对微信《Scalable Overload Control for Large-scale Microservice Architecture》论文的解读

这几年微服务大行其道，随之而来也产生了很多新的话题：

• 服务注册和发现（常见解决方案如Consul, ZK, etcd)
• 服务过载处理: 熔断和降级 （如Hystrix)
• …

微信《Scalable Overload Control for Large-scale Microservice Architecture》这篇论文就是专门针对服务过载后的处理， 提出了他们的解决方案。

在服务过载时， 一个常见的解决方案是限流。常见的限流方案是比较简单粗暴的： 如果一个服务无法处理所有的请求， 那么就随机抛弃一部分请求。

微信团队认为这种粗暴的处理方式并不能缓解整个系统的负载， 并且浪费了很多计算资源，比如以下场景：

假设api层处理一个客户端请求时，依赖N个下游服务， 而这N个下游服务都处于过载状态， 以p的概率随机拒绝服务， 那么这个客户端请求最后被成功处理的概率就是(1-p)^N。 如果P和N很大， 那么这个请求很可能没有被成功处理，但是却浪费了很多计算资源（比如N-1个服务都处理了这个请求，但是1个服务拒绝了）。

微信是怎么解决这个问题的呢？ 主要是以下两点：

1. 面向业务的准入控制
2. 面向用户的准入控制

下面就来详细说说这两点分别是什么意思。

面向业务的准入控制

微信根据业务重要性和用户体验，对一些常见的业务定义了优先级:

比如两个同样依赖红包服务的业务：发红包和查看红包历史记录， 他们的业务优先级是不一样的， 发红包明显要高于查看历史记录。 因此，微信在入口服务层通过预定义的hash表ÿ