如何解读《微信技术总监谈架构：微信之道——大道至简》

本人VINCI公司工程师，前两天正好内部写了个科普文章，发在微信公众号：VinciChina2015，大家可以移步去VINCI微信公众号。

一、前言

最近在朋友圈看到有人分享腾讯微信技术总监周颢的一个技术报告，题目是《微信技术总监谈架构：微信之道——大道至简》（演讲全文整理、演讲PPT讲稿下载），我也转发了一下。然后就被本司妹子看到了，非让我解释一下。

无奈微信的技术人员出来交流的太少了，只能写下这篇浅显的文章，通俗的解释一下微信背后的技术力量。

二、敏捷

在微信的技术报告中，通篇演讲所说的内容，其实都是为了两个字服务：“敏捷”。首先，我们要先解释一下敏捷。

在软件领域，敏捷软件开发实际上已经是一种术语，它又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。敏捷 (Agile)也是一股思潮, 它包括了好几种软件开发的方法论 (methodology); 这些方法论又是建立在许多业界证明行之有效的最佳实践方法 (best practices) 上面的，例如：Software Development Rhythms 、ASD/Adaptive Software Development、Scrum、XP Extreme Programming等等。敏捷开发最终的目的，都是使软件能够快速迭代和交付。

So，简单来说就是为了软件快速迭代和交付，微信的技术做了什么事情，是如何做的。

在报告中，有一段话的意思是这样的：微信的成功来源于产品决策的成功，为了给产品决策最大的自由度和能力，微信的技术允许发布前十分钟的需求变更。做到这个事情非常非常牛，我必须要解释一下它的难度。

一个人的精力是有限的也是容易出错的，所以，在传统软件开发流程中，规定了一系列的规范来保证软件能够不出错。一个需求的完整开发流程大致是这样的：需求提出，技术分析，开发，自测，模块测试，联调测试，灰度测试，完整发布。

即使已经做了这么多步的保证，所有故障的80%仍然是发布导致的。为了保证服务的稳定性——微信的及格线是99.95%——开发中的变更一般是很昂贵的，因为需要把已经走过的步骤再重走一遍。所以大部分软件开发对于开发中的需求变更都是非常忌讳的，对于开发人员来说也是如此，谁也不想辛苦完成的东西再重新来一遍，或者因为频繁的需求变更导致测试不完全而出现故障。放张漫画感受一下程序员的心情



对于微信来说，更是如此。我估计微信内部有上百个模块，几千台服务器，任意一个模块、程序出现问题都可能会影响到微信的正常服务。尤其是在发布前十分钟还允许变更，需要一套强大的技术、测试和监控系统才能支持如此的任性。

对比一下前东家（不能说名字，也算个大厂），固定每周发布两次，发布持续时间4个小时。例如，周二发布一次，那周二发布的所有需求在周一上午已经确定了；如果发布失败了，第二天继续发这个。我曾经见过有一个需求一周都没有发上去。

在如此困难的情况下，微信凭借了几个思路来做到如此敏捷，后面我来依次解释一下。

三、努力减少人为的错误

既然人的问题如此突出，那么，要想提高效率做到敏捷，一定要先从人的方面着手。
微信的这篇报告提出的思路是：大系统小做+基础组件。应该说，这是一个工业界普遍的解决思路。

我们一般人看到的软件，例如微信，就是在自己手机上运行的一个程序，无所谓大小系统，所有的功能都集中在一起，集中在一个软件中，无需也不能拆分。但在这种服务类软件例如微信、微博等，还有一个更加庞大在后端服务器的程序。

第一，一般来说，后端服务的逻辑相对前端软件来说更复杂：

后端程序要做各种计算、验证和存储的功能。如果前端软件端的代码有几万行的话，后端服务的代码一般要有几十万或者上百万行。例如，简单的登录，在前端只不过发一个登录的请求到后端服务器，而服务器要做的事情呢，从数据库中取得你的用户名和密码验证信息，把请求过来的用户名加密密码（密码不能明文存储，要经过一些复杂的计算过程取得一个加密的东西）和数据库的进行验证；判断是否一个异常登录（还要从数据库取的最近的登录信息）；判断是否过频繁登录（防止恶意服务器攻击）；等这些都做完了，才能返回说登录成功了。

第二，服务器端程序要比前端软件层承载更多的请求和更大的压力：

还是以上一点说的登录举例，所有的那些操作，服务器端要在100ms之内处理完成；同时，这种登录请求每一秒都有几万或者十几万。至少现在，一台普通服务器是无法同时处理这么多请求的，这就表示后端程序要部署很多台机器才行，这也造成了更多的复杂性。

如此复杂的系统，一个人是万万驾驭不了的。那么，唯一的选择就是把复杂变成简单。

首先，针对逻辑复杂的特点，我们会把几十万行代码组成的系统进行拆分，拆分一般是依据功能性，例如：注册登录、消息逻辑、漂流瓶等等，然后把这些程序分别部署到不同的服务器上。

放一页报告的PPT：


这张图应该是微信服务器端的主要逻辑和部署结构，其中每一个机器的图都是一组（很多台）服务器。这样的好处很明显，当拆分后，一个人只需要了解其中某一个模块的程序即可，不再需要详细的了解其他东西是怎么运行的。

但是，逻辑的复杂性解决了，又出现了另外一个问题，就是远程调用的复杂度和稳定性问题。

定义一下远程调用（RPC）：

In computer science, a remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

简单来说，要调用的程序在另外一台物理服务器上。

而有网络参与的情况下，可靠性要比单机调用低一个等级，为了弥补这个可靠性的降低，需要做很多异常情况处理，例如：网络断了、有一次调用非常慢，有一台服务器没有响应了等等。

我们前面又提到，微信只有几十上百个模块在同时运行，不能要求每一个模块都把这些复杂的东西都做一次，并且受限于经验的问题，每个人做的都会不一样会有遗漏，这个时候，远程服务框架这个基础组件就应运而生了。

在报告中的一页PPT，提到了两个基础组件：



就是属于远程服务框架中的一部分，它能够让开发人员很简单的使用，10分钟即可写一个远程调用，并且各种错误都由框架处理了，只要很开心的关心我们的业务是如何运行的即可。Yes，开发快了好多倍。

当然，远程服务框架是一个很复杂和系统的工程，他至少应该关心4个方面：

• 开发的简易型
• 服务的分布式调用链及服务状态的跟踪统计
• 服务的配置管理，包括服务发现、负载均衡和依赖管理
• 服务之间的调度和生命周期管理
  

阿里巴巴公司曾经开源过一套远程服务框架：dubbo，摘一张它的程序整体设计图:



在报告中还提到一个很重要的基础组件，存储组件，它屏蔽了容灾扩容等复杂问题。

存储是如此重要，所有的内容最终都要落到存储上；存储是如此重要，大部分的操作最终都要从存储读数据。正因为存储的重要，所以它又显的非常脆弱，任何一点小的问题，一定会影响一大批用户。

在这种情况下，务必要进行减少存储的出错几率，并且让上层屏蔽这些处理，让开发人员专注于自己的模块，这种思想和前面说的远程调用框架思路是一致的。

在报告中，提到了4中容灾模型，前面两种分别是主备、双写，这个就不多说了，主要说下另外两种。

Set模型+双写：



这里，报告里说的不慎明确，他说能够实现完全一致的备份副本，但是只能支持追加写以及需要外部索引，类似简化版的GoogleFS，主要存储图片和音频。这里我脑补一下，希望能猜中。

读到这些关键字，除了GoogleFS，我还想起了一个东西：bitcask模型。



bitcask模型有一个外部索引，一般是放到内存中，保存了每一个key所在的文件位置和value长度及位置；在写入的时候，追加写入文件中，并更新索引内容，把位置指向新的磁盘位置。bitcask模型的好处是对于机械磁盘友好,写吞吐量大，数据持久化好不用担心crash后的数据丢失问题。这种模型就和报告所说的特点很像了，只不过把内存索引放到了外部一个单独的服务里面。当一个Set写入失败的时候，只需要写入另外一个，并把索引写入索引服务即可；读的时候，先读索引服务，然后去某一个Set中读取数据。因为每一个Set都做了主备模型，并不特别担心不可读。

四、及时发现错误

说了这么多，我们做了好多事情来尽量避免问题的产生，提高生产效率，但是遗憾的是，错误永远不可避免，这个时候，能够及时发现错误并解决它，影响尽量少的人就成了关键。微信给出的答案是：一套简单易用的监控系统+自动报警+灰度上线

对于这个，我其实没有啥好说的，都应该能很好的理解，任何软件服务的监控工作都是必不可少的。不过听视频上说的，微信5分钟即可部署好一个监控点并设置好报警阈值，完成监控和自动报警的工作，这个还是很牛的。

还有一项技术是灰度上线。顾名思义，灰度介于黑与白之间。在这里的意义就是，上线时只上线一部分，目的是用一部分用户检测代码的正确性，如果出现异常可以迅速的回到之前正确的代码上，实现影响尽量少的用户。



从报告给出的截图看，微信可以实现上线时任意选择要上线的服务器。如果上线有问题，也只会影响到访问到问题服务器的用户。当一台服务器上线验证没有问题，可以选择多几台上线，最后再上线全部服务器。这样就减少了很多的风险，有更大的容错性。

附录1：QQ、微信团队原创技术文章汇总

《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《IM全文检索技术专题(一)：微信移动端的全文检索优化之路》
《企业微信客户端中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《以手机QQ为例探讨移动端IM中的“轻应用”》
《一篇文章get微信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》
《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》
《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践》
《微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的》
《微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等》
《微信技术分享：揭秘微信后台安全特征数据仓库的架构设计》
《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践》
《企业微信针对百万级组织架构的客户端性能优化实践》
《揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链》
《微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题》
《微信团队分享：微信后端海量数据查询从1000ms降到100ms的技术实践》
《大型IM工程重构实践：企业微信Android端的重构之路》
《IM技术干货：假如你来设计微信的群聊，你该怎么设计？》
《微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗》
《长连接网关技术专题(十一)：揭秘腾讯公网TGW网关系统的技术架构演进》
《总是被低估，从未被超越，揭秘QQ极致丝滑背后的硬核IM技术优化》
《首次公开，最新手机QQ客户端架构的技术演进实践》
《大型IM稳定性监测实践：手Q客户端性能防劣化系统的建设之路》

附录2：QQ、微信的技术故事

《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》
《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《技术往事：“QQ群”和“微信红包”是怎么来的？》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
《首次揭秘：QQ实时视频聊天背后的神秘组织》
《为什么说即时通讯社交APP创业就是一个坑？》
《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》
《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
《QQ的成功，远没有你想象的那么顺利和轻松》
《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》
《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》
《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？》
《那些年微信开发过的鸡肋功能，及其带给我们的思考》
《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》
《同为IM社交产品中的王者，QQ与微信到底有什么区别》
《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
《社交应用教父级人物的张小龙和马化腾的同与不同》
《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》
《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》

（原文链接：https://www.zhihu.com/question/28165323）

hi，lz你好，一直不太明白set模型+双写是个啥意思，能解释下吗，谢谢

大道至简

微信强

发布前10分钟还能改需求，对微信这么大的服务来说真是太牛x了

确实很牛啊