az服务器购买(历时三年,苏宁如何建设多数据中心多活的实践项目?)

博主:xiaoweixiaowei 2022-12-18 条评论

随着苏宁线下线上业务以及全产业、全业态规模式快速增长,特别是每年苏宁 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 导致的未同步异常数据修复完成时长,一般为小时级别。

高可用实践

az服务器购买(历时三年,苏宁如何建设多数据中心多活的实践项目?)

服务切换

(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官网,获取最新资讯~

The End

发布于:2022-12-18,除非注明,否则均为 主机评测原创文章,转载请注明出处。