用户破10亿，国民应用微信高并发下的高可用之秘！

2018年12月21日晚间，微信突然发布了7.0版本……

2011年1月21日，微信发布第一个版本……

从1.0到7.0，近8年的时间，微信从一个不知名的APP一跃登上国民超级应用的王座，令同行艳羡。今天的微信，用户数已经超过10亿，每天的微信消息达1000+亿，朋友圈每日发表和点赞数达10+亿，每日浏览数达100+亿……

如此海量场景下，长达8年的时间里，关于微信重大故障的报道我们却少有耳闻，这与微信在高可用方面的努力是分不开的，否则，一个可用性差的APP也不可能成为国民超级应用。

这8年，微信关键技术经过哪些演变？如何保障10亿用户数据不出现问题？面对重大节日、突发事件时，微信又是如何扛住高并发，并做到服务随时可用的？ 这是很多人都关注的问题，阅读完本文，你将得到答案。

本期对话嘉宾：微信技术架构部后台总监许家滔

微信是如何保障10亿用户数据不出现问题？面对重大节日、突发事件时，微信又是如何扛过高并发并做到服务随时可用的？

许家滔：微信作为一个国民应用，对高可用有着极高的要求，是不可以停顿的。高可用又会延伸出两个核心要点：数据一定要是强一致的。但这还不够，计算资源还要可扩展。

多主系统收益很大，可以分为几个点。一是7×24小时的可用性，它可以应对有计划和无计划的停机维护。不再有封尘已久的切换流程，由于多主可用，类似快照与数据对齐等行为，已经在在线核心逻辑中充分体现。其次是变更发布，因为这些系统写出来并非一直不变，最大的可用性需求是来自于我们的程序版本发布。

第二点是资源调度，当系统变多主之后，相当于有了多台随时都可以用的机器，它们的模式都是一样的，为了回避弱的节点去使用更多计算资源，只要切流量就可以了。所以切存储跟切逻辑是一样的，统称为切流量。

最后一点是成本，多主系统的预留冗余成本是相对低的，因为所有的机器都可以服务用户，所以在多主系统方面我们只需预留1/3的成本即可。

计算资源可扩展方面，我们做到了自动扩容。如果在线服务遇到突发流量，弱节点会主动做过载保护，微信所有节点会自动切换计算资源，超过服务能力部分自动转移到其他节点。如果是全链路过载，会触发系统警告，同时会触发自动扩容系统。

当然，这方面我们还在探索中，因为自动扩容需要资源的支持，此外，还有可能出现一些不可预期的情况。目前，微信有能力批准系统做一些自动扩容，而下一步的目标，是让系统在一个资源池情况下可以自动扩容。

这些年来微信技术架构、关键技术经过哪些演变？

许家滔：从架构和职责划分看，不论是接入层，业务逻辑层还有数据存储层，其实变动并不大。但每一层的技术变化非常大。

过去，我们常会说飞机上换引擎之类的话，但现在，我们不怎么说了，为什么？因为经常这样干。

关于演变，举个例子，存储层是我们这几年迭代比较多的部分。数据存储经历过三次大的改造，最开始，我们存储层是基于开源来搭建的，但第二年，我们就全部切换成自己开发的一整套存储。

2013年的那次宕机故障，促使我们开始思考，到底应该用怎样的系统去支撑，这一年我们很困惑，做了大量调研，我们希望达成的目标有2个，一，机器故障是常态，微信希望提供连续无间断的服务能力。二、相对于传统的基于故障转移的系统设计，我们需要构建一个多主同时服务的系统。

虽然很多的解决方案就在那里，但未必就能实现，也未必就合适我们，我们做了很多权衡，2016年，这一块问题就解决掉了，

微信关键技术演变。最初，微信是异步复制，比较传统的一个场景。之后是选主同步复制，到现在的多主可用。

业界有两种比较经典的系统：一种是基于故障切换的系统，包括两个主要的协议，Raft协议和基于租约Paxos Log。来保证数据的一致性，但对服务的可用性有一定影响。另一种是基于多主的系统，是在可用性方面做的最彻底的系统。它是基于非租约Paxos Log，Google MegaStore以及微信PaxosStore。

多主系统有很多的难点。第一， 海量Paxos Log管理，对存储引擎的要求很高；第二，代码假设在一个cas环境中运行。

要做到服务随时可用，对cache和热点处理的要求很高。同时它对于追流水/恢复流程有时效性的要求。

另外，最初的微信连系统内部的数据安全都没有实现，这几年我们在数据安全方面做了很多工作。

目前微信后台研发团队大概是怎样的规模？

许家滔：微信现在已经比较大了，有做基础消息、账号的，也有专门团队做微信支付，还有专门团队做小程序的，要说总的研发人员，不包括公司的基础设备那块，大概有一千多人，都是偏后台的。

人多了后，会带来哪些痛点？

许家滔：人多了之后，理念会不太一样，经验也不太一样，这个时候就需要有流程和工具去支持发展，最大的问题有两个，一是编译，二是如何让系统继续保持简洁和统一管理。

编译是程序构建一个很大的问题，由于服务多，依赖多，一个开发人员，也许只是想要做一下验证，但编译就需要半小时，很麻烦。所以，编译是我们的一大痛点。

微信用户已经破10亿了，随着数据量并发量的增长，通常数据库会最先成为新的瓶颈，你们怎么样去解决数据库的瓶颈，通常有哪些优化的手段？

许家滔：有很多公司，可能一开始就是基于关系数据库来构建，因此，很自然就会出现分表分库的问题，经历NoSQL的发展过程。

但腾讯不太一样，因为一开始我们就基于NoSQL，腾讯早期很多服务都是用手写存储去实现，所以，分库分表问题我们没有，但在自研存储这块，会有新的问题，自研的东西多了，就会有统一架构去做，但统一架构也会有它的假设，因此，早期我们也是一种小表结构来支持我们所有的服务。

那么，也会面临问题，就是像您刚才说的，用户多了之后，表也会变得很大？怎么去优化它？

我们会有两个方法，第一个是基础，第二个是方法，为什么？第一、如果想系统可以扩展，那么，你必须让数据有很高的安全性，所以，核心这一点需要有强一致制算法去做。

当我们把数据的原数据抽出来之后，用Paxos去实现，然后再实现一套完整的可扩展的方案，就可以达到数据库的应对，这是解决开源的问题。

我们有两大手段，开源和节流。开源就解决当你有资源时怎么解决问题，而节流是你不可能无限的申请机器，不管是从技术追求还是从企业角度，这都会有问题。

我们节流这块是怎么做呢？一方面，我们会不断去跟进新的存储技术，去应用在新的架构里面去。另外一方面，针对一些特别大的处理，像支付，搜索，我们会用不同的引擎去处理。

以支付为例，支付早期会用一些关系表来实现一些功能，到了后期，我们探讨发现，其实这一需求是可以具体化，也就说，不用泛化到标准的关系表上面去。

因此，我们会针对性的做一些数据结构，比如，最近做了一个树形结构，这一个方案比原来方案节省大约80%的开销，这是一个典型的案例。

总结来说，在底层提供统一的强一致和可扩展的架构，在上层与不同业务去探索新的，更适合的数据模型。