云原生限流熔断必须下沉至基础设施层，首选Istio（VirtualService+DestinationRule），次选Sentinel（需避坑），轻量场景可用etcd自研；核心在于策略与业务SLO对齐。
云原生环境下的服务限流与熔断，不能靠单个服务自己写代码硬扛，必须下沉到基础设施层——要么用 Service Mesh（如 Istio + Envoy），要么用统一的治理 SDK（如 Sentinel 或 Go 的 go-zero middleware），否则多语言、多团队、动态扩缩容场景下策略必然失准。
为什么 Istio VirtualService + DestinationRule 是生产首选
在 Kubernetes 集群里，直接在业务代码里写限流逻辑（比如用 sentinel-go）看似简单，但会带来三个硬伤：策略无法跨语言生效、Pod 重启后规则丢失、灰度发布时难做流量比例控制。Istio 把这些能力从应用层剥离，由 Envoy 边车统一执行，所有策略通过 CRD 声明，天然支持 GitOps 管控。
-
VirtualService控制入口流量分发（比如按 header / path 限流），适合 API 网关级粗粒度控制 -
DestinationRule定义目标服务的调用策略（如连接池大小、超时、熔断异常检测阈值），作用于服务间通信链路 - 两者配合可实现“对 /payment 接口 QPS > 100 时触发 503，同时对 payment-svc 实例设置连续 5 次 5xx 后熔断 60 秒”这类组合策略
- 注意：
envoyproxy/envoy默认不开启熔断统计，需在DestinationRule中显式配置outlierDetection，且健康检查端点必须返回 200，否则会被误判为异常实例
用 Sentinel 做应用内限流时，必须绕开的三个坑
当无法部署 Service Mesh（比如遗留系统改造过渡期），或需要更细粒度方法级控制（如某个 RPC 方法单独限流），Sentinel 是主流选择。但它在云原生环境容易因容器生命周期错配而失效。
- 心跳上报地址不能写死
localhost:8848—— 控制台部署在 K8s 里时，客户端要用 Headless Service DNS 名（如sentinel-dashboard.default.svc.cluster.local） - 规则持久化必须外挂，
file-read模式在 Pod 重建后清空；推荐对接 Nacos 或 Apollo，用datasource动态拉取，避免重启生效延迟 -
@SentinelResource注解默认 fallback 不走 Spring 的@ExceptionHandler，降级逻辑得单独写函数，且该函数签名必须和原方法一致，否则运行时报BlockException无法捕获
etcd + 自研控制器实现轻量级熔断，什么场景才值得搞
不是所有团队都需要 Istio 或 Sentinel。如果你只有几个 Go 服务、没上 Service Mesh、又不想引入 Java 生态，用 etcd 存熔断状态 + 自研控制器是可行路径，但只适用于低频变更、强可控环境。
- 核心是把熔断器状态（OPEN/CLOSED/HALF_OPEN）、失败计数、最后切换时间存成 etcd 的 key，例如
/circuit-breaker/payment-svc/192.168.1.10:8080 - 每个服务启动时 Watch 该前缀，本地缓存并定期刷新；调用前查缓存，OPEN 状态直接 panic 或返回兜底数据
- 缺点明显：无自动恢复探测（HALF_OPEN 状态需额外定时任务触发试探请求）、不感知实例下线（得靠租约 TTL 清理）、无法聚合统计全链路失败率
- 适合场景：边缘计算节点、IoT 网关、CI/CD 流水线中的工具服务等对 SLA 要求不高、人力有限的系统
真正难的不是选哪个工具，而是定义清楚「谁来决定限流阈值」「失败多少次才算熔断」「降级数据从哪来」——这些必须和业务 SLO 对齐，而不是拍脑袋设个 100 QPS 或 50% 错误率。K8s 的 HorizontalPodAutoscaler 可以根据 CPU 扩容，但不会因为慢查询自动熔断；监控告警能告诉你 P99 延迟飙升，但不会帮你切到缓存。治理能力最终要落在人对指标的理解和响应机制上。
