背景介绍

首先，我们需要敏捷开发。过去几年，微信都是很敏捷地在开发一些业务。所以我们的底层架构需要支撑业务的快速发展，会有一些特殊的需求。

另外，目前整个微信团队已经有一千多人了，开发人员也有好几百。整个微信底层框架是统一的，微信后台有千级模块的系统。比如说某某服务，有上千个微服务在跑，而集群机器数有几万台，那么在这样的规模下，我们会有怎么样的挑战呢？

我们一直在说“大系统小做”，联想一下，微服务与腾讯的理念有哪些相同与不同的地方呢？通过对比，最终发现还是有许多相通的地方。所以我挑出来讲讲我们的实践。

看过过去几个会议的内容，可能大家会偏向于讲整一个大的框架，比如整个云的架构。但是我这边主要讲的是几个特殊的点。

概览详情

开始看一下我们的结构。全球都有分布，主要有上海、深圳、香港、加拿大几个数据中心。

其中上海服务国内北方的用户，深圳负责南方用户，加拿大服务北美、南美和欧洲，香港服务东南亚、中东和非洲地区。

然后来看看我们的架构：

• 最上边是我们的产品；

• 然后有一个号称几亿在线的长连接和短连接的服务；

• 中间有一个逻辑层，后台框架讲的主要是逻辑层往后这块，包括我们的 RPC、服务分组、过载保护与数据存储；

• 底层有个 PaxosStore 存储平台。

整套就是这么个体系。微服务很容易去构建，但是规模变大后有哪些问题，需要哪些能力？这里挑出三个点来讲一下：

一、敏捷

希望你的服务很快实现，不太多去考虑。像我们早期互联网业务，甚至包括 QQ 等，我们很注重架构师的一个能力，他需要把握很多的东西。他设置每个服务的时候，要先算好很多资源，算好容灾怎么做。容灾这个问题直接影响业务怎么去实现的，所以有可能你要做一个具体逻辑的时候要考虑很多问题，比如接入服务、数据同步、容灾等等每个点都要考虑清楚，所以节奏会慢。

二、容错

当你的机器到了数万台，那每天都有大量机器会有故障。再细一点，可以说是每一个盘的故障更频繁一点。

三、高并发

基础架构

接下来看看我们的基础架构。

整个微服务的架构上，我们通常分成这些部分：

• 服务布局

• 服务之间怎么做一些远程调用

• 容错（主要讲一下过载保护）

• 部署管理

服务布局

分两层，一个是城市间。城市之间的数据是相对独立的，除了少数账号全球同步，大部分业务都希望做成电子邮件式的服务，各自有自身的环境在跑，之间使用类似于电子邮件的通信。所以我们选择让每个城市自治，它们之间有一个 200-400ms 的慢速网络，国内会快点，30ms。

而城市内部，就是每个园区是一套独立的系统，可以互相为对方提供备份。要求独立的电源与网络接入。

城市内部会有整套的划分，终端 -->接入层 -->逻辑层 -->存储层都是完全独立的一套系统。

远程调用

看到很多框架，竟然是没有协程的，这很诧异。早年我们 QQ 邮箱、微信、图像压缩、反垃圾都是一个 web 服务，只有存储层会独立到后面去，甚至用 web 直连 MySQL。因为它早期比较小，后来变大之后就用微服务架构。

每个东西都变成一个小的服务，他们是跨机的。你可以想象一下，每天我们很多人买早餐的时候，掏出手机做一个微信支付，这一个动作在后台会引起上百次的调用。这有一个复杂的链路。在 2014 年之前，我们微信就是没有做异步的，都是同步的，在这么多调用里，A 服务调用 B，那要先等它返回，这样就占住了一条进程或者线程。所以其实 13 年的时候，我们发生了大大小小的故障，很大一部分原因就在这里。

然后 13 年底的时候，这个问题太严重了，严重到，比如发消息的时候，你去拿一个头像之类的，它只要抖动，就可能引发整一条调用链的问题，并且因为过程保护的不完善，它会把整个消息发送的曲线掉下去，这是我们很痛苦的时间。

然后当时我们就去考虑这些方案，13 年的时候抽出 3 个人重新做了一个完整的库 libco。（两千行），实现时间轮盘与事件处理链、常用网络编程模式、同步原语等。它分为三大块，事件驱动、网络 HOOK 和协程机制。

早期是多进程为主，当年切多线程的时候，也遇到一大波修改，后来线程里有了一个线程变量就好多了。如果没有这个东西，你可能要把许多变量改成参数再一层一层传递下去。有了线程变量就好多了。现在我们的协程变量也是这个意义，效果就像写一个宏一样。

另一个是，我们支持 CGI，早期库在 CGI 上遇到问题，所以没有推广。因为一个标准 CGI 服务是基于一些古老的接口的，像 getENV、setENV，就是说你的 coreString 是通过 ENV 来得到的，那么这个我们也把它给 HOOK 掉了，它会根据你的协程去分派。

最难的一个是 gethostbyname 方法，我发现很多人就连在异步编程里，处理 hostbyname 也可能是用了一套独立线程去做，或者你很辛苦地把整个代码抠出来重新写一遍，这个肯定是有很多问题的。所以我们 libco 就把这个 gethostbyname 给完整地支持了。

最后如果你还不爽，说一般业务逻辑可以这么干，那我还有很多后台代码怎么办呢？很多有经验的老的程序员可能要拿着他们那一堆很复杂的异步编程的代码来质疑我们，他们不认为他们的代码已经完全可以被协程所取代了。

他们有如下两个质疑：

• 质疑性能：协程有很多切换，会不会带来更大开销？

• 你可能处理几万并发就好，消耗个 1G 内存就行，但是我们这里是处理千万并发哦，这么大的规模，我不信任你这个东西。

这样我们其实是面临了一个问题，因为一些老代码，越是高级的人写的，它的技术栈越深，稍微改动一点代码，就出 BUG 了。

所以我们后来做了两个东西，一个是实际修改了相对简单的异步代码到 libco 里，然后性能更好了。因为在做异步编程的时候，你需要自己去维护很多的数据结构，做你的状态保存，它们的生存期有可能需要很久，你自然地会分配许多内存给它，当然你会用一些内存池去优化它，但是这些是有限的。

但是你用协程的话，很多变量就自然在一个连续的内存里了，相当于一个小的内存池，就比如 if……else……这个你没有必要去 new 一个东西保存状态的，直接放在栈里就行了，所以它的性能更好了。

第二个是，它要求很高的并发。由于协程要一个栈，我们一般开 128k，如果你对这个代码掌控得比较好，可能开 16k，就算是这样，你要开 1 万个协程，还是要 100 多 M 的内存。所以我们后来就在这基础上做了一个可以支持千万连接的协程模式。

Libco 是一个底层库，让你很方便开发，但是大部分开发人员不是直接面对 libco 的，我们花了一年时间把整个微信后台绝大部分逻辑服务、存储服务改成基于 libco，整个配置就直接通过配一台机器上的并发数配 10 倍甚至 20、30 倍，这样子就一下子把整个问题解决了。

过载保护

并发数上去后容易引发另一个问题，早期的时候，后端服务性能高，逻辑服务性能相对弱，很容易被 hold，不可能给后端发起很多连接，不具有“攻击性”，但修改完成后，整个前端变得很强，那可能对后端产生很大的影响。这个时候就要来考虑一下过载保护了

关于：中科研拓

深圳市中科研拓科技有限公司专注提供软件+硬件结合系统解决方案定制开发服务，其中包括：软件外包、软件开发、软件定制、硬件开发、硬件定制、智能硬件开发、物联网项目等开发外包服务，通过IT技术实现创造客户和社会的价值，成为优秀的软件公司，通过客户需求导向、开放式创新、卓越运营管理等战略的实施，全面打造公司的核心竞争力。优秀软件外包公司、软件开发公司，联系电话400-0316-532，邮箱sales@zhongkerd.com，网址www.zhongkerd.com