高可用建设需分阶段演进：先消除单点（如单web服务器、单数据库），再逐层冗余与自动故障响应，最后按业务分级容灾并灰度迁移。
高可用不是一步到位的配置，而是一条有节奏、分阶段、可验证的演进路径。真正可行的建设方式，是围绕业务容忍度，从最脆弱的单点开始加固，逐层补强，每一步都带来实际可用性提升，而不是直接套用“两地三中心”这类终极方案。
先识别并消灭最致命的单点
系统里只要存在一个无法替代的组件，就谈不上高可用。常见单点包括：单台Web服务器、单一数据库实例、唯一负载均衡器、共用缓存节点、集中式文件存储。这些不是理论风险，而是线上真实故障源头——一次磁盘损坏、一次误操作、一次网络抖动，就能导致全线中断。
- 优先给Web服务加第二台机器，配合Nginx或云厂商SLB做基础负载分发
- 数据库立即启用主从复制，哪怕初期只读流量不切过去，至少保障RPO可控
- 负载均衡本身也必须冗余，比如用Keepalived实现VIP漂移，或直接选用云平台多可用区部署的托管型LB
让每一层具备基本故障响应能力
光有冗余不够，还得能自动应对异常。接入层要能发现后端宕机并摘除节点；应用层需无状态设计，支持快速扩缩；数据层得有明确的主备切换机制，避免人工干预延迟。
- 所有服务实例注册到Nacos/Consul等注册中心，并配置健康检查（HTTP /health 或 TCP 端口探测）
- 数据库主从间开启半同步复制，确保至少一个从库写入成功才返回客户端，把RPO压到接近0
- API网关启用限流和熔断，当某个下游服务错误率超阈值时自动隔离，防止雪崩扩散
按业务影响分级推进容灾能力
不同模块对中断的承受力不同。核心交易系统可能要求RTO＜30秒、RPO＝0；而报表类服务允许小时级恢复。不必统一标准，而是依据SLA分级投入：
- 一级系统（如支付、开户）：部署跨可用区双活，写请求由中间件路由到本地主库，读请求就近访问
- 二级系统（如用户中心、日志分析）：采用同城双中心主备，故障时分钟级手动或半自动切换
- 三级系统（如后台管理、内部工具）：主从+定期备份即可，RTO控制在1小时内
迁移过程本身必须可灰度、可回退
从旧架构走向新架构，最大的风险不在技术，而在切换动作。任何“一次性全量切换”都是高危操作。平滑过渡的关键在于让新老体系并行运行，并逐步转移流量。
- 用影子库/影子表同步写入新旧数据库，验证数据一致性后再开放读流量
- 通过网关或配置中心控制灰度比例，例如先放5%真实请求到新集群，观察错误率与延迟
- 每次变更保留完整回滚脚本，包括数据库回退语句、配置还原步骤、服务版本切换指令
