限流、熔断、降级是云原生流量治理的递进式防御链：限流控制请求速率防过载，熔断隔离下游故障防雪崩，降级提供兜底结果保核心可用。
限流：保护服务不被突发流量压垮
限流是流量治理的第一道防线，核心目标是控制单位时间内进入服务的请求数量，防止系统过载。在云原生场景下，限流通常在网关层（如 Envoy、Nginx Ingress Controller）或服务网格侧（如 Istio 的 VirtualService + DestinationRule 配合 Envoy 的 local rate limiting）实现。
常见策略包括：
- QPS 限流：最直观，比如限制某 API 每秒最多处理 100 个请求；
- 并发连接数限制：适用于长连接场景（如 WebSocket），避免线程/连接耗尽；
- 用户级/租户级限流：按 header 中的 user-id 或 JWT claim 做区分，保障多租户公平性；
- 动态限流：结合 Prometheus 指标（如 CPU 使用率、错误率）自动调整阈值，需配合自定义控制器（如 K8s Operator 或 Argo Rollouts 集成）。
示例（Istio YAML 片段）：通过 EnvoyFilter 启用本地限流，匹配特定 host 和 header，并返回 429 状态码。
熔断：快速失败，避免雪崩扩散
熔断不是拒绝请求，而是主动“断开”对下游不稳定服务的调用，让上游快速失败并降级处理。它依赖实时指标（失败率、延迟、连接超时等）触发状态切换（关闭 → 半开 → 打开）。
Kubernetes 生态中，Istio 默认支持基于 Outlier Detection 的熔断机制，配置在 DestinationRule 中：
- consecutive_5xx：连续多少次 5xx 响应触发摘除；
- interval：检测周期，默认 10s；
- base_ejection_time：节点被摘除的最短时间；
- max_ejection_percent：最多允许多少比例实例被摘除，防止单点误判导致全量不可用。
注意：熔断只作用于客户端（即调用方 sidecar），不改变后端服务本身；需配合健康检查与重试策略使用，否则可能放大抖动。
降级：有损服务，保障核心链路可用
降级是在资源紧张或依赖故障时，主动关闭非核心功能，确保主流程仍可运行。它不等于“报错”，而是返回兜底结果（如缓存旧数据、静态页面、默认值、简化逻辑）。
落地方式分两类：
- 配置驱动降级：通过 ConfigMap 或 Nacos/Apollo 动态开关，比如关闭商品推荐模块，但保留下单能力；
- 代码级降级：在业务逻辑中嵌入 Hystrix / Sentinel / resilience4j 的 fallback 方法，例如调用积分服务超时时，跳过积分扣减直接完成订单。
关键原则：降级策略必须提前设计、充分测试，并具备一键回滚能力；所有降级路径都要记录日志和监控指标，便于事后复盘。
协同生效：把三者串成一条防御链
限流、熔断、降级不是孤立策略，而是一套递进式防护体系：
- 高并发突增 → 触发限流，保护自身容量；
- 下游持续超时或报错 → 熔断器打开，隔离故障源；
- 熔断期间上游仍有请求进来 → 自动走降级逻辑，避免用户看到空白页或 503。
建议在 CI/CD 流水线中加入混沌工程演练（如 Chaos Mesh 注入网络延迟、Pod Kill），验证三者组合在真实故障下的响应是否符合预期。监控上，重点关注限流拦截率、熔断开启率、降级调用量三个黄金指标。
