政策快报平台的目标可用性是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分钟单点故障存在不存在经验总结冗余是基础没有冗余就没有高可用限流是保险宁可拒绝部分请求也不能让系统全挂降级是底线核心功能必须始终可用自动恢复是关键人工介入太慢要能做到系统自愈定期验证是保障不验证的高可用方案等于没有高可用不是“建完就完事”的系统是“持续验证、持续优化”的系统。冗余、限流、降级、自动恢复每一步都需要投入但每一步都能减少一次“系统不可用”的风险。