腾讯官方写论文：微信的技术架构有多复杂
腾讯旗下的微信从一个通信工具变成一个庞大平台，究竟经历了什么？微信开发者团队最近一篇论文“Overload Control for Scaling WeChat Microservices（超大规模微信微服务中的过载控制）”透露了部分细节，主要讲述了微服务的过载控制。
基于这篇论文，本文核心要点有二。其一，解析微信的后端; 第二，解析微信五年生产化运行过程中，得到实践检验的过载控制系统DAGOR的设计思路。这套系统在设计上专门考虑到微服务架构的特殊性，如果你希望为自己的微服务制定策略，那么本文无疑是一份极好的上手指南。
截至目前，微信后端共包含超过3000项移动服务，其中包括即时消息收发、社交网络、移动支付以及第三方验证等等。该平台每天接收到的外部请求量在 10^10-10^11次之间，其中每一项请求都会触发更多的内部微服务请求，这意味着微信后端整体每秒需要处理数亿次请求。
微信的微服务系统能够在微信业务系统中的2万多台设备上运行超过3000项服务。而随着微信的广泛普及，这一数字仍然不断增加……伴随着微信的不断发展，微服务系统一直在快速迭代并进行服务更新。举例来说，从2018年3月到5月，微信的微服务系统每天平均经历近千次变化。
微信将其微服务分类为“入口跳转”服务（用于接收外部请求的前端服务）、“共享跳转”服务（中间层协调服务）以及“基本服务”（不向任何其它服务扇出，因此可充当请求接收方的服务）。
图：用于存储微信入口服务内操作执行业务优先级的哈希表
当过载控制被设定为业务优先级n时，所有来自n+1等级的请求都将被放弃。这种方式对于混合型工作负载来说效果良好，但假定我们面对的是大量付款请求，而所有请求都具有相同的优先级（假定为p），那么一旦系统遭遇过载，我们就需要调整过载阈值以实现轻载，即将过载阈值变更为p-1。而一旦检测到轻载，过载阈值将再次增加至p，这时我们将重新面对过载状态。因此，要在大量具有相同优先级的请求引发超载时停止这种无意义的转换，我们需要采用超越业务优先级的细粒度调整。
微信对此拿出了一种良好的解决方案。其增加了基于用户ID的第二层接纳控制机制。
“User priority is dynamically generated by the entry service through a hash function that takes the user ID as an argument. Each entry service changes its hash function every hour. As a consequence, requests from the same user are likely to be assigned to the same user priority within one hour, but different user priorities across hours.”（用户优先级由入口服务通过以用户ID为参数的哈希函数动态生成。每项入口服务每小时变更一次其哈希函数，因此来自同一用户的请求很可能在一小时之内被分配予相同的用户优先级，但在数小时内被分配予不同的用户优先级。）
这就提供了公平性，同时亦能够在相对较长的时间周期内为个人用户提供一致的使用体验。另外，其还有助于解决后续过载问题，因为来自被分配予高优先级用户的请求更有可能在整体调用图中得到及时处理。
将业务优先级与用户优先级结合起来，即可为每个业务优先级提供配合128种用户优先级的复合接纳级别。
图：DAGOR过载控制工作流
实验
DAGOR设计有效性的最佳证明，在于其已经在微信的生产环境中拥有长达五年的良好运作记录。不过这无法为学术论文提供必要的图表，因此我们进行了一组模拟实验。下图突出显示了基于排队时间——而非响应时间——的过载控制成效。在后续过载的情况下，这种收益最为明显（如图（b）所示）。
图：不同工作负载类型下的过载控制
最后，在公平性方面，CoDel在高压场景下更倾向于使用扇出量较小的服务，而DAGOR则在各类请求当中表现出大致相同的成功率水平。
"
图：过载控制的公平性
构建处有系统中的三项经验
即使你不打算完全按照微信的方式使用DAGOR，作者仍然总结出了三项宝贵的实践经验：
?超大规模微服务架构下的过载控制必须在每项服务中实现分散与自治。
?过载控制应当考虑到各种反馈机制（例如DAGOR的协调接纳控制），而非仅仅依赖于开环启发式机制。
?应当通过对实际工作负载的处理行为进行分析，从而探索过载控制的设计思路。
腾讯旗下的微信从一个通信工具变成一个庞大平台，究竟经历了什么？微信开发者团队最近一篇论文“Overload Control for Scaling WeChat Microservices（超大规模微信微服务中的过载控制）”透露了部分细节，主要讲述了微服务的过载控制。
基于这篇论文，本文核心要点有二。其一，解析微信的后端; 第二，解析微信五年生产化运行过程中，得到实践检验的过载控制系统DAGOR的设计思路。这套系统在设计上专门考虑到微服务架构的特殊性，如果你希望为自己的微服务制定策略，那么本文无疑是一份极好的上手指南。
截至目前，微信后端共包含超过3000项移动服务，其中包括即时消息收发、社交网络、移动支付以及第三方验证等等。该平台每天接收到的外部请求量在 10^10-10^11次之间，其中每一项请求都会触发更多的内部微服务请求，这意味着微信后端整体每秒需要处理数亿次请求。
微信的微服务系统能够在微信业务系统中的2万多台设备上运行超过3000项服务。而随着微信的广泛普及，这一数字仍然不断增加……伴随着微信的不断发展，微服务系统一直在快速迭代并进行服务更新。举例来说，从2018年3月到5月，微信的微服务系统每天平均经历近千次变化。
微信将其微服务分类为“入口跳转”服务（用于接收外部请求的前端服务）、“共享跳转”服务（中间层协调服务）以及“基本服务”（不向任何其它服务扇出，因此可充当请求接收方的服务）。
图：用于存储微信入口服务内操作执行业务优先级的哈希表
当过载控制被设定为业务优先级n时，所有来自n+1等级的请求都将被放弃。这种方式对于混合型工作负载来说效果良好，但假定我们面对的是大量付款请求，而所有请求都具有相同的优先级（假定为p），那么一旦系统遭遇过载，我们就需要调整过载阈值以实现轻载，即将过载阈值变更为p-1。而一旦检测到轻载，过载阈值将再次增加至p，这时我们将重新面对过载状态。因此，要在大量具有相同优先级的请求引发超载时停止这种无意义的转换，我们需要采用超越业务优先级的细粒度调整。
微信对此拿出了一种良好的解决方案。其增加了基于用户ID的第二层接纳控制机制。
“User priority is dynamically generated by the entry service through a hash function that takes the user ID as an argument. Each entry service changes its hash function every hour. As a consequence, requests from the same user are likely to be assigned to the same user priority within one hour, but different user priorities across hours.”（用户优先级由入口服务通过以用户ID为参数的哈希函数动态生成。每项入口服务每小时变更一次其哈希函数，因此来自同一用户的请求很可能在一小时之内被分配予相同的用户优先级，但在数小时内被分配予不同的用户优先级。）
这就提供了公平性，同时亦能够在相对较长的时间周期内为个人用户提供一致的使用体验。另外，其还有助于解决后续过载问题，因为来自被分配予高优先级用户的请求更有可能在整体调用图中得到及时处理。
将业务优先级与用户优先级结合起来，即可为每个业务优先级提供配合128种用户优先级的复合接纳级别。
图：DAGOR过载控制工作流
实验
DAGOR设计有效性的最佳证明，在于其已经在微信的生产环境中拥有长达五年的良好运作记录。不过这无法为学术论文提供必要的图表，因此我们进行了一组模拟实验。下图突出显示了基于排队时间——而非响应时间——的过载控制成效。在后续过载的情况下，这种收益最为明显（如图（b）所示）。
图：不同工作负载类型下的过载控制
最后，在公平性方面，CoDel在高压场景下更倾向于使用扇出量较小的服务，而DAGOR则在各类请求当中表现出大致相同的成功率水平。
" 图：过载控制的公平性
构建处有系统中的三项经验
即使你不打算完全按照微信的方式使用DAGOR，作者仍然总结出了三项宝贵的实践经验：
?超大规模微服务架构下的过载控制必须在每项服务中实现分散与自治。
?过载控制应当考虑到各种反馈机制（例如DAGOR的协调接纳控制），而非仅仅依赖于开环启发式机制。
?应当通过对实际工作负载的处理行为进行分析，从而探索过载控制的设计思路。
