随着苏宁线下线上业务以及全产业、全业态规模式快速增长，特别是每年苏宁 818 大促、双 11 等大促节点，销售订单基本都呈现倍数级增长态势，需要进行大量资源扩容，单个数据中心的容量有限，已经无法支撑苏宁业务的快速发展。同时，单数据中心在高可用上存在不足，一旦数据中心发生故障，会导致业务受损，用户访问中断，带来严重的影响。 针对以上问题，苏宁规划建设多数据中心解决方案迫在眉睫。

1 方案选择

参考业界多数据中心实践，目前主流的多数据中心的解决方案有如下几个：

• 主备模式
• 同城双活
• 多活模式

介绍这几个方案前，我们先来看下相关概念:

• Cell：业务可封闭收敛最小执行分片；业务对请求空间按一定维度（比如会员、门店等）划分分片。
• LDC：逻辑数据中心，是由多个业务可封闭 cell 组成的集合单元，拥有独立的基础中间件系统（包括 RPC， MQ， DNS 等），以及出口网络等。
• PDC：物理数据中心，指物理上独立的一栋建筑，一般每栋有好几层, 存放一系列机柜和上千和上万服务器, 构成一个 PDC。
• AZ（Available Zone）：可用区，具有独立的故障隔离空间，拥有独立网络设施或电力设备，由相邻的单个或多个 PDC 组成。
• Region：地理区域，有多可用区所组成的集合，区域之间故障域完全隔离。

1、主备模式

主机房提供服务，备用机房不提供服务，当主机房故障，服务可切换到备用机房接管。

2、同城双活

同一个集群横跨同城两个不同的 AZ，两个 AZ 同时对外提供服务，同时允许跨机房访问不同服务以及数据库。

3、多活模式

多个机房同时提供服务，业务请求尽量收敛在同一个机房，当某个机房故障时，可以切换其它接管机房。

4、方案比较

鉴于苏宁线上 / 线下交易业务和支付业务特性，以及异地数据中心的要求，通过技术评估和决策，最终选择多活模式。

由于选择了难度最大的一种方案模式，多活方案将涵盖苏宁所有核心业务以及基础组件，需要考虑和关注的问题非常多，一旦设计发生偏差，调整的代价将非常大。为了确保方案的合理性，可实施性，首先我们讨论并制定了顶层设计，包括目标、价值和设计原则，并在设计过程中不断的复盘，以保证设计不偏离主航道。

2 顶层设计

顶层设计是多活相关的干系中心经过充分讨论，并最终达成一致的最高方针。总体方案以及各个业务系统方案都必须有严格遵守的规范和要求，包括目标、价值和原则。

1、目标

1. 机房水平扩展：单机房容量有限，业务高增长带来大量的资源需求，多活需要具备机房水平扩展能力，为资源扩容提供保障。
2. 机房之间同城和异地高可用：单机房存在单点故障风险，多活需要具备机房级别的高可用能力，在一个机房出现故障时，能够将流量快速切到其他正常的机房，对业务的影响降低到最小。

2、价值

1. 支持业务的快速发展：苏宁每年的业务规模成倍数级增长，所依赖的 IT 资源也快速增长，通过机房的水平扩展，解决单机房容量不足问题，以支持业务的发展。
2. 同城与异地容灾：当机房出现电源或网络以及地震等机房级别故障，通过机房级别的流量切换实现同城与异地容灾，将对业务的影响降低到可控水平。
3. 混合云降低持有成本：由于电商业务的特殊性，大促流量与平时流量相差上百倍，大促期间将流量划拨到公有云，在多活能力的基础上，实现私有云与公有云混部，降低私有云长期持有成本。
4. 灰度发布：实现按机房级别流量逐步灰度发布，降低业务版本故障影响面，提升版本发布质量。

3、原则

1. 同一用户的交易尽量在一个数据中心内部完成。苏宁对于交易业务按照用户纬度对数据分片，特定的用户路由到特定的数据中心，保证一个用户的交易在一个数据中心完成。
2. 业务无需感知多数据中心。核心业务在多个数据中心部署，提供服务，业务无需感知自己在哪个机房，即便数据中心发生切换，业务也无需感知。
3. 尽量节省资源。由于多机房部署导致成本上升，需要通过调整高可用部署方案降低多机房部署成本。

基于顶层设计的要求，开始多活总体方案的架构设计。

3 架构设计1、相关概念

• 分片服务：对应的数据仅在某个 Cell 存在，其它 Cell 不与交叉或共享，比如会员服务、订单服务等。
• 共享服务：所有 Cell 拥有相同的数据，相互共享，比如价格服务、商品服务等。
• 索引服务：用于索引数据提供服务，类似共享服务。
• 竞争 (控制) 服务：各个 Cell 相互操作同一个数据，为了保证数据一致性，需要在同一个数据中心进行控制，比如库存的扣减、用户注册等。
• 竞争 Proxy 服务：用于竞争服务前置服务，比如库存前置调拨服务。

2、服务架构

按照用户分布到不同的数据中心，多个数据中心都提供服务，在一个数据中心出现问题时，可以随时将流量切到另外一个正常的数据中心。

• 服务规划：根据业务不同功能，将服务拆分为分片服务，共享服务，竞争服务，索引服务，控制服务以及管理服务。各服务类型单独设置路由规则，同时支持灰度路由。
• 统一服务路由：从接入层到服务层以及最终的数据层，都遵守统一的路由策略，保证同一用户的交易在一个数据中心完成。
• 数据高可用：多数据中心保证数据库高可用，采用全冗余方式，数据在任何一个数据中心都是可用的，从而保证高可用，任一数据中心故障，不影响数据的可用性。

3、服务路由

流量的分布是由服务路由来决定的，而路由的功能由各组件承载并实现，主要分成以下几部分：

• DNS：根据用户所在位置就近路由到对应的 CDN。
• CDN：根据用户请求信息按照一定的规则路由到对应的数据中心。
• SLB：根据用户请求信息路由到同机房或其它机房。
• RPC/MQ：根据用户请求信息按照一定的路由规则分发到不同的数据中心。
• DAL：数据接入层对用户所处的分片进行校验，确保不出现数据异常或数据冲突。

4、服务收敛

基于服务路由的功能，为了实现同一用户的交易在同一数据中心进行，减少跨数据中心网络延迟，需要对用户流量进行精准分发。流量在进入数据中心前，按照一定的路由规则，确定好待分发的目标中心，以减少数据中心之间的二次转发。比如，苏宁在 CDN 层进行用户的初次路由，将用户分发到不同的数据中心。

数据中心内部，对服务层设置多种路由策略，比如设置接入层、RPC、DAL 等的路由方式以及业务服务拆分，使得同一个用户所有请求尽量收敛在同一个数据中心，实现流量精准划拨，避免跨机房调用。

请求的收敛设计确保流量按照 Cell 级别划拨到不同的数据中心，并在同一中心封闭收敛，这也是实现多数据中心部署的基础。

5、数据高可用

为了确保数据高可用以及任何一个机房故障都可被接管，所有数据中心都包含全量数据，当主数据中心的变更将会实时同步到各个从数据中心。

数据中心之间延迟相对数据中心内部延迟较大，数据中心之间的同步一般采用异步复制方式。在机房故障等极端情况，将出现少量数据未同步到其它数据中心，针对此类故障场景，在机房恢复后，需要对未同步的数据进行人工修复。

4 技术难点

按照多活的架构设计，并结合苏宁的业务特点和 IT 技术现状，需要优先解决相关的技术难点。

1、高可用实现高可用实现原则

数据中心高可用分成两部分：

单数据中心内高可用

• 集群内部高可用无状态服务 (比如应用服务器)：采用 N+1 方式部署，任何一台故障，流量都可被其它机器所接管。有状态服务 (比如数据库)：采用 2N（一主一从）或 3N（一主两从）方式部署，任何一台故障，在秒级切换到另外一台机器。

多数据中心间高可用

• 单系统同城高可用：任何一个系统有计划维修或非计划性故障，都可切换到另外一个数据中心
• 全链路同城高可用：当机房级别故障或维修时，可切换到另外一个机房接管。
• 全链路异地高可用：当出现地震等特殊场景，异地机房可进行接管，避免同城两个数据中心同时故障等异常场景。

其中机房级别故障切换时间一般在分钟级别。

高可用实现指标

• RPO(Recovery Point Object)：表示机房级别故障时，未被同步的数据时长。考虑到 MySQL 在特殊情况下复制延迟较大情况下，RPO 设置为分钟级别，正常情况下 RPO 为秒级
• RTO(Recovery Target Object)：表示机房故障情况下，关键流程或系统切换恢复时间，一般为分钟级别
• WRT(Work Recovery Time)：表示故障时，由于 RPO 导致的未同步异常数据修复完成时长，一般为小时级别。

高可用实践

服务切换

（1）数据复制拓扑结构

对于分片数据跨机房复制方式主要分成两种：

• 单向交叉复制：两个机房同一个分库的两个不同集群之间采用主备模式进行复制，仅主集群提供写操作，如上图所示 Cell4 的 LDC-B 做为主集群复制到 LDC-A 备集群， Cell8 的 LDC-A 主集群复制到 LDC-B 的备集群
• 双向复制：两个机房同一个分库的两个不同集群之间采用主 – 主模式进行复制，两个机房的集群同时提供写操作服务

复制拓扑结构比较

为了确保数据的一致性和避免出错概率以及数据存储分布不规整，苏宁初期采用单向交叉复制拓扑结构。

（2）数据迁移与规整

为了实现按用户分 Cell 分布到不同数据中心，并且苏宁业务形态的多样性以及一些历史遗留问题，比如单表记录过多（超过 1 亿），不利于多数据中心的扩展，为此需要对数据按照一定的规则重新迁移和规整。

• 对原有数据做快照，然后对快照数据重新规整到新的分库分表。
• 对原有集群增量数据准实时抽取 Binlog 数据规整到新的集群。
• 通过 DAL 灰度划拨流量写入到新的集群，直至所有数据切换到新集群。

（3）服务切换

对于分片数据服务，分片服务按照一定规则对 Cell 分组进行切换，确保应用层的服务和数据可以同时切换，避免数据写入异常。

跨数据链路切换

为了实现部分流量全链路划拨到不同的数据中心，以及在数据中心故障时能够快速接管业务，所有多数据中心流程分发和服务调度全部由基础中间件平台完成，无需业务感知数据中心故障或流量划拨，这样整体切换时间会大大缩短，快速恢复业务。从而实现数据中心之间同城高可用以及异地高可用。

具体步骤如下：

• 接管机房对应的从库提升为主库。
• 服务写操作切换到新的接管机房。
• 服务（SLB/RPC/MQ）切换到新的接管机房。
• CDN 流量重定向到新的接管机房。

2、灰度部署与上线

为了确保多机房部署时，拓扑结构和配置的变化，不影响到整个业务系统运行，采用灰度部署方案，分以下几个阶段：

• 基础组件部署：比如 RPC、MQ、WAF、数据库等的部署
• 业务系统部署：比如订单系统、会员系统、促销系统、商品系统等的部署

组件和系统部署完成了，为了确保业务稳定上线，生产的流量逐步划拨，前一个步骤的完成为下一个步骤的准入条件。

具体如下：

• 用白名单（内部用户）进行测试，验证部署和配置的正确性。
• 进行单系统流量划拨，确保每个系统切换的正确性。
• 全链路流量划拨，确保端到端切换的正确性。

3、全链路监控

苏宁的业务种类繁多，为确保核心交易业务的可靠性和扩展性，现阶段优先对这些业务进行多活改造和多数据中心部署。

一次交易请求，落在哪个数据中心处理，请求失败是由哪个业务节点导致等等，这就需要一套完善的监控平台，对全链路，多数据中心的各个环节进行全方位，高精度的监控。

监控平台主要分成以下几个部分：

• 日志：分别在每个机房部署日志组件，避免跨机房传输日志带宽消耗，查询通过联邦模式汇总查询。
• 指标 (metrics): 每个机房汇总到指标数据到主机房，以便指标在主机房汇总查询。
• 调用链：分别在每个机房部署调用链，调用链也是通过联邦模式查询。

4、故障演练

为了模拟机房故障，通过混沌工程逐步提高爆炸半径，模拟业务故障，减少对业务的影响，主要故障模拟如下：

• 单系统故障模拟：比如订单系统或会员系统单个系统故障
• 全链路故障模拟：比如交易链路或支付链路多个系统同时故障
• 网络故障模拟：比如交换机或路由器等故障
• 整个机房级别故障模拟：比如电源（市电、UPS 等）故障导致整个机房故障

通过混沌工程模拟可以相对真实验证整个多活系统的容灾能力，整个模拟对业务的影响都相对可控，大大降低对业务的影响。

5 多活拓展

在多活方案设计过程中，需要综合考虑苏宁 IT 基础设施规划，其中异地部署和混合云部署是多活能力的拓展和延伸。

1、异地部署

由于同城机房资源受限，并且同城部署无法解决地震等极端故障，因此需要引入异地部署。异地多数据中心相比同城多数据中心，最大的问题就是网络延迟明显增大，数据中心的宽带相对受限，需要在架构和整体的解决方案上进行考虑，通过技术手段实现异地多数据中心的高可用性，降低延迟。同时需要通过组件对传输数据进行压缩和传输限流，确保传输的数据在有限的宽带可控范围内。

苏宁多活架构从一开始就是按照异地部署架构来设计，大大降低同城和异地部署异构性和运维复杂性。

2、混合云部署

苏宁业务系统大促流量是平时业务流量的十倍甚至上百倍，日常资源都是按照大促的峰值进行准备，资源持有和运维成本较高，资源采购，上线周期较长。因此大促期间，通过将部分流量弹到公有云，利用公有云的弹性能力，为私有云进行削峰，大大降低苏宁私有云长期持有成本，以及运维成本。

混合云相比原有多活需要做如下的能力拓展：

• 安全管控：公有云与私有云属于不同的信任域，对于公有云与私有云相互访问进行管控，确保混合云网络之间安全；以及公有云数据存储安全管控。
• 快速部署：由于公有云是根据按量或按月 / 按年计费，快速部署能力可以降低公有云资源成本使用时长。
• 非对称部署：由于公有云与私有云处理能力不一样，可以通过非对称部署降低公有云和私有云成本。

6 总结

多数据中心多活项目作为苏宁重大项目，经过 3 年左右的建设，已于 2019 年上线，历经 818 和双 11 等大促考验，实现关键链路从单机房平滑过渡到多机房的突破，支撑了业务的快速发展；并在机房出现真实故障时，快速实现业务恢复，将故障影响降低到可控范围内。

混合云项目经历一年左右的建设，也已初具规模，将为苏宁后续的业务高速发展保驾护航，降低公司大促扩容成本。

作者介绍

陈跃泉，苏宁科技集团 CTO 办公室技术架构部负责人，架构总监，苏宁多活多数据中心项目首席架构师和混合云项目总体技术负责人，拥有 15+ 年零售、电信、金融等超大型或大型项目架构设计经验，对大规模分布式系统 PaaS 和 IaaS 架构设计有深入的理解和思考。

涂成义，苏宁科技集团 CTO 办公室技术架构部高级架构师，曾在华为，中兴等多家 IT 公司任职架构设计，技术负责人。目前专注于云计算相关技术研究，对高并发，高可用架构有较深入的理解和思考，多活多数据中心项目核心成员。

马忠成，苏宁科技集团 CTO 办公室技术架构部高级架构师，多活多数据中心项目核心成员，在加入苏宁之前从事多年的运营商 IPTV、CDN 研发设计和规划工作。

关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书，点击文末「了解更多」，即可移步InfoQ官网，获取最新资讯～