服务熔断限流与降级

核心思想：就是做不到最好的，那就退而求其次来保障服务。

为什么要熔断限流

首先，我们可以明确一件事情，无论算法，与运维再怎么优化，单台服务器的承载力，都是有限的。例如在常见的游戏服务器当中，假设我们的单机可以承载10万用户的正常游戏。某天 由于市场做了推广，导致有20万的万的用户一下子涌入进来。那么在短时间内无法扩容的情况下我们该怎么办？那就是熔断限流。我们，依旧是接纳前10万名登录的用户，后面十万的用户让他们排队去。这样看起来好像依旧会让 一半的用户不高兴，但是这也是最好的选择。如果不是这样，那么可能会导致20万，也就是全部的用户没有办法拥有一个良好的体验。

为什么要降级

举例一个应用场景，在某游戏服务中，有个实时统计的排行榜。正常情况下，请求进来了，都是实时转发给统计服务去统计的。而有天，因为做了活动，导致压力过大，统计服务器死机，或者是由于 其他因素，导致统计服务下线了。这个时候，请求进来，那么肯定是返回了NULL数据给前端，导致用户体验很差。因此我们可以做降级服务，例如最简单的，实时统计不行了，那我拉取上一次统计的缓存结果，总可以了吧。

如何实现熔断

说到熔断限流，大家在日常生活中接触最多的，应该就是令牌桶限流器了。EasySwoole 有提供一个令牌桶限流器，大家可以看文档组件库那边。那正常情况下，我们服务上线前会有一个压测。根据二八原则，服务器在负载达到百分之80左右，用户响应时间控制在200ms以下的时候，我们把 此刻的用户承载量定义为最佳的承载量，因此此时，我们就把限流器的数量限制为这个最佳承载量。降级服务也是同理，当某个服务连续访问多次，出现服务不可用的时候，我们认为该服务需要降级。