阿里同城双活架构详解(图文全面总结)

阿里同城双活是大型架构核心，下面我详解阿里同城双活架构@mikechen

阿里同城双活

随着互联网业务规模不断扩大，系统对高可用、高性能和快速恢复能力的要求也越来越高。

对于电商、支付、物流、内容分发等核心业务而言，单点故障已经无法接受。

传统的单机房、或单地域部署方式也越来越难以满足连续服务的需求。

在这一背景下，同城双活架构成为大型企业保障业务稳定性的重要方案之一。

所谓“同城双活”，是指在同一城市内部署两个或多个可独立承载业务的机房或数据中心。

平时两地同时对外提供服务，业务流量按一定策略分配。

当其中一地发生故障时，另一地能够迅速接管流量，保证业务连续运行。

阿里同城双活架构

同城双活的本质是分层高可用，从用户端到最终的存储层，每一层都要具备双活与路由能力。

                   [ 用户客户端 (App / Web) ]
                                |
                    [ DNS / 全局负载均衡 (GSLB) ]
                     /                         
           50% 流量 /                            50% 流量
                  v                             v
       ==================             ==================
       【 同城 A 机房 】               【 同城 B 机房 】
       ==================             ==================
       [ 统一接入层 (Nginx/SLB) ]      [ 统一接入层 (Nginx/SLB) ]
                  |                             |
       [ 微服务应用层 (RPC/Web) ] <--> [ 微服务应用层 (RPC/Web) ]  (跨机房RPC RPC)
                  |                             |
       [ 分布式缓存 (Redis) ]          [ 分布式缓存 (Redis) ]
                  |                             |
                                               /
                   v                           v
              [ 数据库层 (MySQL / 阿里自研 OceanBase) ]
              (核心：通过高可靠复制链路/分布式共识算法保持同步)

从技术实现上看，阿里同城双活通常包含几个关键层面。

第一是接入层双活。

用户请求会通过全局流量调度、DNS解析、SLB或其他智能调度系统进入不同机房。

正常情况下，两地按照设定比例分担流量，发生异常时，可以迅速将流量切走。

第二是应用层双活。

应用服务需要做到无状态或尽量弱状态化，使得任一机房都可以独立处理请求。

为了实现这一点，常采用会话外置、缓存共享、服务治理等方式。

第三是数据层双活。

这是整个架构中最复杂的部分，因为数据一致性直接决定业务正确性。

阿里在实践中通常会根据业务类型选择不同的数据同步方案，如强一致、最终一致或分级容忍策略，以平衡性能与一致性。