多活部署是通过地理、逻辑、数据、服务多维活性分布实现高可用，要求跨地域全量服务、单元化隔离、数据多写强一致及流量与治理双冗余。

多活部署是高可用架构中消除单点故障最有效的手段之一，它不是简单地“多放几台机器”，而是通过地理、逻辑、数据、服务多个维度的活性分布，让系统在任一节点、区域或组件失效时，其余部分仍能独立承载完整业务流量。

跨地域多活：打破物理层面的单点依赖

单数据中心或单云环境天然存在地域性风险——电力中断、光缆被挖、自然灾害都可能导致整体瘫痪。多活部署要求至少两个以上独立可用区（如阿里云杭州+腾讯云上海），且每个站点都具备全量服务能力（非仅读能力）。

• 每个站点部署完整的应用集群、数据库分片、缓存与消息队列，支持用户就近接入
• 通过全局流量调度（如Anycast DNS或智能网关）实现请求自动路由，故障时秒级切流
• 典型目标：RTO < 30秒、RPO = 0，即切换快、不丢数据

单元化拆分：隔离故障爆炸半径

即使多地都“活着”，若所有服务共用同一套数据库或共享中间件，一个模块异常仍可能拖垮全局。单元化是多活落地的关键设计。

• 按业务维度（如“订单”“支付”“用户”）或租户维度（如按省份/渠道）划分逻辑单元
• 每个单元内闭环完成读写，跨单元调用走异步或最终一致性协议
• 某单元因数据库锁表卡死，只影响该单元用户，其他单元照常运行

数据多活：避免数据库成为新SPOF

传统主从复制本质仍是“一主多从”，主库就是单点。真正的数据多活需满足：任意节点可读可写、变更实时同步、冲突可收敛。

• 采用分布式数据库（如YashanDB多活集群、TiDB、OceanBase）或成熟多主方案（如Galera、MySQL Group Replication）
• 写入请求由本地节点处理，通过Paxos/Raft等共识算法保障多副本强一致
• 配合全局事务ID（GTID）、冲突检测策略（如时间戳/向量时钟）解决跨单元并发写冲突

流量与治理双冗余：让“活”真正可持续

多活不是静态部署完就结束，而是一套持续运行的动态保障体系。

• API网关和注册中心必须多活部署，避免它们自身变成新单点；服务发现需支持跨域健康探活（不只是端口通，还要校验响应时延与成功率）
• 配置中心、限流熔断规则、灰度开关等治理能力需全局同步，确保故障时降级策略一致生效
• 定期开展真实故障演练：随机下线一个AZ的全部数据库节点，验证是否自动剔除、流量是否重分、数据是否未丢失、监控告警是否准确触发