迎战双11,苏宁的多数据中心多活如何建成? 发布时间:2020-10-30

随着苏宁线下线上业务以及全产业、全业态规模式快速增长,特别是每年苏宁 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 等大促考验,实现关键链路从单机房平滑过渡到多机房的突破,支撑了业务的快速发展;并在机房出现真实故障时,快速实现业务恢复,将故障影响降低到可控范围内。

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

相关推荐: ODCC名誉主席、中国信通院云大所所长何宝宏:数据中心新趋势及第三方运营商市场分析

很高兴,换了一个身份站在这儿,跟大家分享一下关于数据中心新趋势我个人的与团队的看法,以及发布的第三方运营商分析报告。上个世纪以来,互联网致力于通信基础设施的通用化。过去10年云计算和数据中心致力于将计算基础设施化。现在我们有了通信做基础设施的支撑,有了计算做基…