随着苏宁线下线上业务以及全产业、全业态规模式快速增长，特别是每年苏宁 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、高可用实现
高可用实现原则
数据中心高可用分成两部分：
单数据中心内高可用
集群内部高可用
无状态服务 (比如应用服务器)：采用 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 研发设计和规划工作。
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论 3 条评论