Sentinel 中的三种流控策略（STRATEGY_DIRECT、STRATEGY_RELATE、STRATEGY_CHAIN）是 针对不同业务场景设计的精细化流量控制手段 。它们的核心区别在于："以什么维度来判断是否触发限流"。
下面逐个详解其含义、原理和典型应用场景：
🟢 1. STRATEGY_DIRECT（直接流控）
✅ 含义：
- 对当前资源本身进行限流。
- 可进一步细分为：
- 按调用方（origin）限流 ：如只限制来自
"mobile"应用的请求。 - 对所有调用方统一限流 ：即
limitApp = "default"。
- 按调用方（origin）限流 ：如只限制来自
🔧 原理：
- 使用 当前资源的统计节点 （
ClusterNode或OriginNode）来判断 QPS/线程数是否超限。 - 例如：
/order/create接口每秒最多处理 100 次请求。
📌 典型场景：
| 场景 | 配置示例 | 说明 |
|---|---|---|
| 接口整体保护 | resource="/pay", limitApp="default", strategy=DIRECT |
所有来源的 /pay 请求总和不能超过阈值 |
| 多租户隔离 | resource="/api", limitApp="tenantA", strategy=DIRECT |
只限制租户 A 的调用量，不影响 tenantB |
| 防刷/防爬 | resource="/login", limitApp="crawler", strategy=DIRECT |
识别并限制爬虫流量 |
💡 最常用、最直观的策略，适用于绝大多数基础限流需求。
🔵 2. STRATEGY_RELATE（关联流控）
✅ 含义：
- 当某个"关联资源"达到阈值时，限流当前资源。
- 即：A 资源的流量影响 B 资源的可用性，通过控制 B 来保护 A。
🔧 原理：
- 限流判断依据不是当前资源的指标，而是 另一个资源（
refResource）的全局流量。 - 例如：当
order-service被大量调用时，自动限制payment-service的入口，防止支付服务拖垮订单服务。
📌 典型场景：
| 场景 | 配置示例 | 说明 |
|---|---|---|
| 保护下游依赖 | resource="/pay", refResource="db-write", strategy=RELATE |
当数据库写入压力大时，限制支付请求 |
| 削峰填谷 | resource="/submit-order", refResource="/query-stock", strategy=RELATE |
库存查询频繁时，限制下单（避免超卖） |
| 第三方 API 保护 | resource="/notify-user", refResource="sms-api", strategy=RELATE |
短信接口快打满时，暂停用户通知 |
⚠️ 注意：
refResource是 全局资源名，不区分调用方。
🟣 3. STRATEGY_CHAIN（链路流控）
✅ 含义：
- 只在特定的调用链路（入口）上触发限流。
- 即：同一个接口，从不同入口调用时，限流策略不同。
🔧 原理：
- 通过
Context.getName()（即 入口资源名 ）判断当前调用链是否匹配refResource。 - 仅当 入口资源 == refResource 时，才对当前资源进行限流。
📌 典型场景：
| 场景 | 配置示例 | 说明 |
|---|---|---|
| 区分内外流量 | resource="/user/info", refResource="gateway-entry", strategy=CHAIN |
只限制从网关进来的请求，内部服务调用不受限 |
| 防止入口打爆内部服务 | resource="/cache/get", refResource="/order/detail", strategy=CHAIN |
只有 /order/detail 调用缓存时才限流，其他路径不限 |
| 灰度发布控制 | resource="/new-feature", refResource="gray-gateway", strategy=CHAIN |
仅对灰度入口限流，不影响主干 |
🔑 关键点：
refResource必须是 调用链的入口资源名（通常是第一个被 Sentinel 保护的资源）。- 内部服务间调用（无入口上下文）通常不会触发此策略。
🆚 三者对比总结
| 策略 | 判断依据 | 适用场景 | 是否依赖 refResource |
|---|---|---|---|
DIRECT |
当前资源自身流量（可按 origin 细分） | 通用限流、多租户隔离 | ❌ 否 |
RELATE |
另一个资源（refResource）的全局流量 | 保护依赖、联动限流 | ✅ 是 |
CHAIN |
当前调用链的入口资源是否匹配 refResource | 链路级精细化控制 | ✅ 是 |
💡 实际配置示例（代码）
java
// 1. DIRECT: 限制 mobile 应用访问 /api
FlowRule rule1 = new FlowRule("api")
.setLimitApp("mobile")
.setStrategy(RuleConstant.STRATEGY_DIRECT)
.setCount(10);
// 2. RELATE: 当 /order 流量高时，限制 /pay
FlowRule rule2 = new FlowRule("pay")
.setLimitApp("default")
.setStrategy(RuleConstant.STRATEGY_RELATE)
.setRefResource("order") // 关联资源
.setCount(50);
// 3. CHAIN: 只在从 gateway 进来的链路限制 /user
FlowRule rule3 = new FlowRule("user")
.setLimitApp("default")
.setStrategy(RuleConstant.STRATEGY_CHAIN)
.setRefResource("gateway") // 入口资源名
.setCount(20);✅ 总结一句话：
DIRECT→ "我自己不能太忙"RELATE→ "他太忙了，我得帮他挡一挡"CHAIN→ "只有从那条路来的人，我才管"
理解这三种策略，就能在复杂微服务架构中实现 精准、灵活、安全的流量治理。