Spring Cloud 治理组件选型限流、熔断与可观测性分开看1. 先拆需求再谈组件Spring Cloud 场景里的治理需求通常分为入口限流、进程内熔断、服务发现和链路观测。把它们混成一张功能表很容易为了一个功能引入整套平台。先写清故障发生在哪一层再决定由 Gateway、Resilience4j、Sentinel 或服务网格承担。2. 评估替换成本新组件要与现有注册中心、指标系统和发布方式配合。除了吞吐还要验证配置是否可审计、规则失败时如何回退、客户端版本能否逐步迁移。团队不熟悉的控制面本身就是运维成本。3. 用同一批故障用例比较对候选方案注入相同的超时、连接拒绝和慢响应观察是否按预期打开熔断、是否产生重试风暴、错误信息能否定位。比较依据应来自重复实验而不是官网示例或单次跑分。4. 保留退出路径治理组件应藏在稳定接口后面业务代码只依赖限流与熔断语义。规则配置要能版本化旧规则要能快速恢复。能够撤回的选型通常比功能最多的选型更适合长期维护。