人世繁华|SpringCloud在Kubernetes的最佳实践—熔断前言阿里巴巴十多年的双十一

前言阿里巴巴十多年的双十一，锤炼出来了一套业界领先的高可用技术，有一些已经商业化（云产品 PTS、AHAS），也有的开源了如：Sentinel、ChaosBlade 。我们这一系列的高可用章节也主要介绍这方面的内容。今天介绍熔断部分，即开源产品 Sentinel 的核心能力。
问题定义在一个常见的分布式应用中，一个请求先通过终端到达 Gateway ，再经过防火墙和网络负载均衡，其中还包括调用下游的其它服务和第三方应用，才能到达前端网络服务；如下图所示。
和这样一个架构一样，大家可能也会遇到如下的一些熟悉的 Case ：

瞬间洪峰流量导致系统超出最大负载， load 飙高，系统崩溃导致无法正常提供服务。
“黑马”热点数据击穿缓存， DB 被打垮，挤占正常流量。
调用端被不稳定服务拖垮，线程池被占满，导致整个调用链路卡死甚至系统雪崩
......

这些不稳定的场景可能会导致严重后果。大家可能想问：如何做到均匀平滑的用户访问？如何预防流量过大或服务不稳定带来的影响？这时候我们就要请出微服务稳定性的法宝 —— 高可用流量防护，其中重要的手段就是流量控制和熔断降级，它们是保障整个系统稳定性重要的一环。
流量控制流量是非常随机性的、不可预测的。前一秒可能还风平浪静，后一秒可能就出现流量洪峰了（例如双十一零点的场景）。然而我们系统的容量总是有限的，如果突然而来的流量超过了系统的承受能力，就可能会导致请求处理不过来，堆积的请求处理缓慢， CPU/Load 飙高，最后导致系统崩溃。因此，我们需要针对这种突发的流量来进行限制，在尽可能处理请求的同时来保障服务不被打垮，这就是流量控制。

熔断降级一个服务常常会调用别的模块，可能是另外的一个远程服务、数据库，或者第三方 API 等。例如，支付的时候，可能需要远程调用银联提供的 API；查询某个商品的价格，可能需要进行数据库查询。然而，这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况，请求的响应时间变长，那么调用服务的方法的响应时间也会变长，线程会产生堆积，最终可能耗尽业务自身的线程池，服务本身也变得不可用。

Spring Cloud 中如何做熔断？在原来的 Spring Cloud 产品族中，有自带的熔断组件 Hystrix，是 Netflix 公司提供的一个开源的组件，提供了熔断、隔离、降级的这些特性，不过 Hystrix 在 2018 年 11 月份开始，就不再迭代开发，进入维护的模式。不过好消息是也就是这一年开源了 Spring Cloud for Alibaba 产品族，其中的 Sentinel 完美的对 Hystrix 做了补充，下面针对 Sentinel 做一些基本介绍。
Sentinel 工作原理？Sentinel 以资源流量（URL、线程、本地函数、Dubbo服务等）为切入点，根据用户输入的规则，自适应的做到流量控制、熔断降级、系统负载保护等多个维度，全方位的保障系统的稳定性。并提供了一套具备丰富的应用场景、完备的实时监控、广泛的开源生态、完善灵活的 SPI 扩展点的完美的高可用解决方案产品，一个基本的原理介绍图如下，详细介绍请参考官方文档。

在使用上，针对主流框架默认提供自动适配的能力来定义需要保护的资源，并提供设施对资源进行实时统计和调用链路分析。同时， Sentinel 也提供开放的接口，方便您自定义并改变规则。