政策快报平台的目标可用性是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分钟。

高可用架构的持续验证

高可用架构不是“建完了就完事了”，需要定期验证。

验证方式：

• 故障注入演练：定期模拟某组件故障，验证自动恢复是否生效

• 压测验证：模拟流量高峰，验证限流和降级策略是否生效

• 备份恢复演练：定期验证备份数据能否成功恢复

效果数据

经验总结

• 冗余是基础：没有冗余，就没有高可用

• 限流是保险：宁可拒绝部分请求，也不能让系统全挂

• 降级是底线：核心功能必须始终可用

• 自动恢复是关键：人工介入太慢，要能做到系统自愈

• 定期验证是保障：不验证的高可用方案，等于没有

高可用不是“建完就完事”的系统，是“持续验证、持续优化”的系统。冗余、限流、降级、自动恢复，每一步都需要投入，但每一步都能减少一次“系统不可用”的风险。