![](https://img.kancloud.cn/14/cb/14cb1154899af8372d6ee10d45a325e9_1086x428.png) ## 什么是 Sentinel >随着微服务的流行,服务和服务之间的稳定性变得越来越重要。 Sentinel 以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 ## Sentinel 的特征 * **丰富的应用场景**:**Sentinel承接了阿里巴巴近 10 年的**双十一大促流量**的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、实时熔断下游不可用应用等。 * **完备的实时监控**:**Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况。 * **广泛的开源生态**:Sentinel 提供开箱即用的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。 * **完善的 SPI 扩展点**:Sentinel 提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点,快速的定制逻辑。例如定制规则管理、适配数据源等。 ![](https://img.kancloud.cn/5a/bd/5abdbe6ca1b50640c798670742b506d1_1365x634.png) ## Sentinel 的开源生态 ![](https://img.kancloud.cn/de/a3/dea3c4a2fe8731e0af0cdc9ca00ef082_1447x783.png) ## Sentinel与Hystrix > Hystrix 已经停止开发。Hystrix 不再维护可能也是 Sentinel 能快速进入大家眼球的原因之一。Hystrix 虽然不再维护,但依然开源,且 Hystrix 已经很稳定,不会因为不维护就不可用,只是不会再有更新。相比 Hystrix,Sentinel 更易于上手,Sentinel 是国内开源的项目,官方有提供中文文档,对国内的开发者较为友好,并且文档介绍得也很全面。 ![](https://img.kancloud.cn/f9/9a/f99a7290af1d64bb4a38e343a06b246a_858x629.png) ## Sentinel使用方式 * 手动使用代码配置 * sentinel控制台动态配置 * 默认情况下sentinel不对数据持久化,需要自己持久化。 ## sentinel控制台 -> Sentinel dashboard 使用 ![](https://img.kancloud.cn/97/5e/975e60e4bac56c71213a0cedb0f8c7e4_1183x652.png) ## 启动sentinel-dashboard ![](https://img.kancloud.cn/19/3c/193cf6fecdf75123346d9ecacb444a40_1610x876.png) ## 访问sentinel-dashboard ### [http://127.0.0.1:8989/](http://127.0.0.1:8989/) ### sentinel/sentinel ### 登录页面 ![](https://img.kancloud.cn/93/e5/93e59cc065413ce08a30a26c17ec005c_1920x606.png) ### 登录成功 ![](https://img.kancloud.cn/96/17/96174ff06e1225ace15f6b0245179426_1901x662.png) ### 限流算法 假设1s内可以处理3000个事务。 * **固定窗口**:维护一个计数器,如果在窗口时间单元内且不超过3000,则允许请求。存在的问题可能是流量高峰集中在第一秒内的最后10ms内,第二秒的最初10ms内,这样有可能在20ms中要处理6000个事务。 * **滑动窗口**:细分时间单元,划分多个小窗口,基于时间滑动,在总窗口内的请求总数不能超过3000,可以解决固定窗口的问题。但是缺点是无法解决小窗口内的请求集中的问题,如果10ms内涌入3000,可能造成服务被流量压垮。 窗口划分太细容易导致正常的请求被误限流,窗口太粗,导致限流无法起到很好的作用。所以一般的平滑策略是多层次限流,设置多条限流策略使用滑动窗口限制请求速率,使用细粒度固定窗口防止请求集中的问题。为了优化窗口算法的问题,出现了漏桶算法和令牌桶算法。 * **令牌桶算法**:有一个固定容量的桶,桶里存放着令牌(token)。桶一开始是空的,token以一个固定的速率r往桶里填充(本次和上次请求时间戳计算),直到达到桶的容量,多余的令牌将会被丢弃。每当一个请求过来时,就会尝试从桶里移除一个令牌,如果没有令牌的话,请求无法通过,优点是对突发的流量可以有适当的弹性,但是要注意令牌桶的总量不能超过服务的处理能力。 * **漏桶算法**:有一个固定容量的桶,有水流进来,也有水流出去。对于流进来的水来说,我们无法预计一共有多少水会流进来,也无法预计水流的速度。但是对于流出去的水来说,这个桶可以固定水流出的速率(本次和上次请求时间戳计算)。而且,当桶满了之后,多余的水将会溢出,优点是即便突发流量来临,也会保持一定的速率去处理,大量的流量不会压垮服务。 ### 限流规则 * 时间粒度:时间窗口的大小、令牌的投放速率、漏桶的消费速率。对于突发流量高的,时间粒度要小一点,对于突发流量少的,时间窗口大一点。 * 接口粒度:集群访问粒度、服务访问粒度、服务接口访问粒度。 * 最大限流值:不大于压测的TPS并且不小于业务的预期流量,针对监控数据做一些适当调整。