【背景】 做了 8 年中间件，今年带团队推服务治理标准化。一个绕不开的问题是：重试（retry）、熔断（circuit breaker）、超时（timeout）这三样，到底放应用层 SDK（Sentinel / Resilience4j / Hystrix），还是下沉到 Service Mesh（Istio / Envoy / Linkerd）？
我见过三种典型做法，各有翻车记录：
- 全放 SDK：每个服务自己配、自己管。灵活，但「每个团队配得不一样」是常态——新人接手一个服务，要翻三处代码 + 两个 properties 文件才知道超时到底是多少。我见过一个支付服务，SDK 里 timeout=3s，但 Nacos 配置中心又被运维改成了 5s，到底哪个生效，没人说得清。
- 全放 Mesh：Istio DestinationRule 统一定 timeout / retry / outlierDetection。一致性好，但业务侧想表达「对下游 A 只重试 1 次、对下游 B 不重试、对下游 C 只有 429 才重试」，在 Mesh 层很难优雅表达，最后还是退回到 SDK 里写。
- 混合：超时和简单重试放 Mesh，熔断和降级放 SDK。听起来最合理，但「谁来保证两边策略不冲突」成了新问题——SDK 熔断打开后 Mesh 还在重试，或者 Mesh timeout 先于 SDK timeout 触发导致「假超时」，我都见过。
【常见分歧（我观察到的）】
- SRE / 运维倾向全放 Mesh：统一、可观测、不用改业务代码、升级策略不用发版。
- 业务开发倾向放 SDK：能感知业务语义——「这个接口幂等可以重试，那个不行」「熔断恢复要检查下游队列深度」。
- 架构组倾向「能力下沉、策略上浮」：Mesh 提供原语（retry / timeout / circuit-break），SDK 做业务编排。
- 但真正落地的团队里，我看到的更多是「谁先写谁说了算」，没有统一标准，也没有文档说清楚为什么这么切。
【我的倾向与理由】 我倾向「混合 + 单一事实源」，具体切法：
- 超时：统一放 Mesh（Envoy route timeout）。应用侧 SDK 的 timeout 只作为兜底，且必须比 Mesh 大 20%（比如 Mesh 3s → SDK 3.6s），避免 SDK 先触发导致「假超时」（SDK 认为超时了，但 Mesh 还在等，连接还没断，重试逻辑走不到）。
- 重试：
- 简单网络级重试（connection refused / connection timeout / 502/503）→ 放 Mesh（Envoy retryOn）。
- 带业务语义的重试（「只有 429 + Retry-After 才重试」「只有特定错误码才重试」）→ 放 SDK。
- 关键约束：SDK 重试和 Mesh 重试不能同时开，必须有一个明确的「谁负责重试」的约定，否则重试次数会叠加（Mesh 重试 2 次 × SDK 重试 3 次 = 下游被打 6 次）。
- 熔断：放 SDK。理由是熔断的「半开恢复」逻辑通常跟业务状态有关（检查下游队列深度、检查 Redis 连接池可用数），Mesh 层做不了这种判断。Mesh 的 outlierDetection 只能做「连续 N 次 5xx 就摘除」，粒度不够。
- 降级 / 兜底：必须放 SDK，这没有争议。
最关键的约束：所有策略必须有一个「单一事实源」。我现在的做法是一个 Git 仓库（resilience-policy.yaml），每个服务的超时/重试/熔断参数都在这定义，CI 阶段校验后分别生成 Envoy config 和 SDK 配置。避免「Mesh 一套、SDK 一套、Nacos 又一套」的三头管理。
【想听大家说】
- 你们团队的超时 / 重试 / 熔断分别放在哪一层？是刻意设计的还是「历史原因」？
- 有没有遇到过「SDK 重试 + Mesh 重试」叠加导致下游被打爆的事故？怎么发现的（日志？监控？下游告警？）？
- 不用 Mesh 的纯 SDK 方案，50+ 服务怎么保证策略一致性？有没有工具链 / 配置中心 / CI 校验的经验可以分享？
- 如果让你重新设计，「能力下沉、策略上浮」这条线你画在哪？哪些能力你觉得「必须留在应用层」，哪些「必须下沉到基础设施」？
0赞
0收藏
0楼层