微信后台技术“干货们”带来的启发

因为持续写作的缘故，因而有了记录、收藏和整理阅读笔记的习惯。之前春节在家休息无事时就顺便整理了下 2016 一年以来收藏的内容和笔记，发现技术内容中收录了好多篇有关微信后台的技术干货文章。

想到去年中时我还写过一篇《技术干货的选择性问题》里面提到五年前我们做 IM，那时腾讯公司在技术上保持神秘而低调，去年的腾讯在技术上表现得非常开放，不仅贡献了不少不错的技术干货文章，也开源了不少它们的基础组件库。

本篇算是我阅读完微信后台技术相关的干货文章后得到的一些启发，如果去年中那篇属于技术干货的选择问题，这篇大概就是选择之后的消化吸收问题了。

在前文中提过，循证大概是我们读技术干货文章的一个原始诉求，通过分析别人走过的路径，来拨开自己技术道路探索上的迷雾。

关于 IM 类消息应用最重要的一个技术决策就是关于消息模型，微信采用了存储转发模型，其具体描述如下（参考[1]）：

消息被发出后，会先在后台临时存储；为使接收者能更快接收到消息，会推送消息通知给接收者；最后客户端主动到服务器收取消息。

简单描述这个模型就是三个步骤：

初一看这个模型多了一层通知再拉取的冗余，为什么不直接把消息推下去？对，最早期我们自己做 IM 就设计的先尝试直接推消息下去，若接收端没有确认收到，再临时存储的模型。后者减少了临时存储的量和时间，也没有一个多余的通知。

但后面这个模型增加了另一层复杂度，在早期的 PC 互联网时期，推送并确认效率还算挺高的，但在移动环境下，就不太行了。而且引入了移动端，实际就导致了另一层复杂性，多终端在线，多终端确认，多终端已读和未读，都需要在服务端记录各个端的状态。所以，之后我们也就慢慢演变成同时存储和推送消息的并行模型，存储是为了方便各终端拉取各自的离线消息，但推送因为需要考虑旧终端版本的支持，还得直接推消息本身而并不容易简化成消息通知来取消掉消息的接收确认过程。

循证，即便你看到了一个更好的方式，但也要结合自身的实际情况去思考实践的路径。所以，如今我们的模型相比微信是一个更妥协的版本，若是五年多前要改成微信这样的模型，也许只需要一两个程序员一周的时间。但如今也许需要好几个不同的开发团队（各终端和后端）配合弄上一两个季度也未必能将所有用户切换干净了。

IM 中还有个大家特别常用和熟悉的功能 —— 群消息。关于群消息模型，微信采用的是写扩散模型，也就是说发到群里的一条消息会给群里的每个人都存一份（消息索引，参考[1]）。这个模型的最大缺点就是要把消息重复很多份，通过牺牲空间来换取了每个人拉取群消息的效率。

好多年前我们刚开始做群时，也是采用了的写扩散模型，后来因为存储压力太大，一度又改成了读扩散模型。在读扩散模型下，群消息只存一份，记录每个群成员读取群消息的偏移量（消息索引号，单调增长）。之所以存储压力大在于当时公司还没有一个统一的存储组件，我们直接采用的 Redis 的内存存储，当时原生的 Redis 在横向和纵向上的扩展性上都比较受限。这在当时属于两害相权取其轻，选择了一个对我们研发团队来说成本更低的方案。

再后来公司有了扩展性和性能都比较好的统一存储组件后，实际再换回写扩散模型则更好。毕竟读扩散模型逻辑比较复杂，考虑自己不知道加了多少个群了，每次打开应用都要检查每个群是否有消息，性能开销是呈线程递增的。唯一的问题是，写好、测好、上线运行稳定几年的程序，谁也不想再去换了对吧，每一次的技术升级和架构优化其实是需要一个契机的。

另外一个是所有分布式后台系统都有的共性问题 —— 性能问题。只要你的用户量到了一定规模，比如 100 万，以后每上一个量级，对技术支撑的挑战实际上并不是呈线性的。微信春晚红包的案例（参考[2]）给出了一个很好的参考和启发，因为市面上几乎很少有系统能到这个量级了。

微信 2015 年春节的红包峰值请求是 1400 万每秒，而微信后台其实也采用了微服务的架构，其拆分原则如下（参考[1]）：

实现不同业务功能的 CGI 被拆到不同 Logicsrv，同一功能但是重要程度不一样的也进行拆分。例如，作为核心功能的消息收发逻辑，就被拆为 3 个服务模块：消息同步、发文本和语音消息、发图片和视频消息。

服务拆散了，在自动化基础设施的辅助下，运维效率下降不大，而开发协作效率会提升很多，但性能会下降。那么在面对微信春晚红包这样的极端性能场景下，该如何应对？在电商里，正常下单和秒杀下单多是分离的两套系统来支撑，秒杀专为性能优化，简化了很多正常流程，而且秒杀本身需要支持的 sku 不多，所以它具备简化的基础。而微信给出的方案中实际也是类似的思路，但它有个特殊点在于，能把拆散的服务为了性能又合并回去。

在如此海量请求之下，在这个分布式系统中，任何一点网络或服务的波动都可能是灾难性的。最终我们选择把摇一摇服务去掉，把一千万每秒的请求干掉了，把这个服务挪入到接入服务。但这样做，有一个前提：不能降低接入服务的稳定性。因为不单是春晚摇一摇请求，微信消息收发等基础功能的请求也需要通过接入服务来中转，假如嵌入的摇一摇逻辑把接入服务拖垮，将得不偿失。

这里面的黑科技在于 C++ 技术栈的优势，同一台接入服务器上实际由不同的进程来处理不同的功能，达到了隔离的效果。而不同进程间又可以通过共享内存来通信，这比用 Socket 网络通信高效多了，又有效的规避了网络层带来的波动性影响，这是我们用 Java 做后台没法做到的事。

切磋，你不能看见别人的功夫套路好，破解难题手到擒来，就轻易决定改练别人的功夫。表面的招式相同，内功可能完全不同，就像金庸小说里的鸠摩智非要用小无相功催动少林七十二绝技，最后弄的自废武功的结局。切磋主要是带给你不同的思维方式，用自己的功夫寻求破解之道。

如何选择干货，我在前文《技术干货的选择性问题》中最后给出的结论是，给自己结一张网，形成知识体系。暂时离你的网太远的技术潮流性的东西，可以暂不考虑，结合功利性和兴趣原则去不断编织和扩大自己的技术之网。在编织了一些新结点入网后，就需要进一步有效提取这些结点的价值。