一、背景
微服务熔断方案，只接触过 Hystrix，看到日志出现 HystrixException 相关异常，就知道要么是被调用服务挂了要么就是被调用服务处理超时了。也很少有人写被调用服务不可用后的默认返回方法，因为绝大多数服务间的调用是要依赖被调用方返回的数据，没这个数据走不下去了，只能抛异常统一处理了。
微服务限流方案，使用过 Guava RateLimiter 或者 Redis ，耦合业务接口，只能想到哪个业务不重要写到哪个业务里，类似信号量方案，限制 QPS，超量快速返回错误信息， 减少对系统和存储的冲击。
在学习 Soul 网关支持接入四种限流方案时，发现热度最高的可能是 Sentinel，又发现 Sentinel 顾名思义其实又和网关有的功能重叠，也就是网关组件和流量控制组件都为了服务治理，接入业务服务，两者也都提供了控制台管理。感觉国外的开源软件把核心部分开源出来，类似控制台等周边功能保留或者没有（如 kafka），给使用者更多的想象空间和扩展空间，甚至可以产出很多靠封装开源软件提供更好的一体化企业解决方案的公司。而国内公司的开源产品是尽量功能全，解决方案完善，争取让更多的企业能快速应用起来。
二、Sentinel
开源软件现在都很注重社区的建设，参与者也很多，所以社区建设完善，形成良好的循环。文档质量很高，都可以从文档入手，其实这个博客更多的像是日记了，记录给自己看的，学习 Sentinel 也不用到处找资料，看官网、跑例子、看代码基本就上手了。学习了微服务其中的一个开源组件（像网关、注册中心、配置中心、服务调用等），开源系统和微服务的套路基本就熟悉了，再上手其他组件很快，就不用到处看人家的博客了。
先看 github 上的两张图
第一张是功能架构图的四大块：
- 最右侧蓝色的纵向：是可以接入的微服务生态。
- 最上面的黄色：是控制台，实时监控、机器发现（服务发现、还带有注册中心的作用，其实各个组件要么依赖注册中心，要么自己也想做注册中心，因为要和业务服务打交道，不监视它们怎么能好好治理）、规则配置。实时监控那块挺好的，可以好好学习，借鉴到 Soul 网关里，网关是流量的入口，最好能看到流量情况。
- 中间的绿色：是嵌入到业务服务的 Sentinel 功能，看到如此多的功能，会发现 Sentinel 不仅仅是 Hystrix 。从官网的定义也能看出来。
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel: 分布式系统的流量防卫兵（the Sentinel of Your Microservices）
- 最下面的紫色：是配置存储，可以看出来流量的管理规则可以存储在注册中心、配置中心。这一点和 Soul 也不同，Soul是使用 MySQL，其实我也感觉Soul实践起来配置可以不用存储在数据库里，使用注册中心或者配置中心是不是更好。
第二张是融合周边生态系统情况：
发现网关、云原生、微服务、配置中心、注册中心、甚至 RocketMQ 都有，可以控制消费速度？
再来看一张和 Hystrix 的对比图：
Sentinel 采用信号量隔离，其实线程池隔离应用场景不多，过多的线程池还会增加线程切换开销，信号量相当于流量请求拿到了信号量才能继续下去。
令牌桶：控制访问速率 QPS，比如1s中产生1000个令牌，那么大约在1000QPS
信号量：控制并发量，也就是竞态资源允许同时被访问的最大并发量，这个资源可以是Java代码中的方法或者代码块（其实Sentinel中资源的概念也是指的这个）。更像是控制 TPS，但不能比较精准的控制流量，和接口处理时间有关。
