Vimer的程序世界

其实第一次创业在技术上还是有不少历史问题的，所以在第二次创业就趁机做了很多弥补，下面详细说一下。

一.运行环境升级

直接列在这里

centos 6.5 x64  -> centos 7.5 x64
mysql 5.5       -> mysql 5.7
redis 2         -> redis 4
python 2.7      -> python 3.7
django 1.6      -> django 2.1
protobuf 2      -> protobuf 3

老版本有很多的问题，比如mysql5.5的性能问题，redis的dump性能问题，python2的中文处理问题，django1.x系列无法自动migrate，protobuf 2的default混乱问题 ...

三周目82.1个小时，《只狼》白金达成！

《只狼》是我玩的第三个魂类游戏，上一款白金的是《黑魂3》，而说来惭愧，自己的第一款魂类游戏居然是《仁王》，因为自己很喜欢和风，所以当时也是冲着这点开的《仁王》的坑。
我记得当时玩《仁王》一周目的时候，不停的死死死，结果后来耐不住性子开着修改器过关了。
但是等通关之后，我突然觉得这样子玩游戏有什么意思呢？于是关了修改器，重新开始打二周目，虽然艰难，但也开始享受到了魂类游戏的乐趣。
然而玩到三周目之后发现这怎么越来越像《暗黑》刷刷刷？

因为自己本身也做游戏研发，所以很仔细的分析过《仁王》的优缺点。
往小了说，《仁王》是把后期数值做崩了。
往大了说，《仁王》没有找清楚自己的定位。
比如同一把武器有多种品质，同一种品质居然还有多种属性。就算起着绝世神兵的名字，什么《雷切》，《妖刀村正》，背包里有十几把的话也实在是感觉不到稀有。
其实说白了，《仁王》不懂得什么叫克制，什么都想要，反而很容易迷失。
而深入来说，是《仁王》团队极度的不自信 ...

转眼间已经接近半年了。

18年12月份开始筹备二次创业的事，光组团队就折腾了4个多月，才终于把团队成型。
美术同学的招聘比较顺利，刚好是之前专门做像素画，也刚好想要跳出舒适区，挑战一下自己。可以说是一拍即合。
客户端主程的招聘就没那么顺利了。前前后后换了几个，中间甚至还遇到过薪资都已经谈好了，入职当天有临时要求加薪导致离职的。
不过好在最终还是找到了合适的人，才得以保证近几个月项目终于开始有条不紊的进行。

服务器端当然就是我自己写了，由于游戏的特点，服务器端其实是相对比较简单的。
但同时我还有一个重要的职责，就是策划。

你问我为什么不单独招一个策划？
说实话，我们在另外一个项目里尝试过这种方法，但是发现当产品的基调都没有定下来的时候，底下的策划很难去真正理解并细化你的想法。
所以，我宁可自己多辛苦一点，也要把这个游戏做成自己真正想要的样子。

值得庆幸的是，正因为如此，我才真正有机会能在和研发/美术一次次的交流中，完善自己的思路，并且碰撞出新的火花。

当然，做策划远比我要想的复杂，尤其是这种创业团队的策划。

一开始，我发现自己很难去确定哪种特性是好的。
具体的粒子就是，两个美术效果，我很难确定哪一个更合适，即使确定下来，也很难给出原因。
因为这是一个很综合的评估标准，而且有很大的主观因素，它并不像程序代码一样，有绝对的正确结果。
而对于我自己来说，我分析了下原因：

1. 在产品策划上的经验太少
2. 就是源于不自信
3. 之前做CTO留下的坏毛病，对自己权威的保护过强

第一个和第二个原因其实是相关联的 ...

第二次创业比第一次做的事情要更加繁琐一些，毕竟之前只要负责技术就好，现在几乎所有的事情都要和我对接，自己还要负责策划+项目管理的工作。
又要画原型图，又要画思维导图，还要画甘特图，有时候还得处理个音效，录个视频，修个图。。

也正是因为如此，所以自己前段时间找了很多工具软件来辅助自己，出于版权和成本的考虑，所以这里推荐的软件基本都是开源/免费的。

一. 原型图

名字: Pencil
价格: 开源免费
平台: Win/Mac/Linux
简介: 不仅仅支持原型图，也支持流程图等功能。
截图:

二. 思维导图

名字: Freeplane
价格: 开源免费
平台: Win/Mac/Linux
简介: 很方便的思维导图工具，而且有键盘快捷键可以使用，很适合键盘党。缺点是比较丑，而且在4K分辨率下很模糊
截图:

三. 甘特图

名字: GanttProject
价格: 免费
平台: Win ...

上一篇文章已经提到过，自己最近在做第二次创业。
至于再次创业的原因，等下次有机会跟大家聊，这次先整理一些和创业相关的工具。
这是自己以前整理的第一次创业时使用的工具: 给创业者整理的工具
时过境迁，很多工具都可以替换或者升级了，所以通过这边文章更新一下。

一. 代码托管

代码托管的选择其实蛮多的:

• github: 使用最广的代码托管网站了。上次创业的时候还只有开源项目免费，现在私有项目也可以免费使用了。但缺点是国内速度太慢。
• bitbucket: 免费支持私有项目托管，在上次创业中使用。缺点和github一样，也是太慢。
• gitee: oschina出品的代码托管网站，速度不错，国内用的人也比较多。但是私有项目有很多限制。
• coding: 与腾讯多次合作与拆分，搞得比较麻烦，但是后来还是独立回来，只是对于项目容量大小有限制。

经过了深入比较后，最终选择了 coding 来做代码托管，速度很不错。就是功能上少了点，比如分支保护等都没有。

当然，等项目做起来之后，可以通过 gitlab 搭建自己的代码托管服务器。

二. 任务管理

这几年一直想把wordpress换掉，因为明明最讨厌的语言就是php，自己还用php搭的博客。

之前之所以一直不做，也是因为python下的博客一直不成熟。

直到前段时间发现了这个：django-blog-zinnia。

支持python3，支持django2，最关键的居然是支持wordpress导入。

当然，实际操作起来才发现坑不少，好在python比较简单，改起来也很快。

折腾了两天总算搞定了，所有数据完美迁移，另外还把很久之前博客改短url导致链接失效的问题给解决了，美滋滋。

这次之所以花了这么久折腾博客，也是因为自己最近二次创业，感受上和第一次创业有了很多不同，所以也是想找时间分享给大家。

既然内容要更新了，门面当然也得跟着装修一下了，哈哈。

今天先写到这，等过几天开始正式写分享。

前段时间有朋友问我：创业这几年对你改变最大的是什么？
我想了半天，说道：应该是思考的角度。

一. 关于离职

只要涉及到团队，员工离职就是一个永远逃避不了的问题。

创业这几年，不停的有人入职、离职，人与人之间的关系可以多快的建立起来，有可以多快的消失掉。

而作为团队的leader要做的，就是通过 感情、成长、利益、希望 各种方面，将这段关系维持的尽量长一点。

之前，我一直在想，中小型的公司，即使能够一直还不错的活着，最终影响员工选择离开的是什么？
当时我得出的结论是：生活

在深圳，即使以腾讯这个规模的体量，也无法确保员工的薪水能够在深圳买的起房子，而仅仅只是能够提供部分无息贷款的方式。
那么小公司呢？

我想到最后，只有一个方法，那就是小公司要自己成长到足够的体量，足以让核心的老员工们，最终能够达到足够的财务自由。

然而，现实远要比想象精彩。

我忘记了还有理想这回事。

最难挽留的离职，不是太累，也不是没前景，也不是薪水低，而是理想。

就像我当年离职创业一样，并不是任何加薪之类的方式可以挽留的了的。

其实慢慢的，当公司足够强壮的时候，即时是leader级别的人离职也渐渐不会对公司产生多大的影响了。

而我一直相信并且也一直在被验证的事情就是：

每一个离开的人，都在让这家公司变得更好 ...

一. 前言

2016年6月17日凌晨5点钟，我们完成了服务器端V3版本的重构，切换的过程十分平滑且没有对线上用户产生任何影响。

这也正式标志着，我们的游戏服务器进入了一个全新的阶段。

我们上一次的重构是在 2014年12月23日，现在看看，时间过的真快啊。

而熟悉我的人应该知道，我特意为上一次重构写过一篇《游戏服务器端架构升级之路》，其中详细的讲述了我们游戏服务器从农业时代跨越到工业时代的历程。

而这次V3版本的重构，我将其定义为第二次工业革命。也许它没有那么的强大和完美，但是他切实的解决了现存的大部分问题。

二. 背景

之前的文章已经说过，V2版本的服务器的几个优点：

1. 支持服务器代码热更新而不影响外网服务
2. 架构模式足够简单：push-pull

但是，其简单的架构也存在一些缺点：

1. 业务模块之间容易互相影响

   比如两个游戏玩法 A 和 B，内部使用的逻辑、存储服务器都完全不同，但是在worker层却是共用的。

   所以一旦玩法A的服务器出现问题导致处理变慢，那么worker就会被堵住，而玩法B也会跟着遭殃。

   同时，即时在一个业务模块内，也存在请求处理优先级的问题，比如拉取牌局记录和跟注，要尽量避免跟注这种核心逻辑受到影响。

2. 限制了游戏逻辑的实现方式

   V2的多worker的模式，导致worker必须限制为无状态的，因为worker可能处理任何一个请求，而一个请求也可能被分配到任何一个worker上。

   这一点是之前解决服务器热重启的关键，但同时也限制了我们代码逻辑多样性的实现。

   比如我们的游戏桌子数据是存储在redis中，所有人对桌子的写操作可能同时分配到多个worker上，而为了避免写冲突，我们不得不通过redis来实现分布式锁 ...

一. 部署自己的git服务器

之前一直是在用bitbucket来做代码托管，因为它的服务器在国外，所以客户端提交大文件的时候慢的跟蜗牛一样。而我们服务器是直接使用tag来进行部署，有时候代码拉不下来也非常痛苦。

正好这次bitbucket提示我们客户端代码已经超过1G，一旦超过2G就无法再push新代码，所以就狠心自己来搭建了。

代码肯定是用的gitlab，版本是7.9。一开始用的7.8，好像对中文支持有bug，后来又升级的。
8.x系列好像部署起来更简单些，也尝试了一下，感觉太傻瓜了导致各种配置路径都不知道在哪，所以还是决定使用7.9。

因为git本身的特性，迁移代码也没费多少力气。

小伙伴们用了新的git服务器之后，普遍反馈速度快的都不习惯了，哈哈。

其实之所以把这件事情单独拿出来说，是因为我觉得这个事情是有着超过其本身的意义的。
那就是：公司已经成长到可以投入一些成本到一些原本第三方能够解决的服务上了。

这其实是一个很大的进步，当公司处于生死边缘挣扎时，是不会去理会这种事情的。

同样的，我们的统计服务也越来越完善，而之前常用的友盟基本已经抛弃不看了。

二. 支持IPv6

我昨天在朋友圈发了个状态：

苹果说：要有光，于是世界有了光。

说实话，也只有苹果敢这么强势了。说是6月1号之后必须支持IPv6，我们版本6月2号就因为这个原因被打回。

而因为我们的网络底层是直接操作的原生socket，所以没法直接使用ios提供的封装库。不过这个最后还好，https://tools.ietf.org ...

之前在文章里面有提到过，很多事情，并没有绝对的对错，只是度的问题。而度的衡量又取决于时、势二字。所以当形势逼人的时候，基本就是这件事情非做不可的时候了。

先说下背景，公司的服务器一直用的阿里云，包括mysql、redis也都是买了ECS自己搭建的。这里面有几个原因:

1. 创业的时候，阿里云只提供mysql的存储，redis的存储还没提供。
2. 没钱，即时现在去看redis的存储价格也是贵的吓人。

这样自己来搞存储有好处也有坏处。 好处：

1. 完全可控，比如连接数限制，内存限制，存储限制。还有数据备份的灵活性等等。
2. 强迫团队服务器研发要有存储运维能力。
3. 省钱

坏处：

1. 冷备、热备方案不完善。
2. 存储运维的成本较高，需要长时间积累。

ok，问题就是这样，接下来再来说一下我们之前的冷备和热备方案。 可以说极其简陋：

1. mysql、redis每天10点冷备，备份到本地磁盘和阿里云OSS
2. redis使用rdb落地，每60秒至少有1次写就会触发落地。

这样做的问题其实挺多的，主要几个:

1. mysql dump的时候会导致游戏卡顿，即使加了 --single-transaction 参数 也仅仅是缓解
2. 冷备频率过低，真出现问题数据已经太久
3. 没有热备，风险较大

针对这些问题，我们先做了mysql备份的优化 ...