目标：抗抖动、抗故障、可恢复，保障核心链路可靠。
🎯 文章目标
- 设计多副本/多 AZ、降级与熔断
- 故障演练与容灾切换
- 指标与应急预案
📚 背景/前置
- 推理服务往往有状态（模型加载、KV 缓存）
- 高可用需考虑“发布、扩容、硬件故障、网络故障”
🔧 核心内容
1) 高可用拓扑
- 多副本 + HPA
- 多可用区/多机房（有条件）
- 网关熔断与降级路径（如改小模型/短上下文）
2) 故障演练
- 定期注入失败：提升团队响应
- 演练场景：GPU 故障、网络隔离、模型下载失败
3) 容灾
- 冷/温/热备：成本 vs 恢复时间
- 切换策略：DNS/网关层/服务发现
💡 实战示例：熔断降级
javascript
if (latency_p95 > 2000 || error_rate > 0.05) route = 'small-model'📊 对比/取舍（速查）
- 成本 vs 恢复时间：热备最快、成本最高
- 可用性 vs 一致性：视业务选择
🧪 踩坑与经验
- 无演练导致真正故障时手忙脚乱
- 无降级导致全量超时
📎 参考与延伸
- 混沌工程、SLA/SLO
- 网关熔断/降级实践
💭 总结
- 以“多副本 + 演练 + 容灾 + 熔断/降级”建立高可用防线