OpenFeign 交互实验室 — 限流 · 熔断

01OpenFeign 是什么

OpenFeign 是一个声明式 HTTP 客户端：你只需要定义一个 Java 接口并加上注解，调用远程 HTTP 服务就像调用本地方法一样。它把「拼 URL、序列化参数、发 HTTP、解析响应」这些模板代码全部消灭掉。

// ① 定义接口 —— 不写任何实现
@FeignClient(name = "order-service",
    fallbackFactory = OrderFallback.class)
public interface OrderClient {

  @GetMapping("/orders/{id}")
  OrderDTO getOrder(@PathVariable Long id);
}

// ② 业务代码 —— 像调本地方法一样用
@Autowired
private OrderClient orderClient;

OrderDTO order = orderClient.getOrder(42L);

声明式 (Declarative)

接口 + 注解即契约。@FeignClient 声明目标服务名，Spring MVC 注解（@GetMapping 等）描述 HTTP 语义，零实现代码。

与注册中心天然集成

name = "order-service" 不是 URL，而是注册到 Nacos / Eureka 的服务名，配合负载均衡自动挑选实例。

可插拔组件

Encoder / Decoder / Contract / Client / RequestInterceptor 全部可替换，可接入 OkHttp、Apache HttpClient，可统一注入鉴权头。

02工作原理：一次调用经历了什么

启动时，Spring 为每个 @FeignClient 接口生成动态代理对象。点击下方按钮，观察一次 getOrder(42) 调用的完整生命周期。

① 方法调用。业务代码调用代理对象的 getOrder(42)，JVM 实际执行的是 InvocationHandler.invoke()。">

方法调用

orderClient
.getOrder(42)

→

② 动态代理。FeignInvocationHandler 根据方法上的注解元数据，找到对应的 MethodHandler（每个接口方法一个）。">

动态代理

JDK Proxy
InvocationHandler

→

③ 构造请求。Contract 解析注解得到 URL/方法，Encoder 序列化参数，RequestInterceptor 注入通用请求头（如 Token、链路 ID）。">

构造请求

Contract + Encoder
+ Interceptor

→

④ 服务发现与负载均衡。把逻辑服务名 order-service 解析成实例列表（Nacos/Eureka），LoadBalancer 按策略挑一个实例，如 10.0.1.8:8080。">

负载均衡

服务名 → 实例
LoadBalancer 选择

→

⑤ HTTP 调用。底层 Client（JDK 默认 / OkHttp / Apache HC）发出真正的网络请求。超时、重试、熔断都包裹在这一层之外。">

HTTP 请求

GET /orders/42
真实网络 IO

→

⑥ 解码返回。Decoder 把响应体反序列化为 OrderDTO；非 2xx 状态码交给 ErrorDecoder，抛出 FeignException —— 这是触发降级的信号。">

解码响应

Decoder → DTO
ErrorDecoder 处理异常

点击「发起调用」查看每个环节的细节，或直接点击任意节点。

Contract 契约

解析注解的规范。Spring Cloud 用 SpringMvcContract，因此 Feign 接口可以直接复用 Spring MVC 注解。

Encoder / Decoder

请求体序列化与响应反序列化，默认 SpringEncoder + Jackson。换成 Gson/Protobuf 只需替换 Bean。

ErrorDecoder

把 HTTP 错误码翻译成异常。远程服务返回 500 → 抛出 FeignException → 被熔断器统计 → 触发降级。

03限流 Rate Limiting —— 入口的闸门

限流回答的问题是「流量太大怎么办」。它不关心下游健不健康，只按固定节奏放行请求。下面是一个令牌桶：每 600ms 生成 1 个令牌，桶容量 5，有令牌才放行。试试快速连点「发送请求」。

0
放行

0
拒绝 (429)

≈1.67
长期 QPS 上限

💡 对应实现：Sentinel 的 FlowRule（QPS / 并发线程数两种维度）、Gateway 的 RequestRateLimiter（Redis 令牌桶）。Feign 侧触发限流抛 FlowException，同样会进入 fallbackFactory。

04熔断 Circuit Breaker —— 故障的保险丝

熔断回答的问题是「下游已经病了，还要不要继续打」。它统计最近 N 次调用的失败率，超过阈值就「跳闸」：一段时间内直接拒绝调用，给下游恢复时间，之后进入半开状态试探。下面是一个完整的状态机模拟器。

CLOSED

正常放行，统计失败率

→失败率 ≥ 50%

OPEN

跳闸 5s，请求直接短路

→冷却结束

HALF-OPEN

放行 3 个试探请求

下游服务故障率：60%

模拟 order-service 的出错概率。调高看它把熔断器打跳闸；调低并等待，看熔断器自动恢复。

启用熔断（失败率阈值 50%）启用降级 fallbackFactory 启用限流（上限 3 QPS）

0总请求

0成功

0失败 / 短路

0降级兜底

滑动窗口失败率（最近 10 次真实调用，≥6 次起统计）

05降级 Fallback —— 兜底方案

降级回答的问题是「实在调不通，给用户返回什么」。无论是被限流、被熔断短路，还是真的调用失败，Feign 都会把异常交给 fallbackFactory，由它返回一个兜底结果——缓存数据、空列表或友好的默认值，保证调用方不崩。

@Component
public class OrderFallback
    implements FallbackFactory<OrderClient> {

  @Override
  public OrderClient create(Throwable cause) {
    return id -> {
      log.error("降级: {}", cause.getMessage());
      return OrderDTO.cached(); // 兜底
    };
  }
}

为什么用 fallbackFactory 而非 fallback

工厂方法能拿到 Throwable cause——是超时、500、被限流还是被熔断短路，日志里一清二楚，排障效率完全不同。

降级的三种触发源

① 真实调用失败（超时 / 5xx）② 熔断器 OPEN，请求被短路（CallNotPermittedException）③ 被限流（FlowException）。三种异常殊途同归，都进 fallback。

降级的本质

用「有损但可用」换「系统不雪崩」。上面模拟器里关掉「启用降级」开关再压测一次，对比日志就能直观看到差异。

06三者的关系：各管一段，协作兜底

三者不是互相替代，而是同一条调用链上的三道防线。请求按顺序经过它们：

限流

Rate Limiting / Sentinel FlowRule

事前预防。按固定节奏放行，防止流量洪峰把下游打挂。
不管下游病没病，超量就拒。

🚪 入口的闸门

→

熔断

Circuit Breaker / Resilience4j

事中保护。发现下游持续失败就跳闸，快速失败、给下游喘息时间，并防止故障向上游蔓延。
下游病了，就不再打它。

⚡ 电路的保险丝

→

降级

Fallback / fallbackFactory

事后兜底。前两道防线拦下的请求、真实失败的请求，最终都由它给出兜底响应。
无论如何，给调用方一个交代。

🪂 备用的降落伞

维度	限流	熔断	降级
触发条件	流量超过设定阈值（QPS/并发）	失败率 / 慢调用比例超阈值	调用失败、被熔断、被限流
关注对象	自身 / 入口流量	下游依赖的健康度	调用方的体验
行为	拒绝多余请求（429）	短路请求，停止真实调用	返回兜底数据
恢复方式	流量回落即恢复	冷却 → 半开试探 → 关闭	随调用恢复自动退出
典型实现	Sentinel FlowRule、Gateway Redis 限流	Resilience4j、Sentinel DegradeRule	@FeignClient fallbackFactory

🧪 回到上面的模拟器验证：把故障率拉到 80%，开启三个开关后「自动压测」——你会依次看到：限流拒绝部分请求 → 失败率超标熔断跳闸 → 跳闸期间请求全部走降级兜底 → 5 秒后半开试探。这就是三者协作的完整剧本。