应用容灾设计要点
容灾能不能切换成功，很大程度取决于应用自身是否为『被替换』做好了准备：实例无状态、会话外置、配置与密钥集中管理、依赖可降级、操作幂等。这些工作平时不显眼，切换时却决定成败。切换的常见卡点不在数据库，而在应用启动依赖——证书、密钥、外部回调地址、白名单，任何一个缺失都会让应用起不来。
基本信息
| 设计目标 | 任一实例可以被随时替换，切换后短时间内可对外服务 |
|---|---|
| 关键改造 | 无状态化、会话外置、配置中心化、依赖治理、幂等重试 |
| 验证手段 | 探针分离、切换演练、启动依赖清单核对 |
| 常见遗漏 | 本地缓存、节点本地文件、硬编码 IP、证书与密钥分发 |
典型使用场景
- 主备机房切换：备侧实例拉起后无需人工干预即可接流量
- 滚动发布与弹性伸缩：实例随时可替换，发布不影响存量连接
- 数据库迁移：应用通过配置切换连接，不改代码
- 故障隔离：单个实例异常被自动摘除，不影响整体
- 多活单元化：流量调度到其他单元时应用行为可预期
健康检查与就绪分离
健康检查与就绪分离
# readinessProbe：未通过则不接流量，用于启动依赖尚未就绪的阶段
readinessProbe:
httpGet: { path: /healthz, port: 8080 }
initialDelaySeconds: 5
periodSeconds: 5
# livenessProbe：失败则重启容器，用于进程假死
livenessProbe:
httpGet: { path: /livez, port: 8080 }
periodSeconds: 10
failureThreshold: 3
# 要点：/healthz 检查数据库、缓存、关键下游是否可用
# /livez 只检查进程本身，避免下游抖动引发整批重启启动依赖清单
| 类别 | 典型项 | 缺失后果 |
|---|---|---|
| 凭据与密钥 | TLS 证书、密钥管理服务凭据 | 应用启动即失败 |
| 配置 | 配置中心连通性、环境变量 | 启动参数缺失或指向错误环境 |
| 网络 | 下游白名单、DNS 解析、出网策略 | 启动成功但调用全超时 |
| 外部依赖 | 回调地址、短信与支付通道 | 部分功能不可用，业务侧才暴露 |
把启动依赖清单化并在切换演练中逐项核对，比事后排查快得多。清单也要覆盖操作系统层：时钟同步、文件句柄与进程数限制、内核参数。