Soul网关源码探秘《十七》 - 熔断/降级/限流

今天主要研究一下熔断/降级/限流这三个概念各自要解决的问题以及适用的场景。

服务熔断和服务降级是解决服务雪崩的手段，所以先来了解一下什么是服务雪崩。

服务雪崩

假设在一个电商系统中，评论服务出现故障，那么所有依赖于评论服务的其他服务（例如商品详情服务）都将不可用。即一个服务失败，导致整条链路的服务都失败，这就是服务雪崩。

熔断

当评论服务不可用或响应过慢时，常理来说，应该等到评论服务恢复可用再来调用。可事实上是，后续每个评论服务请求，还是会等待评论服务响应，这可能会消耗商品详情服务的宝贵资源，导致资源耗尽，从而使商品详情服务无法处理其他请求。而服务熔断就是解决这个问题的。

当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

soul网关中的熔断插件就是实现的这种短路器模式。当请求服务的失败次数或者失败比例超过设定的阈值，网关中的短路器就会开启。接收到新的请求后，网关并不会真的转发到服务中，而是直接给客户端返回一个异常结果，告知客户端目前服务不可用。一定时间之后，短路器会转变到半开半闭的状态。会逐步放开一部分流量到真实的服务中，如果请求返回了正确的信息，则后面逐步放开请求流量，直至短路器关闭。

降级

服务熔断虽然避免了许多无用的调用，但是商品详情服务还是会因为相对不太重要的评论服务失败而不可用，那是不合理的。现在想要在评论服务请求失败时，不影响商品详情服务的正常使用。这时候就需要使用服务降级了。

服务降级场景

1. 当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，增加响应速度。（开关降级）
2. 当下游的服务因为某种原因不可用，上游主动调用本地的一些降级逻辑，避免卡顿，迅速返回给用户。（熔断降级）

限流

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据）。

限流算法

漏桶(Leaky Bucket)

漏桶(Leaky Bucket)算法思路很简单，水(请求)先进入到漏桶里，漏桶以一定的速度出水(接口有响应速率)，当水流入速度过大会直接溢出(访问频率超过接口响应速率)，然后就拒绝请求。可以看出漏桶算法能强行限制数据的传输速率。

令牌桶算法(Token Bucket)

令牌桶算法(Token Bucket)和 Leaky Bucket 是效果一样但方向相反的算法。随着时间流逝，系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反，有个水龙头在不断的加水)。如果桶已经满了就不再加了。新请求来临时，会拿走一个Token，如果没有Token可拿了就阻塞或者拒绝服务。

令牌桶的另外一个好处是可以方便的改变速度。一旦需要提高速率，则按需提高放入桶中的令牌的速率。

另外通过维护一个原子性的计数器也可以粗暴的实现限流的目的。