Go微服务热点参数限流：Sentinel实现

Sentinel Go热点参数限流必须显式配置ParamIndex/ParamKey、MetricType和ControlBehavior三项，缺一不可，否则规则被静默丢弃；ParamKey比ParamIndex更健壮，QPS模式下Threshold与DurationInSec共同决定限流窗口，Concurrency模式限制的是并发goroutine数而非QPS。

先说几个核心判断：Sentinel Go 的热点参数限流可不是“找个开关打开就能用”的东西。它需要你把 ParamIndex 或 ParamKey、MetricType、ControlBehavior 这三项明明白白地配置出来，随便漏掉哪一个都不行。一旦少了，规则加载就直接失败，而且是那种静默失败——你压根收不到什么错误提醒，结果流量该怎么打穿还是怎么打穿。

为什么 sentinel.LoadRules() 不报错但限流不生效

最典型的场景就是：调用了 hotspot.LoadRules，返回值是 nil，日志里也看不出什么异常，但实际请求就是从未被拒绝过。那问题在哪？根本原因就出在规则结构体的字段缺失上，或者字段类型对不上号。

• MetricType 和 ControlBehavior 是死命令——必须设，漏了的话 Sentinel Go 直接就把规则丢掉了，连个日志都不给你打。
• ParamIndex 设成 0 但你的方法参数是一个 struct（比如 func getProduct(req ProductReq)），那提取出来的结果就是空的，规则对所有请求全都不生效。
• 用 ParamKey 的时候，如果把字段名拼错了（比如你写的是 "userId"，但 struct 里实际是 UserID），Go 的反射根本匹配不上，照样静默失败。
• 参数值类型少了点规则——它不是基础类型（int/string/int64 这些），并且没有实现 ParamFlowArgument 接口，那提取就失败，不计数、不报错、不限流。

ParamIndex 和 ParamKey 怎么选才稳

这两者是互斥的：你只能选一个，而且必须选对，否则参数就提取失败。关键的取舍逻辑在于参数结构和长期维护的代价。

• 如果你的方法签名非常固定，参数顺序也不太会变，比如 func getUser(id int, name string) 这种，那直接使用 ParamIndex=0 确实够简单够直接。
• 但是，但凡换成 struct 或者 map 入参，比如 func createOrder(req OrderCreateReq)，那就必须用 ParamKey="ProductID" 了。靠索引是拿不到嵌套字段的，而且后面加一个字段就容易对不上位。
• 优先用 ParamKey，哪怕多写几个字也是值得的。它不依赖位置，字段名改了在编译期就能发现，远比运行时静默失效稳妥得多。
• 如果用 map 做入参，那 ParamKey 对应的 key 名必须完全一致，而且大小写不能错。另外，map 值不能为 nil，否则提取的时候返回空字符串，所有请求就都被当成同一个参数值来统计了。

QPS 模式下 BurstCount 和 DurationInSec 怎么配

这不是“越大越好”的参数——配错了，限流直接形同虚设。

• DurationInSec 必须设成正整数，比如 1。设 0 或者负数，规则加载失败，但 hotspot.LoadRules 仍然默默返回 nil，没问题你都不知道输在哪里。
• BurstCount 只有在 ControlBehavior=Reject 且 MetricType=QPS 的时候才真正生效。要注意：它代表的是“突发容量”，而不是阈值本身。真正决定限流窗口的还是 Threshold 加 DurationInSec 的组合。
• 举个例子：你想限住 productID=1001 这个热点参数每秒最多 100 次请求，那就设好 Threshold=100 和 DurationInSec=1 就可以了。至于 BurstCount 设成 20，是为了允许短时脉冲——也就是说，1 秒内可以打进 120 个请求，前 100 个放进来，后 20 个拒绝。
• 注意别犯一个常见的错误：把 DurationInSec 设成 60，然后把 Threshold 设成 6000。看起来两者等价，但实际效果完全不同——窗口拉长以后，统计延迟明显增加，热点识别会滞后，秒杀场景下你发现打爆 DB 时才反应过来。

Concurrency 模式容易被忽略的并发语义

很多人以为 MetricType=Concurrency 跟 QPS 差不多，是用来控制每秒多少请求的。实际上它统计的是同时正在执行的 goroutine 数量，跟 QPS 完全是两码事。

• 设置 Threshold=5 就意味着：如果同一个 productID 的请求已经有 5 个 goroutine 同时在跑了（比如都在查 DB、都在调第三方接口），那第 6 个进来的请求就直接被拒绝。
• 这种模式比较适合用来防慢 SQL 或者阻塞 IO，但不太适合直接控制系统的吞吐量。为什么？因为你设高了也没用，goroutine 占用的本质是内存和调度开销，而不是时间片。
• 特别提醒：千万别在 ControlBehavior=Throttling 这个模式下搭配 Concurrency 来用。排队逻辑只对 QPS 有效，对于 Concurrency，你设的 MaxQueueingTimeMs 会被直接忽略。
• 真实压测的时候，可以结合 go tool pprof 来看 goroutine 的数量，这个比 QPS 更能验证 Concurrency 限流到底有没有生效。

最后提一个最容易被绕过的点：规则加载之后，你用过 sentinel.GetNode("your-resource").Resource.Name 检查它是不是真的对应你定义的那个资源名吗？名字对不上，规则就挂在空节点上，永远没有机会触发。别太相信自己写了代码它就生效了，一定要用到 sentinel.GetNode 或者控制台的实时监控去确认节点存在并且有 metric 数据。