Spring Cloud Alibaba入门实践(六)-服务容错Sentinel

上篇博客通过引入了Fegin，再次优化了服务之间的交流方式，简化了远程调用的代码逻辑和调用风格，实现了服务与服务之间的相互调用。

这时候问题来了，不管部署在哪里，服务肯定是无法做到100%可用的，如果百分之百可用，又何必有那么多的备份集群等方案。不管是网络问题还是服务自身问题，当服务提供方出现故障，无法在正常时间内返回响应时，作为服务调用方的我们，应该怎么处理？

首先需要了解到，一个服务是怎么拖垮一整条服务链路的？

在分布式系统中 ，如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪。 而由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩效应” 。

那么就要做好足够的容错，保证在一个服务发生问题，不会影响到其它服务的正常运行。也就是"雪落而不雪崩"。

常见的容错方案有隔离、超时、限流、熔断、降级 。

隔离

它是指将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。当有故障发生时，能将问题和影响隔离在某个模块内部，而不扩散风险，不波及其它模块，不影响整体的系统服务。常见的隔离方式有:线程池隔离和信号量隔离。

超时

在上游服务调用下游服务的时候，设置一个最大响应时间，如果超过这个时间，下游未作出反应，就断开请求，释放掉线程。

限流

限流就是限制系统的输入和输出流量已达到保护系统的目的。为了保证系统的稳固运行,一旦达到的需要限制的阈值,就需要限制流量并采取少量措施以完成限制流量的目的。

熔断

在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断，可以简单的理解成保险丝，电力过大，保险丝就熔断开，起到保护作用。

降级

降级其实就是为服务提供一个兜底方案，一旦服务无法正常调用，就使用兜底方案，配合上这种方案，对用户来说是比较友好的。

重复造轮子的事，我们还是不做了，能够选择引入的容错组件也挺多的，比如Hystrix ，Resilience4J ，Sentinel。

接下来就是把Sentinel组件引入整个微服务项目中，实现容错，提高可用性。