Vimer的程序世界

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

一. 代码托管

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

• github: 使用最广的代码托管网站了。上次创业的时候还只有开源项目免费，现在私有项目也可以免费使用了。但缺点是国内速度太慢。
• bitbucket: 免费支持私有项目托管，在上次创业中使用。缺点和github一样，也是太慢。
• gitee: oschina出品的代码托管网站，速度不错，国内用的人也比较多。但是私有项目有很多限制。
• 腾讯开发者平台: 前身是coding.net，后来被腾讯收购后，私有项目完全免费无限制。

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

当然，等项目做起来之后，可以通过 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备份的优化 ...

前段时间招聘服务器端研发，面到了一个人，忽然感想挺多，所以就写在这里。

这个同学怎么说呢？他自己可能感觉自己很有想法，很与众不同。
举几个例子：
比如，觉得他所在公司的一个框架的版本太低，官网都更新到v13了，他们还在用v7。想要推动公司内升级，他们技术老大又不肯。所以他觉得公司没有创新精神，死气沉沉。
又比如，研究过redis、mongodb或者其他一些开源框架，就觉得想要应用到公司内部来。但是推了半天又推不动。所以又开始觉得公司不够开放。
又比如，炫耀自己喜欢逛github、stackoverflow，还用rabbitmq写了一个分布式消息处理框架，但是问到承载量，性能瓶颈等等，又完全回答不上来。
又比如，我问了几个网络编程的细节问题，比如 epoll的水平和边缘触发、TIME_WAIT的原因与处理，结果一问三不知。

类似种种。

我之所以拿这个事情，单独写一篇文章来讨论，就是因为我知道，有一批人，一定会走到这个阶段。
因为现在的他，就是当年在腾讯时的自己。

当年的自己也是学了点python，用django写了个网站，逛了github，结果就像发现了新大陆一般，觉得自己牛逼了，别的同学都太out了，连python脚本都不会用，看，同样的功能，用python开发速度比c++快十倍！

所以当时公司很多的工具我都尝试用python来写 ...

其实一直想着写一篇2015年的总结，结果从过年回来就一直忙忙忙，拖到了现在。
本来今晚还想着继续做代码优化，突然听到外面下起雨来，就想着不如趁着今晚把文章给写了吧。

之于公司

15年对我、我的合伙人、乃至我们整个团队来说，都是充满意义的一年。

我记得在很久之前，别人是这样给我形容一家公司从不赚钱到赚钱的过程：

就是突然有一天，你看了看报表，发现，咦，我们盈利啦？！

而这一天，发生在了我们身上的时候，是2015年的10月的某一天。

那是我们奋斗近两年来，第一次看到曙光。

虽然其实盈亏也仅仅是基本打平，但是15年底，我们把我们能动用的所有钱，都拿出来给员工发了年终奖。

我和我的合伙人们，极其的感激这些在最困难的时候陪着我们，并且愿意跟我们一起继续走下去的战友们。

而同时，我也十分的想要告诉那些曾经因为各种原因离开了我们团队的人，感谢你们，让我们坚强并成长。

我最开心的是，技术团队目前还没有一个人在年后提出辞职，我也希望这些优秀的同学们能够一直陪着公司一起走下去。

2016年，已经过去了3个月了。
新的一年，我们得比以前更快！更拼！
2016，继续加油！！！

之于个人

15年对于我个人最大的喜事，应该就是媳妇怀孕啦！ 今天3月9日，马上就到预产期了，现在还有点忐忑自己会不会是一个好爸爸，哈哈。

其实我始终相信，肚子里的宝宝是个贵子，公司运营状况的好转，很大部分功劳都归功于他啦 ...

其实打算做游戏内热更新也是几个月之前的事情了，在方案经历了数次变迁之后，最近才终于应用到了外网的bugfix中。
但是就目前数据来看，热更新由于要下载资源，会使新用户的进入门槛变高，所以留存收到了一定影响，基本降低了10个点。
当然，也可能是热更新的功能存在bug。

好了，我们还是进入正题吧!

方案一

最早的时候，我们想用一种类似打patch的方式来更新。
即将lua代码和资源打成一个zip包，而每个zip包只要代码或者资源发生变化，都会有一个自增的小版本号（大版本号为打在apk或者ipa里的版本号）。
不同的zip包之间diff就可以生成一个patch文件，而为了开发的简单，这个patch列表只会将文件路径列出来，之后客户端要去完整的下载新的文件覆盖。

然而这个方案有很多的问题。

1. 小版本号不好维护 因为代码和资源会不停的修改，而如果人工来维护小版本号，会极其复杂。如果通过机器来维护也是个很麻烦的工程

2. patch包太多 如果我们将小版本号的patch包先生成好放到服务器上，那么如果我们有100个小版本，就会有非常多 1->100, 2->100, 3->100 ... 这种格式的patch包。 并且如果小版本号继续增长，patch包的增长基本会失控。

3. 消耗大量流量，速度缓慢 也许有同学会说，不如只有 1->2, 2->3, 3->4 这样的单个小版本之间的升级patch，客户端自己挨个下载就好。

   但是这样客户端如果是个很小的版本号，就不会不停的重复下载，导致迟迟进入不了游戏，并且流量也大量消耗。

综上所述，方案一有太多的弊端。
这也是为什么我们做完了之后迟迟不敢上线的原因 ...

一. 发现问题

最近新版本上线，公司内部的几台iphone测试机测试都一切正常，但是外网用户却频频反馈崩溃。

在友盟上看了错误率统计，曲线如下:

可以看出，错误率确实有了很大的上浮。基本可以确认一定是出问题了。

二. 还原崩溃现场

我们游戏用得cocos2dx-lua，既然是崩溃，那就一定是到了c++端了，我们点击友盟上数量最多的那个看一下：

到了这里，遇到了第一个难点，因为按照友盟文档，使用他的错误dump工具是无效的，一旦看不到具体的错误内容，基本就无法继续了。

(而因为这个问题，发现有人推荐bugly，打算在下一个版本里面试用一下，再给大家反馈)

既然友盟提供的工具不行，我们就得像别的办法，起码现在错误的原始内容是有了，只是要想办法还原出来而已。

仔细研究了一下，友盟其实也是使用了mac原本就提供的工具来做了二次封装，那不如直接用原生的工具了。

具体方法如下：

1. 找到当时出包得那个archive文件，显示包文件，在其中找到如下两个文件放到同一目录:

   xxx.app xxx.app.dSYM

   其中 xxx.app.dSYM 即为符号表文件。

2. 查看其对应的UUID，一定要与crash log的UUID一致

   $: dwarfdump --uuid xxx.app ...