![850003edd42d91c2e3f3855ad088ce3b.png](https://i-blog.csdnimg.cn/blog_migrate/43c1010f8133fcec3c6694d4e8a85195.jpeg)
随着苏宁线下线上业务以及全产业、全业态规模式快速增长,特别是每年苏宁 818 大促、双 11 等大促节点,销售订单基本都呈现倍数级增长态势,需要进行大量资源扩容,单个数据中心的容量有限,已经无法支撑苏宁业务的快速发展。同时,单数据中心在高可用上存在不足,一旦数据中心发生故障,会导致业务受损,用户访问中断,带来严重的影响。 针对以上问题,苏宁规划建设多数据中心解决方案迫在眉睫。
1 方案选择
参考业界多数据中心实践,目前主流的多数据中心的解决方案有如下几个:
- 主备模式
- 同城双活
- 多活模式
介绍这几个方案前,我们先来看下相关概念:
- Cell:业务可封闭收敛最小执行分片;业务对请求空间按一定维度(比如会员、门店等)划分分片。
- LDC:逻辑数据中心,是由多个业务可封闭 cell 组成的集合单元,拥有独立的基础中间件系统(包括 RPC, MQ, DNS 等),以及出口网络等。
- PDC:物理数据中心,指物理上独立的一栋建筑,一般每栋有好几层, 存放一系列机柜和上千和上万服务器, 构成一个 PDC。
- AZ(Available Zone):可用区,具有独立的故障隔离空间,拥有独立网络设施或电力设备,由相邻的单个或多个 PDC 组成。
- Region:地理区域,有多可用区所组成的集合,区域之间故障域完全隔离。
1、主备模式
![055ec6106d1d8cb2ebd7ca304dc8f9d2.png](https://i-blog.csdnimg.cn/blog_migrate/774af006f200df0cce1c26ccdf082c8a.jpeg)
主机房提供服务,备用机房不提供服务,当主机房故障,服务可切换到备用机房接管。
2、同城双活
![4147cb8d609f3414da0d0ea950102acf.png](https://i-blog.csdnimg.cn/blog_migrate/9d2aab218ea51da8964adfee83cd8aa3.jpeg)
同一个集群横跨同城两个不同的 AZ,两个 AZ 同时对外提供服务,同时允许跨机房访问不同服务以及数据库。
3、多活模式
![3105e8118b0453fc0fb64dbff302eaa0.png](https://i-blog.csdnimg.cn/blog_migrate/dde10d1bd5cdff4b1ef59e032ad7ea53.jpeg)
多个机房同时提供服务,业务请求尽量收敛在同一个机房,当某个机房故障时,可以切换其它接管机房。
4、方案比较
![eeea46cb57c6beec41636b76779bf196.png](https://i-blog.csdnimg.cn/blog_migrate/4b3335e5ee39c88593f1adf4c8471b89.jpeg)
鉴于苏宁线上 / 线下交易业务和支付业务特性,以及异地数据中心的要求,通过技术评估和决策,最终选择多活模式。
由于选择了难度最大的一种方案模式,多活方案将涵盖苏宁所有核心业务以及基础组件,需要考虑和关注的问题非常多,一旦设计发生偏差,调整的代价将非常大。为了确保方案的合理性,可实施性,首先我们讨论并制定了顶层设计,包括目标、价值和设计原则,并在设计过程中不断的复盘,以保证设计不偏离主航道。
2 顶层设计
顶层设计是多活相关的干系中心经过充分讨论,并最终达成一致的最高方针。总体方案以及各个业务系统方案都必须有严格遵守的规范和要求,包括目标、价值和原则。
1、目标
- 机房水平扩展:单机房容量有限,业务高增长带来大量的资源需求,多活需要具备机房水平扩展能力,为资源扩容提供保障。
- 机房之间同城和异地高可用:单机房存在单点故障风险,多活需要具备机房级别的高可用能力,在一个机房出现故障时,能够将流量快速切到其他正常的机房,对业务的影响降低到最小。
2、价值
- 支持业务的快速发展:苏宁每年的业务规模成倍数级增长,所依赖的 IT 资源也快速增长,通过机房的水平扩展,解决单机房容量不足问题,以支持业务的发展。
- 同城与异地容灾:当机房出现电源或网络以及地震等机房级别故障,通过机房级别的流量切换实现同城与异地容灾,将对业务的影响降低到可控水平。
- 混合云降低持有成本:由于电商业务的特殊性,大促流量与平时流量相差上百倍,大促期间将流量划拨到公有云,在多活能力的基础上,实现私有云与公有云混部,降低私有云长期持有成本。
- 灰度发布:实现按机房级别流量逐步灰度发布,降低业务版本故障影响面,提升版本发布质量。
3、原则
- 同一用户的交易尽量在一个数据中心内部完成。苏宁对于交易业务按照用户纬度对数据分片,特定的用户路由到特定的数据中心,保证一个用户的交易在一个数据中心完成。
- 业务无需感知多数据中心。核心业务在多个数据中心部署,提供服务,业务无需感知自己在哪个机房,即便数据中心发生切换,业务也无需感知。
- 尽量节省资源。由于多机房部署导致成本上升,需要通过调整高可用部署方案降低多机房部署成本。
基于顶层设计的要求,开始多活总体方案的架构设计。
3 架构设计
1、相关概念
- 分片服务:对应的数据仅在某个 Cell 存在,其它 Cell 不与交叉或共享,比如会员服务、订单服务等。
- 共享服务:所有 Cell 拥有相同的数据,相互共享,比如价格服务、商品服务等。
- 索引服务:用于索引数据提供服务,类似共享服务。
- 竞争 (控制) 服务:各个 Cell 相互操作同一个数据,为了保证数据一致性,需要在同一个数据中心进行控制,比如库存的扣减、用户注册等。
- 竞争 Proxy 服务:用于竞争服务前置服务,比如库存前置调拨服务。
2、服务架构
![4fb787dab8ba6237a05d4fd4243e5428.png](https://i-blog.csdnimg.cn/blog_migrate/5e4f98d898446d69e620d37a1dae302b.jpeg)
按照用户分布到不同的数据中心,多个数据中心都提供服务,在一个数据中心出现问题时,可以随时将流量切到另外一个正常的数据中心。
- 服务规划:根据业务不同功能,将服务拆分为分片服务,共享服务,竞争服务,索引服务,控制服务以及管理服务。各服务类型单独设置路由规则,同时支持灰度路由。
- 统一服务路由:从接入层到服务层以及最终的数据层,都遵守统一的路由策略,保证同一用户的交易在一个数据中心完成。
- 数据高可用:多数据中心保证数据库高可用,采用全冗余方式,数据在任何一个数据中心都是可用的,从而保证高可用,任一数据中心故障,不影响数据的可用性。
3、服务路由
![b05191126ab389a614e0f9bf20cc14bf.png](https://i-blog.csdnimg.cn/blog_migrate/44f1296b19ddd2b926c58bfa4a18fb3a.jpeg)
流量的分布是由服务路由来决定的,而路由的功能由各组件承载并实现,主要分成以下几部分:
- DNS:根据用户所在位置就近路由到对应的 CDN。
- CDN:根据用户请求信息按照一定的规则路由到对应的数据中心。
- SLB:根据用户请求信息路由到同机房或其它机房。
- RPC/MQ:根据用户请求信息按照一定的路由规则分发到不同的数据中心。
- DAL:数据接入层对用户所处的分片进行校验,确保不出现数据异常或数据冲突。
4、服务收敛
![75841dd09b73850ab58dfdf90f15e46e.png](https://i-blog.csdnimg.cn/blog_migrate/12de44feaef02123833a23efe3326f9d.jpeg)
基于服务路由的功能,为了实现同一用户的交易在同一数据中心进行,减少跨数据中心网络延迟,需要对用户流量进行精准分发。流量在进入数据中心前,按照一定的路由规则,确定好待分发的目标中心,以减少数据中心之间的二次转发。比如,苏宁在 CDN 层进行用户的初次路由,将用户分发到不同的数据中心。
数据中心内部,对服务层设置多种路由策略,比如设置接入层、RPC、DAL 等的路由方式以及业务服务拆分,使得同一个用户所有请求尽量收敛在同一个数据中心,实现流量精准划拨,避免跨机房调用。
请求的收敛设计确保流量按照 Cell 级别划拨到不同的数据中心,并在同一中心封闭收敛,这也是实现多数据中心部署的基础。
5、数据高可用
![77996edf0088fdf674abfbfc7956f7dc.png](https://i-blog.csdnimg.cn/blog_migrate/2f4eb95ce00761c19b4b1a8f594c3936.jpeg)
为了确保数据高可用以及任何一个机房故障都可被接管,所有数据中心都包含全量数据,当主数据中心的变更将会实时同步到各个从数据中心。
数据中心之间延迟相对数据中心内部延迟较大,数据中心之间的同步一般采用异步复制方式。在机房故障等极端情况,将出现少量数据未同步到其它数据中心,针对此类故障场景,在机房恢复后,需要对未同步的数据进行人工修复。
4 技术难点
按照多活的架构设计,并结合苏宁的业务特点和 IT 技术现状,需要优先解决相关的技术难点。
1、高可用实现
高可用实现原则
![950e0ae6bb82abe30c7e87ef17129584.png](https://i-blog.csdnimg.cn/blog_migrate/6e6f7e7ba37443351a78d3b6d0fad432.jpeg)
数据中心高可用分成两部分:
单数据中心内高可用
- 集群内部高可用无状态服务 (比如应用服务器):采用 N+1 方式部署,任何一台故障,流量都可被其它机器所接管。有状态服务 (比如数据库):采用 2N(一主一从)或 3N(一主两从)方式部署,任何一台故障,在秒级切换到另外一台机器。
多数据中心间高可用
- 单系统同城高可用:任何一个系统有计划维修或非计划性故障,都可切换到另外一个数据中心
- 全链路同城高可用:当机房级别故障或维修时,可切换到另外一个机房接管。
- 全链路异地高可用:当出现地震等特殊场景,异地机房可进行接管,避免同城两个数据中心同时故障等异常场景。
其中机房级别故障切换时间一般在分钟级别。
高可用实现指标
![0bf911ffe74dcfcda1f3452c73b34836.png](https://i-blog.csdnimg.cn/blog_migrate/1fdfce03d3aa57a80cbc05457d8ffc6e.jpeg)
- RPO(Recovery Point Object):表示机房级别故障时,未被同步的数据时长。考虑到 MySQL 在特殊情况下复制延迟较大情况下,RPO 设置为分钟级别,正常情况下 RPO 为秒级
- RTO(Recovery Target Object):表示机房故障情况下,关键流程或系统切换恢复时间,一般为分钟级别
- WRT(Work Recovery Time):表示故障时,由于 RPO 导致的未同步异常数据修复完成时长,一般为小时级别。
高可用实践
服务切换
![afda6f51ab90e6c6753e919ac163fbcd.png](https://i-blog.csdnimg.cn/blog_migrate/1f32a09d675614031119643ef58729bd.jpeg)
(1)数据复制拓扑结构
对于分片数据跨机房复制方式主要分成两种:
- 单向交叉复制:两个机房同一个分库的两个不同集群之间采用主备模式进行复制,仅主集群提供写操作,如上图所示 Cell4 的 LDC-B 做为主集群复制到 LDC-A 备集群, Cell8 的 LDC-A 主集群复制到 LDC-B 的备集群
- 双向复制:两个机房同一个分库的两个不同集群之间采用主 - 主模式进行复制,两个机房的集群同时提供写操作服务
![3f07d5dc8d659aade8131805b26cb831.png](https://i-blog.csdnimg.cn/blog_migrate/e052742f0dfb56df5bb1f7afcaf15d59.jpeg)
复制拓扑结构比较
为了确保数据的一致性和避免出错概率以及数据存储分布不规整,苏宁初期采用单向交叉复制拓扑结构。
(2)数据迁移与规整
![bc3a6b37f520c0bad30766d385c7f2a2.png](https://i-blog.csdnimg.cn/blog_migrate/520b1c3ca00539d97b2044ee0dbc1bb9.jpeg)
为了实现按用户分 Cell 分布到不同数据中心,并且苏宁业务形态的多样性以及一些历史遗留问题,比如单表记录过多(超过 1 亿),不利于多数据中心的扩展,为此需要对数据按照一定的规则重新迁移和规整。
- 对原有数据做快照,然后对快照数据重新规整到新的分库分表。
- 对原有集群增量数据准实时抽取 Binlog 数据规整到新的集群。
- 通过 DAL 灰度划拨流量写入到新的集群,直至所有数据切换到新集群。
(3)服务切换
对于分片数据服务,分片服务按照一定规则对 Cell 分组进行切换,确保应用层的服务和数据可以同时切换,避免数据写入异常。
跨数据链路切换
![d6d6e94b8c58d52c71b7017fdbf45d85.png](https://i-blog.csdnimg.cn/blog_migrate/2d43c095542c49036b945beaa796289b.jpeg)
为了实现部分流量全链路划拨到不同的数据中心,以及在数据中心故障时能够快速接管业务,所有多数据中心流程分发和服务调度全部由基础中间件平台完成,无需业务感知数据中心故障或流量划拨,这样整体切换时间会大大缩短,快速恢复业务。从而实现数据中心之间同城高可用以及异地高可用。
具体步骤如下:
- 接管机房对应的从库提升为主库。
- 服务写操作切换到新的接管机房。
- 服务(SLB/RPC/MQ)切换到新的接管机房。
- CDN 流量重定向到新的接管机房。
2、灰度部署与上线
为了确保多机房部署时,拓扑结构和配置的变化,不影响到整个业务系统运行,采用灰度部署方案,分以下几个阶段:
- 基础组件部署:比如 RPC、MQ、WAF、数据库等的部署
- 业务系统部署:比如订单系统、会员系统、促销系统、商品系统等的部署
![332b730c1d3aef558ff0ca94b98ff62b.png](https://i-blog.csdnimg.cn/blog_migrate/ade46868da85227aab3611441b71aa02.jpeg)
组件和系统部署完成了,为了确保业务稳定上线,生产的流量逐步划拨,前一个步骤的完成为下一个步骤的准入条件。
具体如下:
- 用白名单(内部用户)进行测试,验证部署和配置的正确性。
- 进行单系统流量划拨,确保每个系统切换的正确性。
- 全链路流量划拨,确保端到端切换的正确性。
3、全链路监控
![f50cb899dddc2a51c3d835e4e79a001a.png](https://i-blog.csdnimg.cn/blog_migrate/e2200ae238ceaf13154825211af69368.jpeg)
苏宁的业务种类繁多,为确保核心交易业务的可靠性和扩展性,现阶段优先对这些业务进行多活改造和多数据中心部署。
一次交易请求,落在哪个数据中心处理,请求失败是由哪个业务节点导致等等,这就需要一套完善的监控平台,对全链路,多数据中心的各个环节进行全方位,高精度的监控。
监控平台主要分成以下几个部分:
- 日志:分别在每个机房部署日志组件,避免跨机房传输日志带宽消耗,查询通过联邦模式汇总查询。
- 指标 (metrics): 每个机房汇总到指标数据到主机房,以便指标在主机房汇总查询。
- 调用链:分别在每个机房部署调用链,调用链也是通过联邦模式查询。
4、故障演练
![5db448dc0a6f8c7576c36128f1120200.png](https://i-blog.csdnimg.cn/blog_migrate/e846a11693bd12c1ac4a7217ac640535.jpeg)
为了模拟机房故障,通过混沌工程逐步提高爆炸半径,模拟业务故障,减少对业务的影响,主要故障模拟如下:
- 单系统故障模拟:比如订单系统或会员系统单个系统故障
- 全链路故障模拟:比如交易链路或支付链路多个系统同时故障
- 网络故障模拟:比如交换机或路由器等故障
- 整个机房级别故障模拟:比如电源(市电、UPS 等)故障导致整个机房故障
通过混沌工程模拟可以相对真实验证整个多活系统的容灾能力,整个模拟对业务的影响都相对可控,大大降低对业务的影响。
5 多活拓展
在多活方案设计过程中,需要综合考虑苏宁 IT 基础设施规划,其中异地部署和混合云部署是多活能力的拓展和延伸。
1、异地部署
由于同城机房资源受限,并且同城部署无法解决地震等极端故障,因此需要引入异地部署。异地多数据中心相比同城多数据中心,最大的问题就是网络延迟明显增大,数据中心的宽带相对受限,需要在架构和整体的解决方案上进行考虑,通过技术手段实现异地多数据中心的高可用性,降低延迟。同时需要通过组件对传输数据进行压缩和传输限流,确保传输的数据在有限的宽带可控范围内。
苏宁多活架构从一开始就是按照异地部署架构来设计,大大降低同城和异地部署异构性和运维复杂性。
2、混合云部署
苏宁业务系统大促流量是平时业务流量的十倍甚至上百倍,日常资源都是按照大促的峰值进行准备,资源持有和运维成本较高,资源采购,上线周期较长。因此大促期间,通过将部分流量弹到公有云,利用公有云的弹性能力,为私有云进行削峰,大大降低苏宁私有云长期持有成本,以及运维成本。
混合云相比原有多活需要做如下的能力拓展:
- 安全管控:公有云与私有云属于不同的信任域,对于公有云与私有云相互访问进行管控,确保混合云网络之间安全;以及公有云数据存储安全管控。
- 快速部署:由于公有云是根据按量或按月 / 按年计费,快速部署能力可以降低公有云资源成本使用时长。
- 非对称部署:由于公有云与私有云处理能力不一样,可以通过非对称部署降低公有云和私有云成本。
6 总结
多数据中心多活项目作为苏宁重大项目,经过 3 年左右的建设,已于 2019 年上线,历经 818 和双 11 等大促考验,实现关键链路从单机房平滑过渡到多机房的突破,支撑了业务的快速发展;并在机房出现真实故障时,快速实现业务恢复,将故障影响降低到可控范围内。
混合云项目经历一年左右的建设,也已初具规模,将为苏宁后续的业务高速发展保驾护航,降低公司大促扩容成本。
作者介绍
陈跃泉,苏宁科技集团 CTO 办公室技术架构部负责人,架构总监,苏宁多活多数据中心项目首席架构师和混合云项目总体技术负责人,拥有 15+ 年零售、电信、金融等超大型或大型项目架构设计经验,对大规模分布式系统 PaaS 和 IaaS 架构设计有深入的理解和思考。
涂成义,苏宁科技集团 CTO 办公室技术架构部高级架构师,曾在华为,中兴等多家 IT 公司任职架构设计,技术负责人。目前专注于云计算相关技术研究,对高并发,高可用架构有较深入的理解和思考,多活多数据中心项目核心成员。
马忠成,苏宁科技集团 CTO 办公室技术架构部高级架构师,多活多数据中心项目核心成员,在加入苏宁之前从事多年的运营商 IPTV、CDN 研发设计和规划工作。
关注我并转发此篇文章,私信我“领取资料”,即可免费获得InfoQ价值4999元迷你书,点击文末「了解更多」,即可移步InfoQ官网,获取最新资讯~