2. 限流降级基础：限流与降级的概念、常见算法、在微服务中的必要性

2.1 限流与降级：概念辨析

在微服务与服务网格架构中，限流与降级是保障系统稳定性的两大核心手段，但二者目标与触发机制有本质区别。

2.2 三大经典限流算法

限流算法的选择直接影响 API 延迟的分布特征。以下三种算法是微服务限流的基础，也是服务网格限流插件（如 Envoy 的 envoy.filters.http.local_ratelimit）的底层实现依据。

2.2.1 令牌桶算法（ Bucket）

以固定速率向桶中放入令牌，请求到达时需获取令牌才能通过。桶容量允许突发流量，但长期速率受限于令牌生成速率。

• 优点：允许一定程度的突发，实现简单，性能高。
• 缺点：突发流量可能压垮下游，需要合理设置桶大小。
• 服务网格应用：Envoy 的 _bucket 配置，Istio 的 RateLimitService。

2.2.2 漏桶算法（Leaky Bucket）

请求以任意速率进入桶中，桶以固定速率“漏出”请求。桶满则溢出（拒绝）。

• 优点：输出速率平滑，适合保护下游数据库或慢服务。
• 缺点：无法应对突发流量，所有请求强制排队，增加尾部延迟。
• 服务网格应用：Nginx 的 limit_req 模式，部分 Mesh 限流器用于流量整形。

2.2.3 滑动窗口算法（Sliding Window）

将时间划分为多个小窗口，统计当前窗口及前 N-1 个窗口的请求总数。窗口随时间滑动，精度高于固定窗口。

• 优点：避免固定窗口的“临界突变”问题，精度可控。
• 缺点：需要维护多个窗口计数器，内存占用略高。
• 服务网格应用：Envoy 的 rate_limit 基于全局 gRPC 服务，滑动窗口常用于分布式限流。

2.3 微服务中限流降级的必要性

在微服务架构中，服务间调用链路复杂，单个服务的抖动可能通过级联效应放大为系统雪崩。限流与降级是防止这种级联失效的第一道防线。

2.3.1 防止雪崩效应

当服务 A 调用服务 B 超时，A 的线程被阻塞，请求积压，最终导致 A 自身资源耗尽。限流在入口处拦截过量请求，降级在依赖故障时快速失败，切断级联路径。

2.3.2 保障核心业务 SLA

在资源有限的情况下，限流确保核心 API（如支付、登录）获得优先处理，降级则关闭非核心功能（如推荐、日志详情），将资源让给关键路径。

2.3.3 应对流量突刺与恶意攻击

秒杀、热点事件、DDoS 攻击都会产生远超正常水平的流量。限流算法（尤其是令牌桶+滑动窗口组合）能有效削峰填谷，保护后端数据库与缓存。

2.4 限流降级在服务网格中的实现层次

在 Istio/Envoy 架构中，限流降级可以在以下三个层次配置：

1. Sidecar 本地限流：Envoy 的 HttpConnectionManager 中配置 local_rate_limit，基于令牌桶，零额外网络开销，延迟影响极小。
2. 全局限流服务：通过 RateLimitService 调用外部限流服务（如 Envoy Rate Limit Server），支持滑动窗口和分布式计数，但增加 1-3ms RTT。
3. 熔断与降级：Envoy 的 circuit_breaker 配置（最大连接数、最大重试次数），以及 Istio 的 VirtualService 中的 fault 注入和 timeout 设置。