微信架构的启示

标签： Uncategorized | 发表时间：2012-11-12 17:06 | 作者：flychen
出处：http://flychen.com

腾讯大讲堂中最近分享了周颢演讲的 微信技术总监解读微信架构的秘密，看完视频的一些心得。

技术微创新

微信的技术设计上有很多微创新，看起来都很小，但是对于系统的稳定性、用户体验及开发敏捷都具有重要作用。

前轻后重
由于客户端升级不便，从技术设计上尽量利用后端的设计来减少依赖客户端升级的方法。如某个版本新增了群聊功能，按常规思路，需要所有客户端升级才能全部打通。微信采用服务器兼容的方法，在老客户端不升级情况下让其增加群聊的功能，通过在服务端将群聊协议转换成之前旧版兼容的协议返回给老的客户端。

客户端辅助设计
微信客户端做了很多非常规的功能，比如常规的客户端测速方法是登录阶段轮询测试多个IP来选择服务器，这样会带来流量及登录速度双方面的开销，因此微信选择的方法是服务端返回最佳的IP（可能是通过历史数据分析）。客户端另外实现了一些容灾能力的配合，当一个IDC访问出现异常自动选择另外一个IDC。

流量控制
由于大部分无线用户对流量非常敏感，为了防止由于客户端不可预知的bug如死循环导致“偷流量”，服务端增加用户流量实时分析的方法，可以在海量数据下找出流量异常的用户，并给这些用户强制下行终止连接信号。

基础研发的策略

从视频介绍来看，微信的基础研发与业务结合非常紧密，提到的有基础组件比如Client/Server框架，从原理上看类似Twitter Finagle，框架封装了大容量网络通讯及远程调用所需各种功能。此外介绍的一些监控与统计框架也较为先进，可以随时增加监控指标。

大量可复用的基础组件让业务开发非常敏捷，周颢总结的基础研发策略是“实现已有经验的固化”。这和其他一些公司中的基础研发团队思路有所区别。业界中基础研发脱离生产闭门造车的情况并不罕见，一方面业务部门重复低层次开发现象严重，另外一方面基础研发对业务理解欠缺，开发的组件模块与业务结合不紧密，无法被有效利用。因此类似微信这样增强业务团队的力量，在开发业务同时总结抽象更多的基础组件或许是一种更为实用的发展思路。

腾讯海量课程

视频中多次提到腾讯内部的一种海量模型的培训课程，其中的经验或设计模式包括
大系统小做
将一个复杂的大系统分解成多个独立的、小的、简单的任务去完成，“分而治之”。

柔性可用
服务端系统通常不是0与1之间的选择，可以在极端情况下做一定优雅降级，在服务端代码中需要体现这些设计。

Set模型
类似最近讨论的 cell架构，按一个服务按用户范围分成不同的小单元，每个小单元(cell/set)具备全部业务服务能力，当一个set发生故障时候，只会影响这一小部分用户。微信架构中所做的补充是，在set之间增加了容错处理，当一个set发生故障时，使用类似一致性哈希的算法，调用方可以自动切换到下一个set来存储，并且将新的位置记录在index上(类似GFS master)，周颢自称是一个简化版的GFS。

微信的协议

里面提到了XMPP和类Sync的自定义协议，里面提到XMPP的缺点是流量大和消息不可靠。但是流量大并非XMPP主要矛盾，可以很简单将其映射成二进制协议。消息ACK也可以添加简单的扩展协议来实现。较繁琐的还是兼容CMWAP网关的设计。

使用XMPP或者简化的XMPP标准协议有很多好处，类似的场景有业界广泛使用的open api基本都使用HTTP及JSON，并不是由于这两种协议优化或高效，而是其简洁并得到广泛的认知。一种标准协议的认知及扩展成本要比一个自定义协议小得多，XMPP流量大的问题可以通过转换协议来实现，比如用binary 1代表login等全部协商协议，2代表message，消息增量获取也可以通过自定义扩展协议来实现。标准协议可以让团队内部及新人的认知成本降低，每一个参与者都很容易想到代码及架构改进建议。而且微信目前也在构建开放平台，自定义协议在开放方面必然具备一些局限。

其他

分布式理论
从微信的分享也看到，指导业界不同背景的团队（不管大小）的分布式理论主要还是Google及Amazon系列论文，对互联网技术的发展具有深远影响。微信借鉴了Quorum及Merkle tree的理论，创造了一种自定义的做法，用于实现一种分布式递增发生器。
不过分布式递增算法其实有更简单的实现方法，twitter也有相关的公开博文，由于视频相关背景介绍比较简短，可能大家解决的需求具有差异，就不展开了。

监控
数千的监控项，可以在分钟发现系统的异常

敏捷
每天20个后台变更

技术传承
从视频和PPT来看，微信的技术体系是从头搭建的，可能有不少利用qqmail时代的基础代码，但与深圳团队并不存在太大技术沿袭或者传承关系。从另外一个角度也看到微信技术团队的战斗力。

新人力量
一位毕业生的创意：按SET分布,全量数据从2G减到200K（具体的情况待了解）
另外一个新特性，漂流瓶及摇一摇，据说也是2个月的本科毕业生一周完成，而且上线后运行稳定。

存储

上图中可扩展设计中字段配置表的做法感觉略显繁琐，目前大部分NoSQL产品的schema free方式可能更易于维护。

产品驱动

如图，其中“允许发布十分钟前的变更”这样做法通常在大型团队通常会引起广泛质疑，单纯学习这种形式并非正解，如何在互联网产品上实现敏捷值得产品和研发进一步思考。

Similar Posts:

转载自 Tim[后端技术]

您可能也喜欢：

以求医为例谈搜索引擎排序算法的基础原理
iPhone 真机测试教程-伪造证书,使用证书
| 搜索引擎技术博客
贝叶斯推断及其互联网应用（三）：拼写检查
无觅

相关 [微信 架构 启示] 推荐：

微信架构的启示

- - Tim[后端技术]
腾讯大讲堂中最近分享了周颢演讲的 微信技术总监解读微信架构的秘密，看完视频的一些心得. 微信的技术设计上有很多微创新，看起来都很小，但是对于系统的稳定性、用户体验及开发敏捷都具有重要作用. 由于客户端升级不便，从技术设计上尽量利用后端的设计来减少依赖客户端升级的方法. 如某个版本新增了群聊功能，按常规思路，需要所有客户端升级才能全部打通.

微信红包的架构设计简介

- - 鸟窝
来源于QCon某高可用架构群整理，整理 by 朱玉华. 背景：有某个朋友在朋友圈咨询微信红包的架构，于是乎有了下面的文字（有误请提出，谢谢）. 概况：2014年微信红包使用 数据库硬抗整个流量，2015年使用 cache抗流量. 答：微信金额是拆的时候实时算出来，不是预先分配的，采用的是纯内存计算，不需要预算空间存储.

[转][转]微信、陌陌等著名IM软件设计架构详解

- - heiyeluren的blog（黑夜路人的开源世界）
对微信、陌陌等进行了分析，发出来分享一下（时间有些久了）. 有兴趣的同学可以加入群：369511307. 电量：对于移动设备最大的瓶颈就是电量了. 因为用户不可能随时携带电源，充电宝. 那就要检查我们工程是不是有后台运行，心跳包发送时间是不是合理. 流量：对于好多国内大部分屌丝用户来说可能还是包月30M，那么我们必须站在广大用户角度来考虑问题了.

腾讯微信技术总监周颢：一亿用户增长背后的架构秘密

- - 互联网的那点事
微信——腾讯战略级产品，创造移动互联网增速记录，10个月5000万手机用户，433天之内完成用户数从零到一亿的增长过程，千万级用户同时在线，摇一摇每天次数过亿…在技术架构上，微信是如何做到的. 日前，在腾讯大讲堂在中山大学校园宣讲活动上，腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密.

[转]万亿级调用系统：微信序列号生成器架构设计及演变

- - 步步为赢
“每天万亿级调用的重量级系统，每次申请序列号平时调用耗时1ms，99.9%的调用耗时小于3ms，服务部署于数百台4核CPU服务器上. 曾钦松，微信高级工程师，目前负责微信后台基础服务、朋友圈后台等开发优化，致力于高可用高性能后台系统的设计与研发. 2011年毕业于西安电子科技大学，早先曾在腾讯搜搜从事检索架构、分布式数据库方面的工作.

Instagram启示录

- Wenhuan - 所有文章 - UCD大社区
不管认为Instagram是lomo-twitter还是poladroid+iphoneography. 照片分享服务Instagram于 6个月之前上线，上个月24日公开发布了支持实时功能的API，第三方开发人员可以根据标签、地点和地区抓取照片. 数据显示，Instagram目前每周新增13万用户.

原生启示录

- stingzou - 互联网的那点事...
之前写过一篇关于andoid和ios对比的文章——乔布斯改变移动未来的人. 人们通常认为苹果是靠iphone卓越的外观设计轻松取得5%的移动市场份额和他人望其项背的利润，但老乔自视苹果是一个缔造优质软件的企业. 他曾夸口苹果在软件上的水平要领先业界5年. 今年ipad2发布的时候 乔布斯还是没免俗的演示自己开发的应用.

母狼的启示

- - 吴越的BLOG
一个朋友的孩子大学毕业半年了，没有去找事，窝在家里，白天睡觉，晚上上网. 最近跟他父母要钱，想去美国游学，朋友来问我该不该让他去，. 我望着他苍苍的白发说 ：“你如果真的要为孩子好，让他去，但是不要给他钱. 我想到了我妹婿的故事. 我妹婿是美国人，从小就想当水手，向往外面的世界，想先环游世界再回学校念书.