滚动更新中单服务闪退引发级联崩溃，本质是依赖链缺乏容错与就绪感知；必须通过真实应用层健康检查（如/health端点）、service_healthy依赖条件、parallelism=1+delay=15s渐进更新及超时熔断等机制保障稳态。
滚动更新中单服务闪退引发级联崩溃，本质是依赖链缺乏容错与就绪感知——新实例没真正“活”起来，旧实例已被停掉，下游服务瞬间失联。关键不在“怎么快”，而在“怎么稳”。
确保健康检查真实有效
只靠容器状态（RUNNING）远远不够，必须验证应用层就绪。
- 在服务配置中显式定义 healthcheck，测试路径需命中业务真实入口（如
curl -f http://localhost/health或数据库连接探针） - 设置合理超时与重试：
timeout: 5s、retries: 5、start_period: 45s（尤其对 Spring Boot 等冷启动慢的服务） - 避免用
cmd: exit 0这类假健康检查，它会让 Compose 误判服务已就绪
用 condition 约束 depends_on 行为
默认的 depends_on 只等容器启动，不等健康；必须升级写法，让依赖服务“真正可用”后才启动当前服务。
- 将
depends_on: [db]改为： depends_on:<br> db:<br> condition: service_healthy
- 同时确保被依赖服务（如 db）已配置有效的
healthcheck，否则 condition 永远不满足
控制更新节奏，留出缓冲窗口
别贪快。parallelism=1 + delay=15s 是生产环境安全基线，给日志、监控、人工干预留出反应时间。
-
parallelism: 1：每次只更新一个副本，避免全量失败 -
delay: 15s：足够观察新容器日志、确认 HTTP 响应码、检查 DB 连接池初始化完成 -
failure_action: rollback：一旦某批次失败，自动回退到上一稳定版本，阻断蔓延
隔离故障域，避免雪崩传导
级联崩溃往往源于强同步调用+无降级。从架构层面做减法：
- 前端或网关层配置超时与熔断（如 Nginx 的
proxy_read_timeout 10s+proxy_next_upstream error timeout） - 服务间调用启用客户端重试（最多 2 次）和 fallback 逻辑，而非直接抛异常终止流程
- 关键依赖（如认证、配置中心）改用异步拉取+本地缓存，降低启动期强耦合
