99.99%可用性核心是构建“故障不扩散、服务不停摆、数据不丢失”的系统性防线，全年停机≤52.6分钟，需多区域多可用区冗余、GSLB全局调度、多活数据库（RPO<100ms，RTO<30s）、微服务隔离、Service Mesh熔断限流、缓存强一致性、Saga事务及可观测驱动的自动闭环自愈。

要实现全栈业务的99.99%可用性，核心不是堆砌技术，而是围绕“故障不扩散、服务不停摆、数据不丢失”构建系统性防线。全年允许停机时间仅52.6分钟，这意味着任何单点依赖、手动干预环节或未覆盖的故障场景都可能直接击穿目标。

多区域+多可用区冗余部署

地理级容灾是底线保障。不能只在单个云区域（Region）内做高可用，必须跨至少两个物理隔离的Region部署核心服务，比如用户认证、订单、支付等关键链路。每个Region内部再跨至少三个可用区（AZ）部署，数据库主从节点、应用实例、缓存集群全部打散分布。

• 使用GSLB（如Cloudflare Load Balancing或AWS Global Accelerator）做全局流量调度，DNS TTL设为≤60秒，并开启健康检查自动剔除故障Region
• 数据库采用多活架构，例如TiDB跨Region部署或阿里云PolarDB GDN，RPO控制在100ms内，RTO小于30秒
• 静态资源走CDN，动态API通过Anycast IP接入，避免DNS解析单点和网络路径单点

微服务化与故障隔离设计

单体架构天然无法满足四个九，必须拆分为边界清晰、自治演进的微服务。重点不在“拆多少”，而在“断得干净”——一个服务崩溃不能拖垮登录、不能卡住下单、更不能污染数据库连接池。

• 每个服务独立部署、独立扩缩容，Kubernetes中用Deployment+HPA按QPS或延迟指标自动伸缩
• 服务间通信引入Service Mesh（如Istio），配置熔断（如连续5次超时触发）、重试（最多2次，带指数退避）、限流（按租户/接口维度）
• 非核心功能默认降级：报表生成失败不阻塞客户查看，搜索无结果可返回缓存快照，日志写入失败转为本地异步落盘

数据层强一致性与弹性保障

99.99%可用性下，数据不能靠“事后修复”，必须在写入路径就保证可靠。缓存、数据库、消息队列三者协同，而非各自为政。

• 写操作采用“先写DB，再删缓存”或“更新DB + 延迟双删”，禁用“先删缓存再写DB”这种易脏读模式
• Redis使用Cluster模式，配置min-slaves-to-write 1，确保至少一个从节点同步成功才返回写成功
• 关键事务（如扣库存+锁单）用Saga模式分步执行，每步有补偿动作；非关键事务可接受最终一致性，但需明确标注并监控延迟水位

可观测驱动的自愈闭环

人工响应速度永远赶不上故障传播速度。真正的高可用依赖“发现-定位-恢复”全流程自动化，且恢复动作必须经过充分验证。

• Prometheus采集黄金信号（延迟、错误率、流量、饱和度），Grafana看板按服务/区域/链路分层下钻
• 告警分级：P0级（核心交易失败率>0.5%持续1分钟）自动触发预案，如切流、重启Pod、降级开关；P1级（某AZ延迟突增）仅通知值班工程师
• 所有预案经混沌工程定期验证，比如每月模拟一次Redis节点宕机，检验缓存重建逻辑与DB回源能力是否达标