随微服务流行,服务和服务之间稳定性越来越重要。Sentinel是面向分布式服务架构的轻量级流量控制框架,以流量为切入点,从流控、熔断降级、系统负载保护等多维保障服务稳定性。
曾经:
如今:
可完成替代 Netflix-hystrix。
系统依赖的某个服务发生延迟或故障,数秒内导致所有应用资源(线程,队列等)被耗尽,造成雪崩效应。
cascading failure(级联失效 / 级联故障):
最常见的容错模式。
常见的有设置网络连接超时时间,一次RPC的响应超时时间。
主要解决当依赖服务出现建立网络连接或响应延迟,不用无限等待的问题,调用方可根据预置超时时间中断调用,及时释放关键资源,如Web容器的连接数,数据库连接数等,避免整个系统资源耗尽,而出现拒绝对外提供服务。
只要释放够快,我就没那么容易挂~
常用于下游服务容量有限,但又怕出现突发流量猛增(如爬虫,大促)而导致下游服务因压力过大而拒绝服务的场景。常见的限流模式有控制并发和控制速率
我就一碗饭量,给多了我也不吃!
造船行业使用此类模式,利用舱壁将不同船舱隔离,这样若一个船舱破了进水,只损失一个船舱,其它船舱可不受影响。借鉴造船行业经验,这种模式也在软件行业使用。
线程隔离(Thread Isolation)就是这种模式的常见场景。如系统A调用ServiceB、C、D三个远程服务,且部署A的容器一共有120个工作线程,采用线程隔离机制,可以给对B、C、D的调用各分配40个线程。当B慢了,给B分配的40个线程因慢而阻塞并最终耗尽,线程隔离可保证给C、D分配的80个线程不受影响。若无这种机制,当B慢时,120个工作线程会很快全部被对B的调用吃光,整个系统会全部慢下来,甚至系统停止响应。
实践经常遇到,如某接口由于数据库慢查询,外部RPC调用超时导致整个系统的线程数过高,连接数耗尽。可用舱壁隔离模式,为这种依赖服务调用维护一个小的线程池,当一个依赖服务由于响应慢导致线程池任务满的时候,不影响其他依赖服务的调用,缺点:增加线程数。
别把鸡蛋放在一个篮子!
断路器三态转换:
监控 + 开关
特性 | Sentinel | Hystrix |
---|---|---|
隔离策略 | 信号量隔离 | 线程池隔离/信号量隔离 |
熔断降级策略 | 基于响应时间或失败比率 | 基于失败比率 |
实时指标实现 | 滑动窗口 | 滑动窗口(基于 RxJava) |
规则配置 | 支持多种数据源 | 支持多种数据源 |
扩展性 | 多个扩展点 | 插件的形式 |
基于注解的支持 | 支持 | 支持 |
限流 | 基于 QPS, 支持基于调用关系的限流 | 有限的支持 |
流量整形 | 支持慢启动、匀速器模式 | 不支持 |
系统负载保护 | 支持 | 不支持 |
控制台 | 开箱即用, 可配置规则、查看秒级监控、机器发现等 | 不完善 |
常见框架的适配 | Servlet、Spring Cloud、Dubbo、gRPC 等 | Servlet、Spring Cloud、Netflix |
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。