服务治理

【背景】 做了 8 年中间件，今年带团队推服务治理标准化。一个绕不开的问题是：重试（retry）、熔断（circuit breaker）、超时（timeout）这三样，到底放应用层 SDK（Sentinel / Resilience4j /

背景 我们维护一个 Go 1.21 gRPC（v1.59.0）定价服务，被 5 个独立上游服务共享：搜索、购物车、结算、营销、风控。每个上游都是独立的团队，各自用 Resilience4j（Java）或自研 Go 中间件配置重试策略，下游对

背景 我做了 5 年运维，从最早一个 monolith 跑在两台 ECS 上，到现在管着 60+ 个微服务的 K8s 集群，切身体会到一个感受：服务数量每翻一倍，运维的复杂度不是翻倍，是翻好几倍。 具体来说，我数了一下我们现在的日常负担：

背景 我最近在帮一个组定「服务间调用的公共规范」，走到「默认要不要开重试」这一步，组内直接吵起来了。这个点平时大家各自服务里都有一套，但没人愿意把它写成团队级默认值——因为它一旦写成默认，就等于替所有调用方做了决定。 三种常见做法（也是三种