《微信架构》由会员分享，可在线阅读，更多相关《微信架构（11页珍藏版）》请在金锄头文库上搜索。
1、微信架构（转）微信腾讯战略级产品，发明移动互联网增速记录，10个月00万手机顾客,43天之内完毕顾客数从零到一亿的增长过程,千万级顾客同步在线，摇一摇每天次数过亿.在技术架构上，微信是如何做到的？日前,在腾讯大讲堂在中山大学校园宣讲活动上，腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。周颢，毕业于华南理工大学,计算机专业研究生。加入腾讯广州研发部，历任QQ邮箱架构师，广研技术总监,技术专家,微信中心助理总经理。腾讯广研助理总经理、微信技术总监 周颢 CSDN配图周颢把微信的成功归结于腾讯式的“三位一体”方略：即产品精确、项目敏捷、技术支撑。微信的成功是在三个方面的结
2、合比较好,可以超过绝大多数同行或对手,使得微信走到比较前的位置。所谓产品精确，通俗的讲就是在恰当的时机做了恰当的事，推出了重量级功能，在合适的时间以最符合人们需求的方式推出去。她觉得在整个微信的成功中，产品精确占了很大一部分权重。敏捷是一种态度 敏捷就是试错微信研发团队里鼓励一种试错的信奉:她们坚信,在互联网开发里,如果可以有一种团队在更短的时间内尝试了更多机会(并能改善过来)，就能有(更多的）机会胜出。敏捷是一种态度,在软件开发过程中,项目管理者都会非常忌讳“变更”这个词,但是在微信的项目运作中是不可以的。由于微信必须要容忍说哪怕在发布前的十分钟,也要容许她变更。这是非常大的挑战,由于打破了
3、所有老式项目开发的常识。所有人都说不也许做到的,但微信做到了。研发团队所做的一切都是要给产品决策者有最大的自由度，而这个决策正是微信可以胜出的核心。海量系统上的敏捷 无异于悬崖边的跳舞敏捷有诸多困境，如果做一种单机版程序，是可以做到很敏捷的,但是腾讯正在运作的是一种海量系统，有千万级顾客同步在线,在一种单独的功能上每天有百亿级的访问，同步还要保证9.95%的可用性。在海量系统上应对项目开发会有很严谨的规范,都说要尽量少的变化,由于90%5%的错误都是在变更中产生的，如果系统始终不变更会获得非常高的稳定度，但是微信就是要在悬崖边跳舞。微信的研发团队要做某些事情,让敏捷开发变得更简朴。如何做到这一
4、切?周颢觉得，一方面，必须建立起一种狂热的技术信念,就是一定是可以做到的。然后,需要用某些稳固的技术(理念)来支撑,例如大系统小做、让一切可扩展、必须有基本组件、轻松上线（灰度、灰度、再灰度；精细监控；迅速响应).等等来支撑。四大法器：大系统小做、让一切可扩展、要有基本组件、轻松上线大系统小做：当设计庞大系统的时候,应当尽量分割成更小的颗粒，使得项目之间的影响是最小的。一切可扩展：在高稳定度、高性能的系统中间,为了稳定性能把它设计成不变化的系统，但为了支持敏捷需要让一切的东西都要变得可以扩展。必须建立基本组件：要解决复杂问题的时候,需要将已有的经验固化下来,固化下来的东西会成为系统中的一部分。
5、轻松上线：当做了变化并把它从开发环境中部署到既有的运营环境中去，在这个过程中,“灰度”这个词非常核心，就是在黑和白之间的选择，必须要变成一种小规模尝试,再逐渐扩展到海量过程中的一种问题。大系统小做仅仅把模块变得更为清晰，这在海量系统设计开发中是不够的,还需要在物理环境上进行分离部署,浮现问题的时候可以迅速发现,并且在最快的状况下解决掉。转播到腾讯微博大系统小做 混搭模式将不同的应用逻辑物理分割独立出来，顾客注册登录、BS逻辑、摇一摇逻辑、漂流瓶逻辑、消息逻辑独立开来。把核心的逻辑混搭在一起，当所有的逻辑部署在同一种服务器上,的确也会带来很大敏捷上的好处，由于不需要额外的考虑部署和监控的问题。在
6、整个微信的逻辑中，也许目前已有上百种不同的逻辑，由于会在逻辑的分割上拆提成-0种做分离部署。一切可扩展网络合同可扩展、数据存储可扩展扩展的核心点有两块。一种是网络合同需要扩展,当要升级一种新功能的时候,会有某些比较大的困难,因此所有合同设计都比较向前兼容,但是向前兼容还是不够的,由于网络合同设计自身有非常多的功能也会有比较大的字段,有关的代码也许会有数千行，这一块不能通过手写方式完毕。可以通过XML描述，再通过工具自动生成所有的代码,这是微信获得迅速开发的一种重要的点。此外一块就是在数据存储方面是必须可扩展的。在绝大多数海量系统的设计都是采用固定字段的存储,但是在现代系统中会意识到这个问题,会
7、采用KV或者TV的方式,微信也做了不同的设计。把复杂逻辑都固化下来,成为基本软件。在微信后台会有几种不同的基本组件。大体涉及：SrktinSrer自动代码生成框架:0分钟搭建内部服务器LoiServr逻辑容器:随时添加新逻辑OssAgt监控/记录框架:所见即所得的监控报表存储组件屏蔽容灾/扩容等复杂问题灰度、灰度、再灰度在变更后的部署方式上，微信在某些规则会限定不能一次把所有的逻辑变更上去,每一次变更一小点观测到每一种环节没有问题的时候，才干布局到全网上去。微信后台每一天可以支撑超过20个后台变更，在业界来说,一般做到5个已经是比较快了,但是微信可以做到快4倍。转播到腾讯微博腾讯内部的上线系统
8、而所谓灰度发布，是指在黑与白之间,可以平滑过渡的一种发布方式。AB es就是一种灰度发布方式，让一部顾客继续用A，一部分顾客开始用B,如果顾客对B没有什么反对意见，那么逐渐扩大范畴,把所有顾客都迁移到B上面 来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调节问题，以保证其影响度。(在腾讯,灰度发布是最常采用的发布方式之一)孙子兵法：古之所谓善战者,胜于易胜者也常识上，解决一种复杂问题的时候，会用高明的技巧解决复杂的问题,这个不是微信团队的目的，她们追求的要做到让所有问题很自然和简朴的方式解决掉。在周颢看来,微信架构的技术复杂点在四个要点：合同、容灾、轻重、监控。转播到腾讯微博
9、微信架构合同。手机终端跟后台服务器之间的交互合同,这个合同的设计是整个系统的骨架，在这一点做好设计可以使得系统的复杂度大大减少。容灾。当系统浮现了若干服务器或若干支架（宕机的时候),仍然需要让系统尽量的提供正常的服务。轻重。如何在系统架构中分布功能,在哪一种点实现哪一种功能，代表系统中间的功能配备。监控。为系统提供一种智能仪表盘。在合同设计上，移动互联网和常规互联网有很大的区别。一方面有MW和CNE的不同,在中国目前有相称多的手机顾客使用MWAP连接，尚有就是在线和离线的概念,当QQ下线的时候叫离线，当你登录的时候叫在线。但是在移动互联网这两个概念比较模糊。从微信的设计中,不管在线还是离线系统
10、体现都应当是一致的。尚有一种是连接不稳定的问题,由于手机信号强弱的变化，当时信号较好,5秒钟走到信号不好的地区，连接就必须断掉。这个中间带来不稳定的因素为合同设计带来较大困难。此外就是资费敏感的问题，由于移动互联网是按照流量计费的,这个计费会使得在合同设计中如何最小化传播的问题。最后就是高延迟的问题。对此，业界原则的解决方案:MessaginndPresce Protocol：1)XMPP;2)SIPSIMPLE。它的长处是简朴，大量开源实现。而缺陷同样明显：1)流量大:状态初始化；2)消息不可靠。微信在系统中做了特殊设计,叫YNC合同,是参照Acivesyec来实现的。特点一方面是基于状态同
11、步的合同,假定说收发消息自身是状态同步的过程,假定终端和服务器状态已经被迟了，在服务器端收到最新的消息,当客户端、终端向服务器对接的时候，收取消息的过程事实上可以简朴的归纳为状态同步的过程，收消息以及收取你好友状态更新都是相似的。在这样的模式之下，我们会也许会把交互的模式统一化，只需要推送一种消息达到的告知就可以了,终端收到这个告知就来做消息的同步。在这样的简化模式之下,安卓和塞班都可以得到统一。这样的系统自身的实现是更为复杂的，但是获得诸多额外的好处。让剩余系统实现的部分更加简朴,简化了交互模式,状态同步可以通过状态同步的差值获得最小的数据变更,通过增量的传播得到最小的数据传播量。通过这样的
12、合同设计，微信可以保证消息是稳定达到的,并且是按序达到。引用一句俗话：比它炫的没它简朴,比它简朴的没它快,没谁比她更快,哪怕在GPRS下,微信也能把进度条容易推究竟。追求完美设计的团队不能胜任海量服务在容灾之前面向最坏的思考，如果系统真的挂了,需要做某些事情，一方面是避免雪崩，避免蝴蝶效应。如果关注春节订火车票就懂得了,顾客的祈求量会由于系统服务不了而不断的重试，意味着发生雪崩的时候，系统也许会承载原先-1倍的流量,使得所有的事情更加恶化。因此微信有诸多“放雪”功能的设计。第二个词是柔性可用，在任何的系统中不要追求完美设计,追求完美设计的是团队是不能胜任海量服务的。如果在一种系统浮现问题的时候
13、，这个系统就挂了，那么这是一种不好的设计,最佳的做法是提供0-1中间的选择。举一种例子,当一种顾客向此外一种顾客发消息的时候,也许会通过一种垃圾信息过滤的检测,如果垃圾信息过滤这个模块忽然挂掉了，这个消息难道就不能达到了吗？在这样的状况下,要忽视掉这个错误，使得消息正常达到对方。要精拟定位出哪一种环节是最为重要的,把不是重要的错误尽量的忽视掉。当不能做到完美的时候,尽量为顾客提供服务。此外一种重要方面叫做“保护点前置”,最前的一种点就是终端，在手机终端上蕴埋更多的保护点,这样会为顾客系统赢得更大的解决空间。如果终端具有这样的能力，会获得更大的反映空间。周颢简介了在微信上具体容灾设计的做法。在所
14、有的容灾中存储层的容灾是最难的，一种系统的设计分为三层:接入层、逻辑层、存储层。接入层和逻辑层的容灾均有比较成熟的方案。逻辑层的容灾相对来说比较简朴,尽量不要有状态的设计,例如说当你做上一种祈求的时候，会保持某些状态,要使得下一种祈求发到下一种服务器。如果任何一种祈求之间互相不关联的话，这个就是无状态的设计，只要做到这一点逻辑层的容灾可以随意的切换。在回到存储层自身的容灾设计上，相对来说困难某些，但是微信研发团队采用了某些技巧,叫分而治之,分离业务场景，谋求简朴的设计,并不会谋求大而同一的解决方案,由于这样会使得系统的复杂度大幅度上升，而微信会尽量把产品拆细,谋求简化的设计。一方面是主备容灾，
15、这是最常用的方案。在有某些业务场景中是可以容忍最后一致性的,例如账号系统的设计,每天写入账号系统的祈求是非常少的，但是访问的祈求非常多,这个差别也许会达到数万倍的规模,在这样的场景下，微信会在账号系统中采用简化的方案，也可以获得比较大的稳定度。转播到腾讯微博ST模型+双写第二种容灾的模式叫双写，两台Maste的机器,当一台机故障的时候,此外一台机还是可以接受到写祈求,当两台机交错启动的时候，会得到数据的丢失。但是有某些场景是可以容忍轻度数据丢失的,例如说会有一种存储专门记录顾客终端的类型，例如说安卓还是塞班以及她们使用终端的微信版本是什么,这样的数据是可以容忍轻度数据丢失的，由于偶尔有某些丢失的话，下一次访问会把这些数据带上来,会尽快的修复所有的数据。双写也是非常简朴的模式。微信的研发团队做了一种叫me Qoum的机制，在微信的后台中,同步合同有一种很重要的基石叫序列发生器，这样的一种序列发生器需要有极高的稳定度。一方面可以看到序列号有一种特点永远是递增的,用递增方式往前推动的时候，最大的序列号就是最新的系列号。有一种毕业才加入广研的毕业生想到一种绝佳的方案，按SET分布，从G减到20K。前轻后重 功能点后移周颢还谈到了轻重的概念。这个概念的提出重要是从终端自身的某些困境所带来的。一方面在终端上需要体现最多的一种产品的逻辑，逻辑非常复杂，变更的成本也非常高,当需要修复的时候必
