本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&券等营销中台建设
- 交易平台及数据中台等架构和开发设计
- 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
- LLM Agent应用开发
- 区块链应用开发
- 大数据开发挖掘经验
- 推荐系统项目
目前主攻市级软件项目设计、构建服务全社会的应用系统。
参考：
1 Sentinel是啥？
随微服务流行，服务和服务之间稳定性越来越重要。Sentinel是面向分布式服务架构的轻量级流量控制框架，以流量为切入点，从流控、熔断降级、系统负载保护等多维保障服务稳定性。
曾经：
如今：
可完成替代 Netflix-hystrix。
2 发展
- 2012年，Sentinel诞生，主要功能为入口流量控制
- 2013-2017年，Sentinel在阿里内部迅速发展，成为基础技术模块，覆盖所有核心场景，积累了大量流量归整场景及生产实践
- 2018年，Sentinel 开源
3 雪崩效应
系统依赖的某个服务发生延迟或故障，数秒内导致所有应用资源（线程，队列等）被耗尽，造成雪崩效应。
cascading failure（级联失效 / 级联故障）：
4 容错方案
4.1 超时模式
最常见的容错模式。
常见的有设置网络连接超时时间，一次RPC的响应超时时间。
主要解决当依赖服务出现建立网络连接或响应延迟，不用无限等待的问题，调用方可根据预置超时时间中断调用，及时释放关键资源，如Web容器的连接数，数据库连接数等，避免整个系统资源耗尽，而出现拒绝对外提供服务。
思想
只要释放够快，我就没那么容易挂~
4.2 限流（Rate Limiting/Load Shedder）
常用于下游服务容量有限，但又怕出现突发流量猛增（如爬虫，大促）而导致下游服务因压力过大而拒绝服务的场景。常见的限流模式有控制并发和控制速率
- 一个是限制并发的数量
- 一个是限制并发访问的速率。
思想
我就一碗饭量，给多了我也不吃！
4.3 舱壁隔离（Bulkhead Isolation）
造船行业使用此类模式，利用舱壁将不同船舱隔离，这样若一个船舱破了进水，只损失一个船舱，其它船舱可不受影响。借鉴造船行业经验，这种模式也在软件行业使用。
线程隔离（Thread Isolation）就是这种模式的常见场景。如系统A调用ServiceB、C、D三个远程服务，且部署A的容器一共有120个工作线程，采用线程隔离机制，可以给对B、C、D的调用各分配40个线程。当B慢了，给B分配的40个线程因慢而阻塞并最终耗尽，线程隔离可保证给C、D分配的80个线程不受影响。若无这种机制，当B慢时，120个工作线程会很快全部被对B的调用吃光，整个系统会全部慢下来，甚至系统停止响应。
实践经常遇到，如某接口由于数据库慢查询，外部RPC调用超时导致整个系统的线程数过高，连接数耗尽。可用舱壁隔离模式，为这种依赖服务调用维护一个小的线程池，当一个依赖服务由于响应慢导致线程池任务满的时候，不影响其他依赖服务的调用，缺点：增加线程数。
思想
别把鸡蛋放在一个篮子！
4.4 断路器模式
断路器三态转换：
思想
监控 + 开关
5 Sentinel VS hystrix
| 特性 | Sentinel | Hystrix |
| 隔离策略 | 信号量隔离 | 线程池隔离/信号量隔离 |
| 熔断降级策略 | 基于响应时间或失败比率 | 基于失败比率 |
| 实时指标实现 | 滑动窗口 | 滑动窗口(基于 RxJava) |
| 规则配置 | 支持多种数据源 | 支持多种数据源 |
| 扩展性 | 多个扩展点 | 插件的形式 |
| 基于注解的支持 | 支持 | 支持 |
| 限流 | 基于 QPS, 支持基于调用关系的限流 | 有限的支持 |
| 流量整形 | 支持慢启动、匀速器模式 | 不支持 |
| 系统负载保护 | 支持 | 不支持 |
| 控制台 | 开箱即用, 可配置规则、查看秒级监控、机器发现等 | 不完善 |
| 常见框架的适配 | Servlet、Spring Cloud、Dubbo、gRPC 等 | Servlet、Spring Cloud、Netflix |
参考：
