微信一亿用户增长背后的架构秘密
2012-05-16 10:21:54   来源:CSDN   评论:0 点击:

周颢把微信的成功归结于腾讯式的三位一体策略:即产品精准、项目敏捷、技术支撑。微信的成功是在三个方面的结合比较好,能够超出绝大多数同...

设计,最好的做法是提供0-1中间的选择。举一个例子,当一个用户向另外一个用户发消息的时候,可能会通过一个垃圾信息过滤的检测,如果垃圾信息过滤这个模块突然挂掉了,这个消息难道就不能达到了吗?在这样的情况下,要忽略掉这个错误,使得消息正常达到对方。要精确定位出哪一个环节是最为重要的,把不是重要的错误尽可能的忽略掉。当不能做到完美的时候,尽可能为用户提供服务。另外一个重要方面叫做“保护点前置”,最前的一个点就是终端,在手机终端上蕴埋更多的保护点,这样会为用户系统赢得更大的处理空间。如果终端具备这样的能力,会获得更大的反应空间。

周颢介绍了在微信上具体容灾设计的做法。在所有的容灾中存储层的容灾是最难的,一个系统的设计分为三层:接入层、逻辑层、存储层。接入层和逻辑层的容灾都有比较成熟的方案。逻辑层的容灾相对来说比较简单,尽量不要有状态的设计,比如说当你做上一个请求的时候,会保持一些状态,要使得下一个请求发到下一个服务器。如果任何一个请求之间互相不关联的话,这个就是无状态的设计,只要做到这一点逻辑层的容灾可以随意的切换。在回到存储层本身的容灾设计上,相对来说困难一些,但是微信研发团队采用了一些技巧,叫分而治之,分离业务场景,寻求简单的设计,并不会寻求大而同一的解决方案,因为这样会使得系统的复杂度大幅度上升,而微信会尽可能把产品拆细,寻求简化的设计。

首先是主备容灾,这是最常见的方案。在有一些业务场景中是可以容忍最终一致性的,比如账号系统的设计,每天写入账号系统的请求是非常少的,但是访问的请求非常多,这个差异可能会达到数万倍的规模,在这样的场景下,微信会在账号系统中采用简化的方案,也可以获得比较大的稳定度。

\

SET模型+双写

第二种容灾的模式叫双写,两台Master的机器,当一台机故障的时候,另外一台机还是可以接收到写请求,当两台机交错启动的时候,会得到数据的丢失。但是有一些场景是可以容忍轻度数据丢失的,比如说会有一个存储专门记录用户终端的类型,比如说安卓还是塞班以及他们使用终端的微信版本是什么,这样的数据是可以容忍轻度数据丢失的,因为偶尔有一些丢失的话,下一次访问会把这些数据带上来,会尽快的修复所有的数据。双写也是非常简单的模式。

微信的研发团队做了一个叫Simple Quorum的机制,在微信的后台中,同步协议有一个很重要的基石叫序列发生器,这样的一个序列发生器需要有极高的稳定度。首先可以看到序列号有一个特点永远是递增的,用递增方式往前推进的时候,最大的序列号就是最新的系列号。有一个毕业才加入广研的毕业生想到一个绝佳的方案,按SET分布,从2G减到200K。

前轻后重 功能点后移

周颢还谈到了轻重的概念。这个概念的提出主要是从终端本身的一些困境所带来的。首先在终端上需要表现最多的一个产品的逻辑,逻辑非常复杂,变更的成本也非常高,当需要修复的时候必须发布一个新版本,这个新版必须由自己下载才能完成,下载的成本非常高。在这样的前提下,如果手机终端产生了任何变化的时候,如果这个变化有非常大的问题就会有极大的困境,所以需要在每一个发布之前做一些充分的数据,确保不会发生致命问题。如果一旦出现致命问题难以修复,需要把关键的点从终端移到后台实现,把功能点后移,来充分发挥后台快速变更的能力。

\

接入优化:从GSLB到IP重定向

在接入层的优化,速度很重要的因素,是不是能够就近接入一个最优的节点,比如说移动用户最好接入移动的节点,海外的用户可能需要寻找更佳的路由,有的时候可能无法自动做到这一点,一点是在终端上做测速,微信会通过在后台IP逆向的能力,通过后台指挥微信终端联网的能力,寻找最优的接入点。上图就是每分钟收到同一项指令曲线的报表。

如何解决“偷流量”的问题——当国内类微信类产品发布的时候出现一个大的问题就是“偷流量”,当用户在某一些逻辑下进行一个死循环,不断访问某一些数据,这样的死循环是非常可怕的,如果在用户不知觉的情况之下,可能会在一个小时之内偷到数10兆甚至数百兆的流量。有非常多业内的同行都需要花大量的精力解决这个问题,微信研发团队用了非常强大的方式解决它。通过在后台建立起严厉的监控系统,对每一个用户的行为做一个监控,当发现异常的时候,后台会给终端发出指令,使得微信终端在一段时间无法联网,但是可以保证用户流量不会白白的使用掉。

功能适配的例子——第一期微信版本发布的时候,当时没有群聊的功能,第二版发布的时候做了这个功能。当时有两个选择,对于早期版本的用户,因为不支持群聊,就无法享用到这个功能,但是微信希望提供更好的选择,想让早期不支持群聊的版本,也可以被拉到一个群里面收消息、发消息,通过后台功能的适配也能做到这个事情。

分而治之 把监控嵌入基础框架

对于一个海量系统来说,一个精密的仪表盘非常重要。监控是非常痛苦的,对于这样一个系统来说,每小时会产生数百G的监控日志。微信希望在1分钟之内监控的数据就能够显示在报表上,因为只有这样的精准和实时度才能够赢得处理故障的时间。微信会做关联统计,通过摇一摇加了好友,他们活跃度如何,过了一段时间他们的活跃度变化情况又是如何。这种需求是需要通过大量日志的关联统计来获得的。研发团队也花了一段时间来理解这个问题,发现了中间一个重要的经验叫做“鱼和熊掌不能兼得”。

为了让监控数值更敏感,需要把监控细化再细化,上面数据表示每一栏子系统的数据,下面这个是按微信版本号来划分的,这里的数据项是非常多。

微信还需要采集一些异常的点,如果有异常的话会发布紧急的版本,尽可能快的替换它。对收发消息延时做的监控,比如说0—1秒端到端的速度,会对不同的区段做一些统计,当某一个环节出现异常的时候,通常会在中间的延时上体现出来。有一个很重要的点叫自动报警,现在有数千项的数据,不可能每一项都靠人工去看的,必须要跟自动报警相关联,微信有一些智能的算法,是不是在正常的范围内,跟历史的数值进行对比,如果有异常的话,会通过短信、邮件还有微信本身来发出报警信息。

\

把监控嵌入基础框架

 

 

微信会把监控嵌入到基础框架里面去,因为并不是每一个人都会意识到在需要的地方嵌入一个监控点,所以在基础框架本身内置很重要的监控点,比如说这个表上的栏目,非常多的栏目大概会有数百项的栏目,都不需要程序员自己去写,当用基础组件搭建一个系统的时候,就可以直接观测系统数据。

在谈到微信未来的技术挑战时,周颢首先希望能够让微信成为可用性99.99%的系统;设计出面向现在10倍容量的系统以及完全的IDC容灾。

\

网上盛传的凌晨两点,腾讯大厦那多层大片大片的灯光和楼下那长长的出租车队伍说明了一切。引用一句话做结尾,可怕的不是微信,真正可怕的是,比你领先比你更有天赋的团队比你更努力。

【附录】周颢,2001年毕业于华南理工大学,计算机专业硕士。2005年加入腾讯广州研发部,历任QQ邮箱架构师,广研技术总监,T4技术专家,微信中心助理总经理。

相关热词搜索:腾讯 微信 架构

上一篇:谈谈如何做好运维
下一篇:专访昆仑万维高级架构师:如何保证运维安全?

分享到: 收藏
评论排行