从当年支付网关被冲垮的血泪教训，聊聊 Go 微服务限流与熔断组件的避坑选型

聊聊 Go 微服务里的限流与熔断选型，顺便听听大家的生产实践。

最近在帮朋友 review 一套交易网关的改造方案，老生常谈的稳定性治理又被摆上台面。当年在老东家做支付核心时，踩过最惨的一个坑就是依赖方的代付通道抖动：下游响应变慢 -> 上游协程暴增打满连接池 -> 整个支付网关级联超时 -> 最终全链路雪崩。那次故障后我就形成了一个强迫症：无熔断不网关，无限流不上线。

从 Java 技术栈转到 Go 之后，在组件选型上感觉生态比想象中割裂，目前纠结在两个方向：

1. 重型方案：sentinel-golang

   • 观点：规则丰富，支持系统自适应限流、热点参数限流，模型和机制都很成熟。
   • 顾虑：Go 版本的活跃度和社区维护力度明显不如 Java 原版，感觉有点重，侵入性也略大。

2. 轻量组合方案：框架内置（如 go-zero / Kratos）或 x/time/rate + sony/gobreaker

   • 观点：代码纯粹、低侵入，自适应降级（BBR 算法）在容器化下很省心。
   • 顾虑：缺乏一个成熟的统一 Dashboard 进行动态规则下发，真要在生产上动态调整阈值，还得自己结合配置中心（Consul / Nacos）封装一套热更新机制。

想问问各位老哥，你们目前扛核心业务（尤其是订单、高并发结算场景）的 Go 服务：

• 熔断限流是用现成的成熟 SDK，还是自己包的轻量中间件？
• 集群分布式限流，是老老实实用 Redis + Lua，还是单机自适应限流配合网关前置挡刀？

欢迎拍砖，交流下各自踩过的坑。