软件架构-服务限流降级熔断机制详解

大部分老铁都没用过hystrix，一般来说能用到hystrix的公司都是比较大型的互联网公司， 服务的限流，降级，熔断，超时这些东西很多老铁经常听说，在一些技术演讲技术大会上，听一些大牛演讲常说服务限流，熔断，降级这些东西，很多公司的流量，性能，并发达不到那么大，对于高可用没有高的要求，用到这些技术机会很少，所以老铁对今天的内容很陌生，非常的感兴趣，确实这是技术BAT用到最多的技术。所以今天一起探秘，看起来很牛逼的技术让他技术的落地，能彻底的了解掌握这门技术。

分布式系统中，会出现哪些问题？（一）

• ① 雪崩效应

分布式系统集群系统中一定会遇到的一个问题：服务雪崩效应 或者叫级联效应 那么什么是服务雪崩效应呢？ 在一个高度服务化的系统中,我们实现的一个业务逻辑通常会依赖多个服务,比如: 商品详情展示服务会依赖商品服务, 价格服务, 商品评论服务.

调用三个依赖服务会共享商品详情服务的线程池. 如果其中的商品评论服务不可用, 就会出 现线程池里所有线程都因等待响应而被阻塞, 从而造成服务雪崩.

服务雪崩效应：因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过 程，就叫服务雪崩效应。

• ② 导致服务不可用的原因总结有几点：程序Bug，大流量请求，硬件故障，缓存击穿

1. 【大流量请求】：在秒杀和大促开始前,如果准备不充分,瞬间大量请求会造成服务提供者的 不可用。
2. 【硬件故障】：可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的 不可访问。
3. 【缓存击穿】：一般发生在缓存应用重启, 缓存失效时高并发， 所有缓存被清空时,以及短 时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引 起服务不可用。

• 在服务提供者不可用的时候，会出现重试的情况：用户重试、代码逻辑重试

1. 【用户重试】：在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,会不断刷新页面 甚至提交表单。
2. 【代码逻辑重试】：服务调用端的会存在大量服务异常后的重试逻辑. 这些重试最终导致：进一步加大请求流量。

• ③ 根本原因：

大量请求线程同步等待造成的资源耗尽，当服务调用者使用同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了。

解决方案（二）

1. 超时机制
2. 服务限流
3. 服务熔断
4. 服务降级

• ① 超时机制

服务级联失败（服务雪崩效应）的最根本原因是：大量请求线程同步等待造成的资源耗尽那么，在不做任何处理的情况下，服务提供者不可用会导致消费者请求线程强制等待，而造成系统资源耗尽，而且，既然服务提供者已经不可用了，还在作死的请求的话，是毫无意义的。那么，如果我们加入超时机制，例如2s，那么超过2s就会直接返回了，那么这样是不是一定程度上可以抑制消费者资源耗尽的问题。

• ② 服务限流(资源隔离)

限制请求核心服务提供者的流量，使大流量拦截在核心服务之外，这样可以更好的保证核心服务提供者不出问题，对于一些出问题的服务可以限制流量访问，只分配固定线资源访问，这样能使整体的资源不至于被出问题的服务耗尽，进而整个系统雪崩那么服务之间怎么限流，怎么资源隔离了？例如通过线程池+队列的方式，通过信号量的方式。当商品评论服务不可用时, 即使商品服务独立分配的20个线程全部处于同步等待状态,也不会影响其他依赖服务的调用.

• ③ 服务熔断

远程服务不稳定或网络抖动时暂时关闭，就叫服务熔断。举个通俗易懂的例子，就跟我们现实生活中的“跳闸”一样，跳闸应该都听说过吧，比如说家里有点短路了，那是不是闸会跳掉，等你把短路的问题找到并且修复后，然后你把这个闸一送，是不是整个家庭的电路又恢复了正常。这就是熔断器。

所以，同样的道理，当依赖的服务有大量超时时，在让新的请求去访问根本没有意义，只会无畏的消耗现有资源。比如我们设置了超时时间为1s,如果短时间内有大量请求在1s内都得不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他的请求去访问这个依赖了，这个时候就应该使用熔断器避免资源浪费。

• ④ 服务降级

有服务熔断，必然要有服务降级。所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本地的fallback（回退）回调，返回一个缺省值。例如：(备用接口/缓存/mock数据)这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。

PS：这次说了雪崩的解决方案和这几种方案的介绍，下次讲讲如何通过springclud技术完成技术的落地。