作者 | 陈跃泉、涂成义、马忠成
策划 | 蔡芳芳
随着苏宁线下线上业务以及全产业、全业态规模式快速增长，特别是每年苏宁 818 大促、双 11 等大促节点，销售订单基本都呈现倍数级增长态势，需要进行大量资源扩容，单个数据中心的容量有限，已经无法支撑苏宁业务的快速发展。同时，单数据中心在高可用上存在不足，一旦数据中心发生故障，会导致业务受损，用户访问中断，带来严重的影响。针对以上问题，苏宁规划建设多数据中心解决方案迫在眉睫。
1 方案选择
参考业界多数据中心实践，目前主流的多数据中心的解决方案有如下几个：
- 主备模式
- 同城双活
- 多活模式
介绍这几个方案前，我们先来看下相关概念:
- Cell：业务可封闭收敛最小执行分片；业务对请求空间按一定维度（比如会员、门店等）划分分片。
- LDC：逻辑数据中心，是由多个业务可封闭 cell 组成的集合单元，拥有独立的基础中间件系统（包括 RPC， MQ， DNS 等），以及出口网络等。
- PDC：物理数据中心，指物理上独立的一栋建筑，一般每栋有好几层, 存放一系列机柜和上千和上万服务器, 构成一个 PDC。
- AZ（Available Zone）：可用区，具有独立的故障隔离空间，拥有独立网络设施或电力设备，由相邻的单个或多个 PDC 组成。
- Region：地理区域，有多可用区所组成的集合，区域之间故障域完全隔离。
1、主备模式
主机房提供服务，备用机房不提供服务，当主机房故障，服务可切换到备用机房接管。
2、同城双活
同一个集群横跨同城两个不同的 AZ，两个 AZ 同时对外提供服务，同时允许跨机房访问不同服务以及数据库。
3、多活模式
多个机房同时提供服务，业务请求尽量收敛在同一个机房，当某个机房故障时，可以切换其它接管机房。
4、方案比较
鉴于苏宁线上 / 线下交易业务和支付业务特性，以及异地数据中心的要求，通过技术评估和决策，最终选择多活模式。
由于选择了难度最大的一种方案模式，多活方案将涵盖苏宁所有核心业务以及基础组件，需要考虑和关注的问题非常多，一旦设计发生偏差，调整的代价将非常大。为了确保方案的合理性，可实施性，首先我们讨论并制定了顶层设计，包括目标、价值和设计原则，并在设计过程中不断的复盘，以保证设计不偏离主航道。
2 顶层设计
顶层设计是多活相关的干系中心经过充分讨论，并最终达成一致的最高方针。总体方案以及各个业务系统方案都必须有严格遵守的规范和要求，包括目标、价值和原则。
1、目标
- 机房水平扩展：单机房容量有限，业务高增长带来大量的资源需求，多活需要具备机房水平扩展能力，为资源扩容提供保障。
- 机房之间同城和异地高可用：单机房存在单点故障风险，多活需要具备机房级别的高可用能力，在一个机房出现故障时，能够将流量快速切到其他正常的机房，对业务的影响降低到最小。
2、价值
- 支持业务的快速发展：苏宁每年的业务规模成倍数级增长，所依赖的 IT 资源也快速增长，通过机房的水平扩展，解决单机房容量不足问题，以支持业务的发展。
- 同城与异地容灾：当机房出现电源或网络以及地震等机房级别故障，通过机房级别的流量切换实现同城与异地容灾，将对业务的影响降低到可控水平。
- 混合云降低持有成本：由于电商业务的特殊性，大促流量与平时流量相差上百倍，大促期间将流量划拨到公有云，在多活能力的基础上，实现私有云与公有云混部，降低私有云长期持有成本。
- 灰度发布：实现按机房级别流量逐步灰度发布，降低业务版本故障影响面，提升版本发布质量。
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、高可用实现
高可用实现原则
数据中心高可用分成两部分：
（1）单数据中心内高可用
- 集群内部高可用
- 无状态服务 (比如应用服务器)：采用 N 1 方式部署，任何一台故障，流量都可被其它机器所接管。
- 有状态服务 (比如数据库)：采用 2N（一主一从）或 3N（一主两从）方式部署，任何一台故障，在秒级切换到另外一台机器。
（2）多数据中心间高可用
- 单系统同城高可用：任何一个系统有计划维修或非计划性故障，都可切换到另外一个数据中心
- 全链路同城高可用：当机房级别故障或维修时，可切换到另外一个机房接管。
- 全链路异地高可用：当出现地震等特殊场景，异地机房可进行接管，避免同城两个数据中心同时故障等异常场景。
其中机房级别故障切换时间一般在分钟级别。
高可用实现指标
- 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 研发设计和规划工作。
