2021-04-29

Alibaba Sentinel服务容错的可选方案

在实际的开发环境中，我们总是会面对各种各样的问题，网络问题，自然灾害，不可抗力因素以及代码的可靠性，不做服务容错，当项目正式部署上线，一个不大的故障都可能导致大范围的服务不可用，单体项目尚且如此，分布式项目面临的情况更加严峻。

这幅图描述了一个经典的情形，服务雪崩。一开始只是一个底层服务出现了一个故障，特别是当这个服务没有直接挂掉，而是处于缓慢严重超时的这样一个情况下，调用这个服务的其他服务，一旦调用这个服务，由于迟迟没有得到响应，也进入了阻塞状态，渐渐导致所有关联的上层服务全部阻塞，知道超过服务器承载能力的时候就会发生服务雪崩。
这就是没有做服务容错带来的可怕后果，目前市面上主流的服务容错的解决方案有Resillence4j、Hystrix、Sentinel、Turbine，其中Hystrix是由老牌厂商netflix提供，目前也已经不维护了，Sentinel是由阿里提供的，有较好的中文支持，所以这里就以Sentinel来举例。
服务容错的集中简单模式包括：
超时：最简单的容错方式，在调用方为服务调用设置一个超时时间，避免无限制的等待下游系统造成的线程堆积
限流：在提供方一端限制进入的流量，保证服务不会因为超负荷流量而崩溃。
仓壁模式：资源隔离手段。在调用方进行资源隔离，比如使用线程池，保证消耗的资源有上限，避免无限量调用资源占用其他请求的资源。
熔断器：在调用方进行控制，根据策略定义失败情况，失败数字达到阈值时打开熔断器，不再调用底层服务，熔断窗口（一段时间过后）达到时，释放一个请求进入底层，如果请求执行成功则关闭熔断器，正常调用，如果请求失败则继续保持熔断器打开直到下一个熔断窗口达到。
解决方案也就是基于这些模式来进行扩展整合的。
Sentinel提供的解决办法主要包括：限流，熔断，降级这三种。这里在你的Spring Boot 项目中引入Sentinel的依赖，配置连接sentinel-dashboard，sentinel-dashboard是Sentinel服务容错解决方案的UI工具，可以帮你你去更好的调试适合你的服务容错方案。

限流：上图就是一个限流方案的选项，主要包括阈值类型，QPS、线程数。QPS是每秒的请求数量，这个的控制会更简单直观，单机阈值则是指，每秒允许的一个QPS数量（以下皆以QPS选择为基础），流控模式分三种，直接：对当前服务本身有效。关联：A关联B，当B达到了上面的单机阈值是，对A进行限流。链路以链路的起始作为计算，只结算链路开头的服务的请求数量。流控效果是指在触发了流控模式形成的规则之后的一个请求的变化。快速失败：最简单直观，直接挂掉。Warm Up:预热，需设置QPS和时长，这里的QPS是指在这个时长结束后服务会达到的最大QPS，这里有一个默认参数，冷加载因子，默认值为三，依据这个指和最后要达到的QPS可以计算出一个刚开始的QPS=最后要达到的QPS/冷加载因子。这个服务会有一个预热的过程，会在这个时间里，从开始的QPS跑到最后要达到的QPS。这样做的一个好处是可以给服务器一个缓慢启动的过程避免一下子的服务压力过大导致服务器挂掉。排队等待：需要设置将阈值模式设置为QPS才能生效。这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
然后是熔断，熔断的一个基本概念如图

这里能看到熔断的一个基本模式，他不是失败就垄断，而是在一个时间段里失败达到多少次则熔断，并且会有一个熔断窗口，在你熔断多少时间后，再次发送请求去判断服务的状态，这样的设置在有服务集群的情况下可以在某一个服务出问题之后不影响整体的运行，而如果这个服务只是短暂的阻碍的情况下，能够自动修复，避免服务空耗，节约资源。这里熔断也分集中模式，根据错误请求的数量，比列以及一个RT模式(慢请求，需要定义请求超标的毫秒值，默认超标的比列须达到100%)。这里就不细讲，将项目装配好之后可以自己测试。
降级：简单来说就是提供一个后备服务，需要添加@SentinelResource(value = “helloB”,fallback = “sayHelloFallback”)第一个value服务的方法名，第二个fallback 的值这是你提供的后备方法的方法名，需要注意要同参数。这样可以在你的服务挂掉之后走向另一个备用方案，或者做个简单的提醒。
除此之外Sentinel还提供了其他的许多方案，可以根据热点参数限流，系统规则，授权规则等等来进行限流，有兴趣可以去官网Sentinel.io去看一下。