高可用：降级-熔断-限流-Hystrix

0.高可用

0.0 什么是高可用？可用性的判断标准是啥？

高可用描述的是一个系统在大部分时间都是可用的，可以为我们提供服务的。高可用代表系统即使在发生硬件故障或者系统升级的时候，服务仍然是可用的。

一般情况下，我们使用多少个 9 来评判一个系统的可用性，比如 99.9999% 就是代表该系统在所有的运行时间中只有 0.0001% 的时间是不可用的，这样的系统就是非常非常高可用的了！当然，也会有系统如果可用性不太好的话，可能连 9 都上不了。

除此之外，系统的可用性还可以用某功能的失败次数与总的请求次数之比来衡量，比如对网站请求 1000 次，其中有 10 次请求失败，那么可用性就是 99%。

0.1 哪些情况会导致系统不可用？

• 黑客攻击；
• 硬件故障，比如服务器坏掉。
• 并发量/用户请求量激增导致整个服务宕掉或者部分服务不可用。
• 代码中的坏味道导致内存泄漏或者其他问题导致程序挂掉。
• 网站架构某个重要的角色比如 Nginx 或者数据库突然不可用。
• 自然灾害或者人为破坏。
• …

1.熔断

1.1 熔断来源

我们家用电闸上都有保险丝模块，当电压出现短路问题时，自动跳闸，此刻电路主动断开，我们的电器就会收到保护。否则，不能断开，后果不堪设想。

保险丝就是一个自我保护装置，保护整个电路。

1.2 分布式系统中的熔断

在分布式系统中，我们往往需要依赖下游服务，不管是内部系统还是第三方服务，如果下游出现问题，我们还是盲目地去请求，及时失败了多次，还是傻傻的去请求，去等待。

这样，一是增加了整个链路的请求时间
第二，下游系统本身就出现了问题，不断的请求又把系统问题加重了，恢复困难。

1.3 熔断的作用

熔断模式可以防止应用程序不断地尝试可能超时和失败的服务，能达到应用程序执行而不必等待下游服务修正错误服务。

熔断器模式最牛的是能让应用程序自我诊断下游系统的错误是否已经修正，如果没有，不放量去请求，如果请求成功了，慢慢的增加请求，再次尝试调用。

1.4 像不像代理模式？

熔断器模式像那些，容易导致错误操作的，一种代理
这种代理能够记录调用发生的错误次数，并根据次数，自我决定是否继续调用还是立刻返回错误。

比如说A服务调用B服务，B服务是下游的服务提供，或者是第三方服务，容易发生问题。这样既能防止不断的调用，是下游服务更坏，保护了下游方，还能降低自己的执行成本，快速的响应，减少延迟，增加吞吐量。
业内目前流行的熔断器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix。

2. 降级

2.1 降级的本质

降级就是为了解决资源不足和访问量增加的矛盾

在有限的资源情况下，为了能抗住大量的请求，就需要对系统做出一些牺牲，有点“弃卒保帅”的意思。放弃一些功能，保证整个系统能平稳运行

2.2 降级牺牲的是什么？

强强一致性变成最终一致性
大多数的系统是不需要强一致性的。
强一致性就要求多种资源的占用，减少强一致性就能释放更多资源
这也是我们一般利用消息中间件来削峰填谷，变强一致性为最终一致性，也能达到效果

干掉一些次要功能
停止访问不重要的功能，从而释放出更多的资源
举例来说，比如电商网站，评论功能流量大的时候就能停掉，当然能不直接干掉就别直接，最好能简化流程或者限流最好
简化功能流程。把一些功能简化掉

2.3 降级的注意点

对业务进行仔细的梳理和分析
哪些是核心流程必须保证的，哪些是可以牺牲的
什么指标下能进行降级
吞吐量、响应时间、失败次数等达到一个阈值才进行降级处理
如何降级
降级最简单的就是在业务代码中配置一个开关或者做成配置中心模式，直接在配置中心上更改配置，推送到相应的服务。

3.限流

3.1 限流的目的

通过对并发访问进行限速。

3.2 限流有哪些行为

拒绝服务
最简单的方式，把多余的请求直接拒绝掉
做的高大上一些，可以根据一定的用户规则进行拒绝策略。
服务降级
降级甚至关掉后台的某些服务。
特权请求
在多租户或者对用户进行分级时，可以考虑让一些特殊的用户有限处理，其他的可以考虑干掉
延时处理
可以利用队列把请求缓存住。削峰填谷。

3.3 限流的实现方式

3.3.1计数器

最简单的实现方式 ，维护一个计数器，来一个请求计数加一，达到阈值时，直接拒绝请求。
一般实践中用 ngnix + lua + redis 这种方式，redis 存计数值。

3.3.2固定窗口计数器算法

该算法规定我们单位时间处理的请求数量。固定窗口计数器算法概念如下：
将时间划分为多个窗口；

• 在每个窗口内每有一次请求就将计数器加一；
• 如果计数器超过了限制数量，则本窗口内所有的请求都被丢弃当时间到达下一个窗口时，计数器重置。

固定窗口计数器是最为简单的算法，这种限流算法无法保证限流速率，因而无法保证突然激增的流量。考虑如下情况：限制 1 秒内最多通过 5 个请求，在第一个窗口的最后半秒内通过了 5 个请求，第二个窗口的前半秒内又通过了 5 个请求。这样看来就是在 1 秒内通过了 10 个请求。

3.3.3 滑动窗口计数器算法

• 该算法算的上是固定窗口计数器算法的升级版。滑动窗口计数器算法概念如下：
• 将时间划分为多个区间；
• 在每个区间内每有一次请求就将计数器加一维持一个时间窗口，占据多个区间；
• 每经过一个区间的时间，则抛弃最老的一个区间，并纳入最新的一个区间；
• 如果当前窗口内区间的请求计数总和超过了限制数量，则本窗口内所有的请求都被丢弃。

滑动窗口计数器是通过将窗口再细分，并且按照时间"滑动"，这种算法避免了固定窗口计数器带来的双倍突发请求，但时间区间的精度越高，算法所需的空间容量就越大。

3.3.4 漏斗模式

漏桶算法概念如下：

• 将每个请求视作"水滴"放入"漏桶"进行存储；
• “漏桶"以固定速率向外"漏"出请求来执行如果"漏桶"空了则停止"漏水”；
• 如果"漏桶"满了则多余的"水滴"会被直接丢弃。

漏桶算法多使用队列实现，服务的请求会存到队列中，服务的提供方则按照固定的速率从队列中取出请求并执行，过多的请求则放在队列中排队或直接拒绝。
漏桶算法的缺陷也很明显，当短时间内有大量的突发请求时，即便此时服务器没有任何负载，每个请求也都得在队列中等待一段时间才能被响应。

3.3.5 令牌桶

令牌桶算法概念如下：

• 令牌以固定速率生成；
• 生成的令牌放入令牌桶中存放，如果令牌桶满了则多余的令牌会直接丢弃，当请求到达时，会尝试从令牌桶中取令牌，取到了令牌的请求可以执行；
• 如果桶空了，那么尝试取令牌的请求会被直接丢弃。

令牌桶算法既能够将所有的请求平均分布到时间区间内，又能接受服务器能够承受范围内的突发请求，因此是目前使用较为广泛的一种限流算法。

3.4 限流的一些注意点

限流越早设计约好，架构成型后，不容易加入
限流模块不要成为系统的瓶颈，性能要求高
最好有个开关，可以直接介入
限流发生时，能及时发出通知事件
限流发生时，给用户提供友好的提示 。

4. 三者区别

熔断强调的是服务之间的调用能实现自我恢复的状态；
限流是从系统的流量入口考虑，从进入的流量上进行限制，达到保护系统的作用。限流是从用户访问压力的角度来考虑如何应对系统故障。
降级，是从系统内部的平级服务或者业务的维度考虑，流量大了，可以干掉一些，保护其他正常使用。降级是从系统功能优先级的角度考虑如何应对系统故障。
熔断是降级方式的一种；
降级又是限流的一种方式；
三者都是为了通过一定的方式去保护流量过大时，保护系统的手段。
降级的目的在于应对系统自身的故障，而熔断的目的在于应对当前系统依赖的外部系统或者第三方系统的故障。

5. 其它方式

5.1 排队

另类的一种限流，类比于现实世界的排队。玩过英雄联盟的小伙伴应该有体会，每次一有活动，就要经历一波排队才能进入游戏。

5.2 集群

相同的服务部署多份，避免单点故障。
先拿常用的 Redis 举个例子！我们如何保证我们的 Redis 缓存高可用呢？答案就是使用集群，避免单点故障。当我们使用一个 Redis 实例作为缓存的时候，这个 Redis 实例挂了之后，整个缓存服务可能就挂了。使用了集群之后，即使一台 Redis 实例，不到一秒就会有另外一台 Redis 实例顶上。

5.3 超时和重试机制

一旦用户的请求超过某个时间得不到响应就结束此次请求并抛出异常。 如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法在处理请求。
另外，重试的次数一般设为 3 次，再多次的重试没有好处，反而会加重服务器压力（部分场景使用失败重试机制会不太适合）。

5.4 异步调用

异步调用的话我们不需要关心最后的结果，这样我们就可以用户请求完成之后就立即返回结果，具体处理我们可以后续再做，秒杀场景用这个还是蛮多的。但是，使用异步之后我们可能需要 适当修改业务流程进行配合，比如用户在提交订单之后，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功。除了可以在程序中实现异步之外，我们常常还使用消息队列，消息队列可以通过异步处理提高系统性能（削峰、减少响应所需时间）并且可以降低系统耦合性。

5.5 使用缓存

如果我们的系统属于并发量比较高的话，如果我们单纯使用数据库的话，当大量请求直接落到数据库可能数据库就会直接挂掉。使用缓存缓存热点数据，因为缓存存储在内存中，所以速度相当地快！

5.6 其它方式

• 核心应用和服务优先使用更好的硬件
• 监控系统资源使用情况增加报警设置。
• 注意备份，必要时候回滚。
• 灰度发布： 将服务器集群分成若干部分，每天只发布一部分机器，观察运行稳定没有故障，第二天继续发布一部分机器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可
• 定期检查/更换硬件： 如果不是购买的云服务的话，定期还是需要对硬件进行一波检查的，对于一些需要更换或者升级的硬件，要及时更换或者升级。
• …(想起来再补充！也欢迎各位欢迎补充！)

6 常见方案

一文带你了解SpringCloud的限流、降级和熔断——Hystrix！

7 总结

参考

降级-熔断-限流-傻傻分不清楚
分布式服务限流实战，已经为你排好坑了
限流的算法有哪些？
JavaGuide-高可用