【容灾架构】淘宝网/支付宝 异地多活 架构原理学习笔记

【学习背景】

最近在看一本书《蚂蚁金服-科技金融独角兽的崛起》，正看到第七章“技术攻坚”简单介绍了一下支付宝的架构从第一代的烟囱架构、第二代的分布式架构，第三代的云计算架构，其中有个词“异地多活”出现了一次，但没有详细描述。

之前接触的容灾方案，顶多就是两地三中心的双活架构+异地备份，特地从一些公开的资料中尝试学习一下阿里巴巴“异地多活”的架构是什么样的？

 

【为什么两地三中心架构满足不了阿里巴巴的要求】

1、异地节点是冷数据，和最新数据有时差。如果2各生产中心出问题后，没有人有多强的信心能够保障异地起用后是可以正常服务的。因为异地备份中心是冷的，平时没有用户流量进去，意味着拉业务需要时间，也不一定能拉起来。模式看起来很安全，也可用。事实上不一定是这样。

2、异地备份中心因为不对外提供服务，所以整个资源会处于浪费状态，成本比较高。

3、阿里的用户规模非常大，虽然是两地三中心，数据也是在同一个城市写，比如“双十一”的场景中压力非常高的情况下，所有数据都是单点写，由于双十一的用户访问量每年都增幅很大，数据库和业务层面的伸缩面临非常大挑战。

 

【异地多活的技术需求】

1、需要多个跨地域的数据中心，异地多活是跨地域的，而且距离一定要做到1000公里以上的范围，其实在中国范围内全国城市都可以去部署了。

2、每个数据中心都要承担用户的读写流量。如果只是备或只读业务来讲，作用不是很大。

3、多点写。因为每个数据中心去承担用户读写流量的话，如果读或写集中到全国一个点的话，整个延迟是没有办法承受的。

4、任意一个数据中心出问题的时候，其他中心都可以分钟级去接管用户的流量。

 

【阿里巴巴技术架构演进过程】

【异地多活的技术难题】

1、时延大，用户打开网页慢。

2、一个流程涉及多地系统时，异地写的数据一致性，同步机制。

3、流量切换过程，未完成的流程如何保证数据一致性。

4、二代架构之间的平滑升级。阿里保密。

 

【时延问题的解决方案】

1、每个页面的显示内容都在同一个机房内完成，本人妄自推测用到技术包括：DNS来分流区域客户、CDN缓存加速静态页面、专线保障网络稳定、业务单元化部署。

 

【数据一致性问题的解决方案】

1、评估业务需求，异地数据同步时间控制在1秒内，可用容忍。阿里自建了全国的专线网络。

2、自研了数据同步中间件DTS（早期叫阿里巴巴内部叫DRC，现在阿里云网站上叫DTS）。

3、业务单元解耦（阿里内部把解耦叫“单元化”），单元内的应用访问和数据读写全部在一个机房内完成。高流量的业务多地部署，低流量业务集中部署，需要成本和性能的平衡点。

4、写入数据库前有保护动作。阿里保密，本人妄自推测：异地双写或多写失败有回滚操作，并且要求双写或多写成功后才返回前端ok。

5、流量切换过程中能保证数据一致性。阿里保密。 本人妄自推测：流量切换分为前台切换和后台切换两边，新流量走到新的线路，处理中的流量在原来的机房继续处理完成。类似热升级的原理。

 

【核心技术产品DRC/DTS】

DRC/DTS作为阿里巴巴的数据同步工具，支持数据库、NoSQL及大数据之间的数据实时传输。提供数据迁移、数据库Binlog实时订阅及数据实时同步等多种功能。DTS承载着阿里巴巴异地多活数万调实时传输链路，已在线稳定运行7年。 --来自阿里云DTS的网站介绍

 

【容灾能力的体现】

不同公司对可用性做了多少，理解不一样，比如4个9，5个9。阿里巴巴的林昊（花名毕玄）分享如下：

任何网站，出故障是不可避免的，淘宝因为能够做到异地多活，并且流量是可用随时切换的，所以对淘宝来说，如果一地出现故障，不管什么原因，最容易的解决方案，就是把这一地的流量全部切走。这样可用把故障控制在一分钟以内，整个可用性非常高。对于容灾能力的重要标准是故障的恢复时间。

 

【异地多活的能力开放】

阿里巴巴希望异地多活推动行业的进步，金融业也不再希望自己是一个两地三中心而已，通过蚂蚁金服的金融云把能力开放给金融行业。

 

【主要参考文献】

绝对干货:解密阿里巴巴“异地多活”技术

 https://servers.pconline.com.cn/721/7215376.html

专访阿里巴巴毕玄：异地多活数据中心项目的来龙去脉 

https://infoq.cn/article/interview-alibaba-bixuan

傅翠云--异地多活数据流基础设施DRC 

https://wenku.baidu.com/view/fbb886469ec3d5bbfc0a7438.html