政策快报平台的高可用架构：如何做到99.99%可用性
政策快报平台的目标可用性是99.99%（每年宕机时间不超过52分钟）。
这不是一个随便定的数字，是对用户承诺的“可靠性”——用户需要随时查到政策，不能接受“系统正在维护”。
从上线到现在，我们经历过几次故障，每一次都推动了高可用架构的升级。今天复盘这些升级。
4个关键设计
设计一：冗余——没有单点故障
高可用的第一条原则：任何单一组件故障，都不能导致整个系统不可用。
具体实现：
应用服务器：多节点部署（至少2个），负载均衡分发请求，单节点故障时自动切换
数据库：主从部署+自动故障切换，主库故障时自动将从库提升为新主库
缓存：Redis哨兵模式，主节点故障时自动选举新主
消息队列：RocketMQ多副本，单节点故障不影响消息读写
数据：2026年上半年，发生过2次单节点故障（一次应用服务器硬件故障，一次Redis主节点宕机），均实现自动切换，用户无感知。对于用户来说，系统一直在正常运行。
设计二：限流——防止过载拖垮系统
高可用的第二条原则：在流量超过系统承载能力时，主动拒绝部分请求，而不是让所有请求都失败。
限流策略：
接口级限流：每个接口独立配置QPS上限
用户级限流：单用户每秒请求数上限
集群级限流：总QPS超过阈值时，网关层统一拦截
效果：2025年某次政策发布高峰期，流量暴增10倍，限流策略触发了约5%的请求返回“繁忙”提示。系统没有崩溃，核心功能始终可用，97%的用户正常访问。
设计三：降级——核心功能优先
高可用的第三条原则：资源紧张时，优先保障核心功能，非核心功能可以临时关闭。
降级等级：
一级降级：关闭非核心功能（推荐、收藏、分享），释放资源给核心查询
二级降级：降低非核心功能频率（推送延迟发送）
三级降级：仅保留核心功能（政策列表+详情+搜索）
效果：2026年某次流量高峰，自动触发了一级降级。用户仍然可以正常搜索和查看政策，推荐位显示“服务调整中”，整体可用性保持在99.5%以上。
设计四：自动恢复——故障后能自己“站起来”
高可用的第四条原则：故障发生后，系统能自动恢复，不需要人工介入。
自动恢复策略：
应用自动重启：Pod异常时K8s自动重启
数据库自动切换：主库故障时自动切换到从库
缓存自动重建：Redis故障恢复后自动加载数据
消息队列自动重试：消费失败的消息自动进入重试队列
效果：2026年上半年，系统共发生8次自动恢复事件（包括应用重启、数据库切换、消息重试），平均恢复时间约2分钟，远快于人工介入的15-30分钟。
高可用架构的持续验证
高可用架构不是“建完了就完事了”，需要定期验证。
验证方式：
故障注入演练：定期模拟某组件故障，验证自动恢复是否生效
压测验证：模拟流量高峰，验证限流和降级策略是否生效
备份恢复演练：定期验证备份数据能否成功恢复
效果数据
| 指标 | 优化前（无高可用设计） | 优化后（高可用架构） |
|---|---|---|
| 可用性 | 约99.5%（年宕机约44小时） | 约99.98%（年宕机约1.8小时） |
| 故障发现时间 | 用户投诉后（分钟-小时级） | 系统自动发现（秒级） |
| 故障恢复时间 | 人工介入（15-60分钟） | 自动恢复（1-5分钟） |
| 单点故障 | 存在 | 不存在 |
经验总结
冗余是基础：没有冗余，就没有高可用
限流是保险：宁可拒绝部分请求，也不能让系统全挂
降级是底线：核心功能必须始终可用
自动恢复是关键：人工介入太慢，要能做到系统自愈
定期验证是保障：不验证的高可用方案，等于没有
高可用不是“建完就完事”的系统，是“持续验证、持续优化”的系统。冗余、限流、降级、自动恢复，每一步都需要投入，但每一步都能减少一次“系统不可用”的风险。