Sentinel工作原理

简介: Sentinel 是面向分布式服务架构的流量控制组件,以资源(如方法、URL)为核心,提供流量控制、熔断降级和系统负载保护。通过灵活的规则配置与插槽链机制,实现对系统入口流量的精准调控,保障系统稳定。

Sentinel 基本概念

资源

资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容,例如,由应用程序提供的服务,或由应用程序调用的其它应用提供的服务,甚至可以是一段代码。在接下来的文档中,我们都会用资源来描述代码块。

只要通过 Sentinel API 定义的代码,就是资源,能够被 Sentinel 保护起来。大部分情况下,可以使用方法签名,URL,甚至服务名称作为资源名来标示资源。

规则

围绕资源的实时状态设定的规则,可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

Sentinel 功能和设计理念

流量控制

流量控制在网络传输中是一个常用的概念,它用于调整网络包的发送数据。然而,从系统稳定性角度考虑,在处理请求的速度上,也有非常多的讲究。任意时间到来的请求往往是随机不可控的,而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。Sentinel 作为一个调配器,可以根据需要把随机的请求调整成合适的形状,如下图所示:

流量控制有以下几个角度:

  • 资源的调用关系,例如资源的调用链路,资源和资源之间的关系;
  • 运行指标,例如 QPS、线程池、系统负载等;
  • 控制的效果,例如直接限流、冷启动、排队等。

Sentinel 的设计理念是让您自由选择控制的角度,并进行灵活组合,从而达到想要的效果。

熔断降级

什么是熔断降级

除了流量控制以外,降低调用链路中的不稳定资源也是 Sentinel 的使命之一。由于调用关系的复杂性,如果调用链路中的某个资源出现了不稳定,最终会导致请求发生堆积。这个问题和 Hystrix 里面描述的问题是一样的。

Sentinel 和 Hystrix 的原则是一致的: 当调用链路中某个资源出现不稳定,例如,表现为 timeout,异常比例升高的时候,则对这个资源的调用进行限制,并让请求快速失败,避免影响到其它的资源,最终产生雪崩的效果。

熔断降级设计理念

在限制的手段上,Sentinel 和 Hystrix 采取了完全不一样的方法。

Hystrix 通过线程池的方式,来对依赖(在我们的概念中对应资源)进行了隔离。这样做的好处是资源和资源之间做到了最彻底的隔离。缺点是除了增加了线程切换的成本,还需要预先给各个资源做线程池大小的分配。

Sentinel 对这个问题采取了两种手段:

  • 通过并发线程数进行限制

和资源池隔离的方法不同,Sentinel 通过限制资源并发线程的数量,来减少不稳定资源对其它资源的影响。这样不但没有线程切换的损耗,也不需要您预先分配线程池的大小。当某个资源出现不稳定的情况下,例如响应时间变长,对资源的直接影响就是会造成线程数的逐步堆积。当线程数在特定资源上堆积到一定的数量之后,对该资源的新请求就会被拒绝。堆积的线程完成任务后才开始继续接收请求。

  • 通过响应时间对资源进行降级

除了对并发线程数进行控制以外,Sentinel 还可以通过响应时间来快速降级不稳定的资源。当依赖的资源出现响应时间过长后,所有对该资源的访问都会被直接拒绝,直到过了指定的时间窗口之后才重新恢复。

系统负载保护

Sentinel 同时提供系统维度的自适应保护能力。防止雪崩,是系统防护中重要的一环。当系统负载较高的时候,如果还持续让请求进入,可能会导致系统崩溃,无法响应。在集群环境下,网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候,这个增加的流量就会导致这台机器也崩溃,最后导致整个集群不可用。

针对这个情况,Sentinel 提供了对应的保护机制,让系统的入口流量和系统的负载达到一个平衡,保证系统在能力范围之内处理最多的请求。

Sentinel 工作主流程

在 Sentinel 里面,所有的资源都对应一个资源名称以及一个 Entry。Entry 可以通过对主流框架的适配自动创建,也可以通过注解的方式或调用 API 显式创建;每一个 Entry 创建的时候,同时也会创建一系列功能插槽(slot chain)。这些插槽有不同的职责,例如:

  • NodeSelectorSlot 负责收集资源的路径,并将这些资源的调用路径,以树状结构存储起来,用于根据调用路径来限流降级;
  • ClusterBuilderSlot 则用于存储资源的统计信息以及调用者信息,例如该资源的 RT, QPS, thread count 等等,这些信息将用作为多维度限流,降级的依据;
  • StatisticSlot 则用于记录、统计不同纬度的 runtime 指标监控信息;
  • FlowSlot 则用于根据预设的限流规则以及前面 slot 统计的状态,来进行流量控制;
  • AuthoritySlot 则根据配置的黑白名单和调用来源信息,来做黑白名单控制;
  • DegradeSlot 则通过统计信息以及预设的规则,来做熔断降级;
  • SystemSlot 则通过系统的状态,例如 load1 等,来控制总的入口流量;

总体的框架如下:

Sentinel 将 ProcessorSlot 作为 SPI 接口进行扩展(1.7.2 版本以前 SlotChainBuilder 作为 SPI),使得 Slot Chain 具备了扩展的能力。您可以自行加入自定义的 slot 并编排 slot 间的顺序,从而可以给 Sentinel 添加自定义的功能。

更多

相关文章
|
1月前
|
人工智能 安全 前端开发
Harness Engineering实战:用AGENTS/ARCHITECTURE规范AI编码Agent全流程
Harness Engineering(驾驭/护栏工程)是一套围绕自主AI Agent构建完整执行环境的工程方法论,不止局限于提示词与上下文优化,还包含标准化工具集、强约束规则、校验闭环、自我修正反馈机制,让AI智能体在生产环境稳定运行,大幅降低幻觉、逻辑错误、架构偏离问题。本文基于企业内部RAG+微调AI平台落地案例,完整拆解通过AGENTS.md、ARCHITECTURE及配套分层规范文档管控编码Agent的整套落地流程,形成可追溯、可审计、防幻觉的开发体系。
231 1
|
人工智能 前端开发 数据可视化
不再乱改接口、不再反复调试:接口联调跟踪工具带来流程级效率提升
项目上线前,接口联调常因信息不透明、文档混乱、沟通低效等问题频频翻车,导致进度延误、反复返工。本文详解接口联调的核心问题、协作角色、管理流程与工具推荐,助你建立高效联调体系,提升团队协作效率,实现接口状态可追踪、变更有记录、责任有归属,让接口联调不再成为交付瓶颈。
|
2月前
|
人工智能 定位技术 Go
从零搭建 Harness Engineering 框架 :Rule、Skill、Sub-Agent等工程落完整路径
Harness Engineering 是一套让AI在真实项目中稳定、可靠交付的工程系统,涵盖SPEC规范、Rule约束、Skill流程、Sub-Agent分工、Workflow编排、Script校验与MCP集成。它不追求模型更聪明,而是通过结构化机制消除随意性,实现可验证、可维护、可持续的AI协作开发。
808 1
从零搭建 Harness Engineering 框架 :Rule、Skill、Sub-Agent等工程落完整路径
|
7月前
|
XML 语音技术 开发者
基于prosemirror的SSML编辑器
SSML是W3C标准的语音合成标记语言,通过XML标签精细控制TTS的停顿、语调和发音,提升语音自然度与用户体验。相比纯文本,SSML更精准,避免机械感。我基于ProseMirror开发了Web友好的SSML编辑器,助力开发者高效编排。欢迎Star支持!
276 0
|
9月前
|
人工智能 缓存 监控
别再瞎试!一套"万能prompt框架"让AI输出质量提升10倍
作为一名后端开发,我曾因AI答非所问而崩溃。三个月摸索后,总结出高效提问的RBTRO框架:角色、背景、任务、要求、输出。套用需求文档思维,让AI从“瞎猜”变“精准执行”,效率提升10倍。附5大实战场景与可复用模板,助你快速上手。
|
移动开发 前端开发 Java
Docker——使用Dockerfile构建SpringBoot项目(打包 & 部署 & 运行)
Docker——使用Dockerfile构建SpringBoot项目(打包 & 部署 & 运行)
2885 0
Docker——使用Dockerfile构建SpringBoot项目(打包 & 部署 & 运行)
|
SQL 存储 分布式计算
ODPS开发大全:入门篇(1)
ODPS开发大全:入门篇
2099 14
|
NoSQL Java 程序员
秒解答题系统的头号难题:防止重复提交的终极指南!
小米,29岁技术爱好者,分享如何用Redis解决重复答题问题。在线考试系统常遇用户重复提交答案,导致数据异常。本文介绍利用Redis分布式锁特性防止重复提交,包括SETNX命令及Lua脚本实现方法,确保高并发下系统稳定可靠。适合线上考试或答题系统开发者参考。
431 13
秒解答题系统的头号难题:防止重复提交的终极指南!
|
运维 Cloud Native Java
热联集团:从 APISIX 迁移到云原生网关
我们将核心业务系统从 IDC 全栈迁移到阿里云后,并采用了云原生 API 网关,通过其独有的软硬一体的加速方案,相比普通 HTTPS 请求 TLS 握手时延降低一倍,极限 QPS 提升 80% 以上,运维效率也提升了 50%,此外,我们把 Nacos 迁移到 MSE Nacos,稳定性、性能和运维成本等方面都具备了明显的优势。

热门文章

最新文章