月活 12.8 亿的微信是如何防止崩溃的？ _微信

作者：alexccdong，腾讯 WXG 后开开发工程师
一、背景最近在研究过载保护，微信是一个国民级的应用，月活用户过 10 亿，而且经常过年过节消息量暴增，服务很容易出现过载，但微信的服务一直比较稳定，他们是怎么做的呢？
本文以微信 2018 年发表于 Socc 会议上的文章，《Overload Control for Scaling Wechat Microservices》为基础，介绍了微信大规模微服务的过载保护策略，其中很多方法很有借鉴意义。
下面是对这篇文章做的一些解读。
二、过载保护基本概念1.什么是服务过载?服务过载就是服务的请求量超过服务所能承受的最大值，从而导致服务器负载过高，响应延迟加大，用户侧表现就是无法加载或者加载缓慢，这会引起用户进一步的重试，服务一直在处理过去的无效请求，导致有效请求跌 0，甚至导致整个系统产生雪崩。
2.为什么会发生服务过载？互联网天生就会有突发流量，秒杀，抢购，突发大事件，节日，甚至恶意攻击等，都会造成服务承受平时数倍的压力，微博经常出现某明星官宣结婚或者离婚导致服务器崩溃的场景，这就是服务过载。
3.过载保护的好处主要是为了提升用户体验，保障服务质量，在发生突发流量时仍然能够提供一部分服务能力，而不是整个系统瘫痪，系统瘫痪就意味着用户流失，口碑变差，夫妻吵架，甚至威胁生命安全（假如腾讯文档崩溃，这个文档正好用于救灾）。
三、微信中的过载场景微信采用的是微服务，说是微服务，其实我理解就是采用统一的 RPC 框架搭建的一个个独立的服务，服务之间互相调用，实现各种各样的功能，这也是现代服务的基本架构。毕竟谁也不想看到我朋友圈崩了，导致我聊天也不行了。
微信这边的服务是分三层，接入服务，逻辑服务，基础服务，大多数服务属于逻辑服务，接入服务比如登录，发消息，支付服务，每日请求量在 10 亿-100 亿之间，入口协议触发对逻辑服务和基础服务更多的请求，核心服务每秒要处理上亿次的请求。

文章插图

在大规模微服务场景下，过载会变得比较复杂，如果是单体服务，一个事件只用一个请求，但微服务下，一个事件可能要请求很多的服务，任何一个服务过载失败，就会造成其他的请求都是无效的。如下图所示。

文章插图

比如在一个转账服务下，需要查询分别两者的卡号，再查询 A 时成功了，但查询 B 失败，对于查卡号这个事件就算失败了，比如查询成功率只有 50%，那对于查询两者卡号这个成功率只有 50% * 50% = 25% 了，一个事件调用的服务次数越多，那成功率就会越低。
四、如何判断过载通常判断过载可以使用吞吐量，延迟，CPU 使用率，丢包率，待处理请求数，请求处理事件等等。微信使用在请求在队列中的平均等待时间作为判断标准，就是从请求到达，到开始处理的时间。
为啥不使用响应时间？因为响应时间是跟服务相关的，很多微服务是链式调用，响应时间是不可控的，也是无法标准化的，很难作为一个统一的判断依据。
那为什么不使用 CPU 负载作为判断标准呢，因为 CPU 负载高不代表服务过载，因为一个服务请求处理及时，CPU 处于高位反而是比较良好的表现。实际上 CPU 负载高，监控服务是会告警出来，但是并不会直接进入过载处理流程。
腾讯微服务默认的超时时间是 500ms，通过计算每秒或每 2000 个请求的平均等待时间是否超过 20ms，判断是否过载，这个 20ms 是根据微信后台 5 年摸索出来的门槛值。
采用平均等待时间还有一个好处，是这个是独立于服务的，可以应用于任何场景，而不用关联于业务，可以直接在框架上进行改造。
当平均等待时间大于 20ms 时，以一定的降速因子过滤调部分请求，如果判断平均等待时间小于 20ms，则以一定的速率提升通过率，一般采用快降慢升的策略，防止大的服务波动，整个策略相当于一个负反馈电路。

文章插图

五、过载保护策略一旦检测到服务过载，需要按照一定的策略对请求进行过滤，前面分析过，对于链式调用的微服务场景，随机丢弃请求会导致整体服务的成功率很低。所以请求是按照优先级进行控制的，优先级低的请求会优先丢弃。
1.业务优先级对于不同的业务场景优先级是不同的，比如登录场景是最重要的业务，不能登录一切都白瞎，另外支付消息比普通消息优先级高，因为用户对金钱是更敏感的，但普通消息又比朋友圈消息优先级高，所以在微信内是天然存在业务优先级的。