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