查蕴初 李迎接 林芷伊 李泽朋

摘要：微信作为当之无愧的国民级应用，系统复杂程度超乎想象：其后台由三千多个移动服务构成，每天需处理大约十的10～11次方个外部请求，整体需要每秒处理大约几亿个请求！那么微信究竟是如何保证系统稳定性并有序处理各类请求的？本文的作者从技术上深入解读了《用于扩展微信微服务的过载控制》一文，介绍了已在微信上运行了五年之久的过载控制系统DAGOR。

关键词：网络服务器；社交网络；软件

首先，我们能了解一些微信后台的内部消息；其次，作者分享了一种经过实践检验的过载控制系统DAGOR，该系统已经在微信上运行了五年。友情提示，这个系统在设计时就考虑了微服务架构的特殊情况，所以如果你想在自己的微服务上采用某种策略，那最好还是以这个系统为起点参考。

一、每秒需要处理几亿请求的微信后台

现在的微信后台由3000多个移动服务构成，包括实时消息、社交网络、移动支付和第三方认证等，平台每天能处理大约1010～1011外部请求。每个请求可能触发更多的内部请求，所以微信的后台作为一个整体，需要每秒处理大约几亿个请求。

“微信的微服务包含3000多个服务，运行在微信业务系统中的20000多台机器上，随着微信越来越流行，这个数字还在不断增加……由于微信一直在不断发展，它的微服务系统也在迅速更新。例如，从2018年3月到5月间，微信的微服务平均每天大约有1000个修改。”

微信将微服务分类为“入口层”服务（接收外部请求的前端服务）、“共享层”服务（中间层协调服务）和“基本服务”（不调用其他服务的服务，请求在这里终结）。

二、基于微服务的大型平台过载控制的难点

过載控制……对于在任何不可预测的负载高峰下都要保证24x7服务大型在线应用来说极其重要。”传统的过载控制机制主要用于只有少量服务组件的情况，通常包括一个较窄的“前门”，加上一些不重要的依赖。“……现代的在线服务的架构和依赖变得越来越复杂，远远超过了传统过载控制的设计考虑。”发送到微信后台的请求没有单一的入口点，而传统方式是在全局入口点（网关）上以中心化的负载监视为主，因此无法使用。

特定请求的服务调用图可能依赖于请求自身的数据和服务参数，甚至同一种请求的调用图都可能不同。所以，当特定服务出现过载时，很难确定应该拒绝哪一种请求来缓解压力。

过度的请求拒绝（特别是在调用图深处或者请求处理后期拒绝）会浪费大量计算资源，而且会由于高延迟而影响用户体验。由于服务的调用图非常复杂，而且在不断变化，有效的跨服务协调的维护成本和系统额外开销非常高。由于一个服务可能向它依赖的服务发出多个请求，还可能给多个后台服务发出请求，所以在处理过载控制时必须谨慎。作者采用了“序列过载”来描述多于一个过载服务被调用的情况，或一个过载服务被调用多次的情况。

“序列过载给有效的过载控制带来了挑战。直觉上，当服务过载时随机进行load shedding能将系统的吞吐量维持在饱和状态。但是，序列过载可能会导致吞吐量出现预期之外的下降……”

三、微信的过载控制系统DAGOR

微信的过载控制系统叫做DAGOR，它的目标是给所有服务提供过载控制，因此被设计成与服务无关。过载控制运行在单个服务器的力度上，因为中心化的全局协调太昂贵了。但是，它能够与轻量级的服务器间合作协议配合使用，后者在处理序列过载的情况时是必须的。最后，DAGOR应当在load shedding不可避免时尽可能维持服务的成功率。消耗在失败的任务上的计算资源（如CPU、I/O等）应当保持最小。

最后针对开发者，即使你不会完全按照该论文描述的方式使用DAGOR，也提三条非常有价值的建议：

大规模微服务架构下的过载控制必须是去中心化，每个服务必须是自动化；

过载控制应该考虑各种反馈机制（例如DAGOR的协同控制），不要依赖于单一的开环启发；

过载控制设计应当根据实际负载的处理行为进行。

也希望未来的微信能够越来越好，引领通信潮流。

参考文献：

[1]吕金秋.新媒体时代微信营销策略[J].合作经济与科技，2018（24）：110-111.

[2]郭银春，王益祥.基于云服务器与微信平台的水表系统设计[J].单片机与嵌入式系统应用，2018，18（10）：75-77+82.

[3]CSDN资讯<2W台服务器、每秒数亿请求，微信如何不“失控”？>

[4]何平.基于日志来动态调整的服务器性能优化的研究[J].微型电脑应用，2018，34（11）：67-69.