服务异常崩溃自动恢复需策略化：选对docker重启策略（always/unless-stopped/on-failure/no），必配健康检查，限制重启频率防雪崩，并兜底宿主机与依赖服务。
服务异常崩溃时的自动恢复，不能只靠“重启”二字应付。关键在于让恢复动作有判断、有节制、有兜底——既避免无限重启拖垮系统，又确保真正故障时能及时拉起服务。
选对重启策略是第一步
Docker 提供的四种重启策略不是随便挑一个就行，得看服务性质：
- always：适合 Nginx、Redis 等无状态核心服务，宿主机重启后也自动拉起，但必须配合健康检查，否则容器假死也会被强行重启
- unless-stopped：比 always 更稳妥，手动 stop 过的服务不会在 daemon 重启后自启，适合你明确想临时下线的场景
- on-failure[:3]：推荐用于应用类容器（如 Python/Java 服务），只在非零退出码时重试，加 max-retries=3 可防启动风暴
- no：CI/批处理任务用，失败就失败，不该自动续命
必须配健康检查，否则重启等于盲操作
光设 restart 不够。容器进程活着，但 HTTP 接口卡死、数据库连不上、线程全阻塞——这种“假活”状态，Docker 默认无法感知。必须显式定义 HEALTHCHECK：
- 用 curl -f http://localhost:8080/health 检查业务真实可用性，别只 ping 端口
- 设置 interval:30s timeout:5s retries:3 start_period:60s：给冷启动留足时间，避免刚起来就被判死刑
- 在 docker-compose.yml 中写进 healthcheck + deploy.restart_policy，两者协同才生效
限制重启频率，防雪崩连锁反应
微服务里一个服务频繁崩溃，会把依赖它的服务也拖垮。要主动控速：
- Docker 原生命令不支持退避重试（如指数退避），需靠外部编排工具补足；Kubernetes 中可用 backoffLimit 和 restartPolicy: OnFailure 组合控制
- 在应用层加启动保护：比如 Java 服务启动时检测 DB 连通性，失败直接 exit 1，触发 on-failure 重试，而非硬扛着跑
- 记录重启事件到日志或监控系统（如 Prometheus + Alertmanager），连续 3 次重启就告警，人工介入查根因
宿主机和依赖服务也要兜底
容器自动恢复再好，也架不住底层出问题：
- 用 systemd 管理 dockerd 本身：配置 Restart=always 和 StartLimitIntervalSec=60，防 Docker 守护进程挂掉
- Nginx 或 HAProxy 做前置负载均衡时，开启 health_check 和 max_fails=2 fail_timeout=30s，自动摘除异常后端
- 数据库、缓存等依赖服务，必须配置连接池超时、重试次数、熔断降级（如 Sentinel/Hystrix），别把所有希望押在容器重启上
