微服务保护的方案有很多比如请求限流线程隔离服务熔断这些方案或多或少都会导致服务的体验上略有下降比如请求限流降低了并发上限线程隔离降低了可用资源数量服务熔断降低了服务的完整度部分服务变的不可用或弱可用。因此这些方案都属于服务降级的方案。但通过这些方案服务的健壮性得到了提升。Sentinel 具有以下特征:丰富的应用场景Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景例如秒杀即突发流量控制在系统容量可以承受的范围、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。完备的实时监控Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据甚至 500 台以下规模的集群的汇总运行情况。广泛的开源生态Sentinel 提供开箱即用的与其它开源框架/库的整合模块例如与 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。同时 Sentinel 提供 Java/Go/C 等多语言的原生实现。完善的 SPI 扩展机制Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。接下来我们从Sentinel学习微服务的服务保护内容请求限流服务故障最重要原因就是并发太高解决了这个问题就能避免大部分故障。当然接口的并发不是一直很高而是突发的。因此请求限流就是限制或控制接口访问的并发流量避免服务因流量激增而出现故障。线程隔离当一个业务接口响应时间长而且并发高时就可能耗尽服务器的线程资源导致服务内的其它接口受到影响。所以我们必须把这种影响降低或者缩减影响的范围。线程隔离正是解决这个问题的好办法。为了避免某个接口故障或压力过大导致整个服务不可用我们可以限定每个接口可以使用的资源范围也就是将其“隔离”起来。如图所示我们给查询购物车业务限定可用线程数量上限为20这样即便查询购物车的请求因为查询商品服务而出现故障也不会导致服务器的线程资源被耗尽不会影响到其它接口。服务熔断线程隔离虽然避免了雪崩问题但故障服务商品服务依然会拖慢购物车服务服务调用方的接口响应速度。而且商品查询的故障依然会导致查询购物车功能出现故障购物车业务也变的不可用了。处理方法编写服务降级逻辑就是服务调用失败后的处理逻辑根据业务场景可以抛出异常也可以返回友好提示或默认数据。异常统计和熔断统计服务提供方的异常比例当比例过高表明该接口会影响到其它服务应该拒绝调用该接口而是直接走降级逻辑。给FeignClient编写失败后的降级逻辑有两种方式方式一FallbackClass无法对远程调用的异常做处理方式二FallbackFactory可以对远程调用的异常做处理我们一般选择这种方式。我们选择编写FallbackFactory步骤一在hm-api模块中给ItemClient定义降级处理类实现FallbackFactory步骤二在hm-api模块中的com.hmall.api.config.DefaultFeignConfig类中将ItemClientFallback注册为一个Bean步骤三在hm-api模块中的ItemClient接口中使用ItemClientFallbackFactorySentinel中的断路器不仅可以统计某个接口的慢请求比例还可以统计异常请求比例。当这些比例超出阈值时就会熔断该接口即拦截访问该接口的一切请求降级处理当该接口恢复正常时再放行对于该接口的请求。