支付宝建筑师眼中的高可用性和容灾架构的演变

本篇文章6224字，读完约16分钟

支付宝建筑师眼中的高可用性和容灾架构的演变 在企业服务、云计算和移动互联网领域，高度可用的分布式技术为支撑平台的正常运行提供了关键的技术支持。从用户的角度来看，尤其是企业用户，他们是主要的收入来源，确保业务处理的正确性和不间断的服务(高可用性)是支持用户信心的重要来源。高性能和高可用性的分布式体系结构成为网站在流量高峰期成功运行和维护的关键。 高可用性和灾难恢复体系结构的重要性

在企业服务领域，移动互联网、高度可用的分布式技术为支撑平台的正常运行提供了关键的技术支持。从用户的角度来看，尤其是企业用户，他们是主要的收入来源，确保业务处理的正确性和不间断的服务(高可用性)是支持用户信心的重要来源。高性能和高可用性的分布式体系结构成为网站在流量高峰期成功运行和维护的关键。

在当今的信息时代，数据和信息已经逐渐成为各行各业的商业基础和命脉。当企业因信息化带来快速的服务决策和便捷的管理时，也必然面临数据丢失的危险。

容灾系统作为计算机信息系统应对各种灾难的环境，特别是当计算机犯罪、计算机病毒、电源故障、网络/通信故障、硬件/软件错误和人为操作错误都是灾难时，容灾系统将保证用户数据的安全(数据容灾)，甚至更完善的容灾系统也能提供不间断的应用服务(应用容灾)。可以说，容灾系统是数据存储备份的最高层次。

每年，双11和双12都是全球购物者的嘉年华。今年，232个国家参加了狂欢节，成为名副其实的全球购物狂潮。11月11日，交易总额达到912.17亿元，其中68%为移动端。今年，交易的峰值达到每秒140，000笔交易，蚂蚁金服旗下支付宝交易的峰值达到每秒85，900笔交易。这一系列数据测试了支付宝背后强大的信息技术支持能力。持续可用性和快速容灾切换能力是支付宝技术人员追求的最终目标。

在体系结构设计中，容灾设计作为系统高可用性技术的重要组成部分，强调系统对外部环境影响具有快速响应能力，特别是当灾难事件发生并影响到IDC节点时，可以具有节点级的快速恢复能力，以保证系统的连续可用性。2015年12月18日，一年一度的高端技术盛会——全球建筑师峰会在北京国际会议中心隆重举行。会上，阿里巴巴高级系统工程师:善恒(曾欢)结合互联网金融业务和系统特点，分享了支付宝系统架构演进各个阶段的高可用性和容灾能力建设解决方案。这篇文章是根据他演讲的内容组织的。

支付宝系统架构的开发过程可以分为三个不同的阶段，每个阶段都有自己独特的特点和相应的架构难点。在每个阶段的发展过程中，支付宝的技术人员对不同的问题进行了很多思考，并做出了很多尝试来解决这些问题。

天真:童年2004 ~2011

在这个阶段，支付宝的系统架构相对简单。如图1所示，商业LB允许用户的流量进入网关系统。支付宝的系统服务暴露也通过商业设备挂在VIP下，每个服务提供应用机通过VIP进行负载均衡。在支付宝的早期，核心系统库都在一个数据库上(后来分成多个数据库)，也就是说，每个核心系统只使用一个单独的数据库。在这样一个物理上的多机房和逻辑上的单机房架构中，每天的业务量只有几十万级，只有几十个应用系统，容灾能力相对较低:例如，当一个应用不能及时有效地切换时，当一台主机和一台备用计算机切换时，会在一定程度上造成业务中断，有时甚至需要进行停机维护，使得整个系统在面临数据故障时显得非常被动。

随着业务量的不断增长，架构发展到2011年，出现了一些典型问题。如下图所示，由于LB设备在系统内部使用，商业LB的瓶颈尤其明显。随着业务的增长和积累，VIP和在上面发布的服务越来越多。如果设备抖动或停机会严重影响业务，这是体系结构上的一点。第二个问题是数据库的单点瓶颈。随着流量的不断增加，一旦单个核心数据库出现异常，如硬件故障、负载异常等。，它将导致整个核心链路上的流量不可用。

如何消除系统架构中的单点问题，并在未来1-3年内优雅地解决业务量的增长(百万订单/天)和机器数量的增长(数百个系统)是首先要解决的问题，从而带来下一代架构创新。

无知:青年2011 ~2012

鉴于支付宝在第一阶段遇到的这些棘手问题，在第二阶段，支付宝将从逻辑上将一个机房分割成多个机房，并通过将硬负载转化为软负载来实现分布式服务调用，如下图所示。下图显示了一个基于普通消费者和生产者模型的业务模型，其中配置中心负责服务注册和相应服务提供商可用状态变化的通知，从而将信息实时推送到消费者的订阅关系。值得注意的是，支付宝对原有架构做了很大的改进:它将通用的集成配置中心分成两个模块，一个会话模块，用于管理消费者和生产者之间的长期连接维护；数据模块用于在注册服务时存储相关性。通过两个模块的深度解耦，整个配置中心的性能得到进一步提高。

此外，支付宝还扩大了其数据级别。事实上，支付宝早在2011年就开始了这项工作。根据用户的UID，事务数据库被水平划分为多个数据库，如下图所示。在此期间，要解决的问题是对应用程序透明。在实现水平扩展时，首先要考虑的是如何以对应用程序不敏感的方式拆分用户数据库。其次，如何通过数据中间件管理数据分片规则也是数据横向扩展过程中的一个关键问题。

通过以上两个典型的优化，支付宝的整个系统架构如图5所示。从应用层面来看，每个机房都是一个节点。从数据层面来看，每个机房都有特定的数据片段。在部署模式下，当支付宝扩展到3或4个机房时，需要考虑全局部署数据片段，每个机房可能都不可用。这些备份库应分散到不同的多个机房，以达到多个机房备灾的目的。

这种具有多个计算机房和多个活动的第二代架构系统的优势如下:

数据是水平分割的，因此理论上数据/资源可以无限扩展。应用独立部署多个机房，不再有一个单独的机房影响全局；隔离在服务呼叫机房，通过软负荷将服务本地化在机房，不再依赖于另一个机房的相同服务；与前一阶段相比，它具有更高和更可靠的可用性。

尽管上述单点问题在这个过程中自然得到了解决，但仍有一个问题没有得到解决。也就是说，在数据库的日常维护过程中，或者当数据库由于硬件故障而关闭，并且业务在此过程中处于受损状态时，支付宝需要在主数据库和备份数据库之间进行切换。在正常情况下，当IDC出现问题时，工程师会通过前端流量控制系统将用户流量从异常机房切换到正常机房，然后在主备之间切换数据库，即备用负载代替主负载。

在这个过程中，有两大难点:

主备切换期间的数据一致性问题是如何确保数据不会丢失并完全复制到备用数据库，同时最大限度地减少主备切换期间的影响时间。主备倒换期间数据访问不可用导致的业务暂停。

一旦数据库出现故障，当我们需要在主备之间切换时，因为切换过程中的数据无法写入，有些用户会担心操作后状态不对。为了解决这个问题，我们制定了一个故障转移计划。该方案主要通过服务层进行改革。例如，我们对流水线服务数据这样做:在正常数据流访问期间，只有主库提供路由服务，并且在主库和备份库之间执行正常的数据同步，但是故障转移库不执行数据同步，并且在正常情况下对服务系统不可见。也就是说，在正常情况下，没有数据流通过故障转移库，并且故障转移库为空且没有任何历史数据，如下图所示:

一旦出现故障，主库关闭，支付宝人员将通过容灾切换将所有数据的读写放入故障转移数据层。因为它是实时流水线数据，所以不会对历史数据有任何依赖或影响。移交后，整个核心链路上的服务已经完全恢复。这样，支付宝可以在5分钟内切换数据库。一旦故障消除，数据可以在任何时候被读和写回到主存储库。

故障转移方案推出后，支付宝在此基础上对其所有核心业务进行了基本改革，不同业务将有不同的故障转移方案(不限于应用层)。现在，支付宝已经在原始方案的基础上准备了另一个故障转移数据库(如图8中的蓝色图所示)。与前面提到的容灾设计一样，如果需要进一步确保故障转移库的可用性，可以添加故障转移库的备份库。此外，故障转移库需要与主库分开，不能与主库和备份库放在同一个计算机房中。

成熟:2012-2015年青年

通过多计算机房和多生命结构转型以及故障转移计划的实施，支付宝R&D团队在2012年成功支持了double 11，但在计划下一年时发现梦想破灭了。该团队原以为未来三年不必担心IDC资源。因为他们遇到了严重的新问题:

数据库连接不足。由于计算机房中的应用系统是一个节点，因此没有碎片的概念，只有数据碎片。当用户进入任何应用程序节点时，系统需要根据用户的UID片段检查用户应该去哪个数据库。此时，每个应用程序节点将与所有数据库节点保持连接。然而，传统关系数据库中的连接数量非常有价值。当支付宝面临日益增长的用户扩展需求时，因为数据库连接资源不能继续扩展，应用程序不能继续扩展，不仅不能满足日常增长需求，更不用说用户需求的短期爆炸式增长，如11倍。鉴于上述技术，我特意整理出来，有很多技术是无法用几句话解释清楚的，所以我干脆找朋友录了一些视频。事实上，许多问题的答案都很简单，但它们背后的思维和逻辑并不简单。要知道它们是什么，我们需要知道为什么。如果你想学习Java工程，高性能和分布式，深入和简单。微服务之友，Spring，MyBatis，Netty源代码分析可以添加我的Java高级组:694549689，其中有视频阿里丹尼尔的现场解释技术和Java大规模互联网技术免费分享。国际数据中心城市资源有限。2012年夏天，杭州经历了长时间的高温天气。由于机房耗电量大，市政府下发通知，缓解供电压力，并可能随时关闭支付宝的部分机房。机房高流量问题。由于服务请求和后端数据读取之间的比率是1:N(其中N可以是几十甚至几百)，在双倍11的高流量的影响下，计算机房间的流量将变得非常大，因此需要非常高的网络带宽和网络质量。国际数据中心网络的延迟。由于服务请求和后端数据读取的1:N比例问题，同一城市的机房之间的距离稍长，导致同一城市的机房延迟1或2毫秒，扩展后将成为困扰用户的网络延迟问题。新问题进一步提出了对新一代体系结构的要求:彻底解决数据库连接数问题。彻底解决IDC资源有限的问题。我们需要支付宝走出杭州，我们不能只是在杭州扩建和建造计算机房。确保业务连续性。当故障发生时，减少用户和服务的中断。蓝色和绿色。在每日发布期间，它将通过离线发布测试、预发布，最后进入在线发布流程。在线出版通常采用加那利模式。应用程序分布在多个组中。每个组中的用户都不是固定的，这可能会影响该电台的大多数甚至所有用户。因此，支付宝团队希望在每天发布新代码时，将对用户的影响降至最低(可能1%，甚至1%)，并在新代码发布后，尽最大努力验证新代码是否符合预期。因此，需要一种新的发布方法来支持它。高可用性-更多地生活在不同的地方。对于支付宝来说，“两地三中心”的传统要求是，机房属于两个不同的区域，同一城市的两个机房是双职工的，即主动主机房，而远程机房是通过复制数据进行冷备份的，即备用机房。如果同一个城市的两个计算机房都有问题，一旦必须切换远程计算机房，就很难做出决定，因为我们不知道远程冷备用计算机房的操作是什么。支付宝希望远程机房能够实时读写流量，这样数据流量就可以来回切换，而不用担心切换后不知道数据会处于什么状态。单位化。基于上述考虑，支付宝已经到了统一化的阶段。如图9所示，在传统的服务架构下，每次调用一个服务，系统都会随机选择一台机器或一个节点来完成整个调用。单元化后，支付宝可以将任意节点固定为一个单元，即固定节点对应一个固定链路，然后根据数据分片对节点进行单元化。单元化的核心思想包括核心分离和长尾独立。核心剥离是指剥离核心业务。根据用户标识拆分业务数据，实现多房间部署；在此基础上，每个机房的呼叫都是以封闭的方式建立的。每个单元中的服务数据不需要与其他单元同步。长尾对于非核心应用程序是独立的。这些业务数据不是根据UID划分的，核心业务也不依赖于长尾应用程序。

实现支付宝的单元化架构有两个主要想法，如下图所示:

数据级拆分，即分离所有在线核心服务。由于核心业务集可以根据用户标识进行水平切分，支付宝团队将对数据进行切分，并根据机房进行分发，然后逐步关闭各单位之间的通话。每个单元的数据都是分段数据，不需要与其他单元同步。上层是单元化的，即历史和不可分割的业务是分开的。2013年，支付宝实现了两个单元:单元一放置核心服务，如核心环节的支付和交易；单元B放置不能拆分的历史服务，如一些不重要的服务。

支付宝的单元化结构于2013年完成，帮助支付宝在2013年成功支持double 11。从2014年到2015年，支付宝一直在努力解决异地延迟的问题:如果全局数据没有被分割或本地化，当业务单元转移到异地时，由于每次业务的发生基本上都依赖于全局数据，并且对应于多次数据访问，每次数据访问都会产生异地延迟，时间延迟会达到二级，用户体验会大大降低。基于对这一问题的考虑，支付宝研发团队做出了一个重大决策:他们引入了单元c，通过对无法拆分的全部数据进行全局复制(在不同机房之间复制)，方便支持核心业务的本地调用，从而实现读写分离，将跨城市调用减少到最低限度。如下图所示。

由于数据写入操作将在每个数据单元上进行，并且单元C的数据读取需要一个完整的量，因此这种转换需要底层的支持，从而解决了结构转换过程中的数据一致性和及时性问题。为了解决这个问题，支付宝团队提出了两个解决方案:

基于数据库同步的数据复制。对于一些对延迟不太敏感的服务，数据同步仅基于主从同步。基于消息系统的数据复制。由于远程数据的同步非常耗时，支付宝根据可靠的消息系统为对延迟非常敏感的服务制作数据副本(内部称为数据总线)。通过它，上层根据应用程序制作数据副本，这大约需要几毫秒。底层数据库的主数据库和备份数据库的同步是同时进行的。

通过本地化呼叫，支付宝有效地解决了数据库连接数、机房流量限制和国际数据中心延迟等问题。支付宝通过异地单元部署、持续容灾演练和数据交换，有效解决了城市IDC的资源限制和异地IDC的容灾问题。也有蓝绿发布的需求，支付宝就是这样实现的。

如下图所示，蓝绿色发布意味着每个单元被分为一个蓝色组和一个绿色组，这两个组在日常模式下各承担50%的用户流量。在发布之前，绿色组中50%的流量被移动到蓝色组，然后绿色被分两批无序发布。新代码发布后，将蓝色组中1%~2%的流量切换到绿色组进行验证，以尽量减少对用户的干扰。验证后，逐步将100%的流量切换到新的绿色组，重复前面的步骤释放蓝色组，并在验证后切换回每个组50%流量的每日模式。

此时，支付宝统一化的全球架构如下图所示。每个机房单元都有一个单元A和一个单元C。单元A在逻辑上分为两组，单元C执行全局数据复制。每个单元都部署了分布式容灾管理和控制系统，这使得支付宝能够在单个机房出现故障时更快地做出响应。

摘要

通过统一的系统配置，支付宝的整个系统架构具有很强的高可用性和容灾能力。具体来说，有三点:

更灵活的流量控制可以以更少的努力和更快的速度实现数据交换。定制的数据流分布。由于每个数据单元支持的资源和交易量可以预先确定，支付宝可以根据实际需求扩展单元维度。快速恢复的容灾能力。在单元化之后，不仅可以在数据单元中的蓝组和绿组之间切换流量，而且在单元之间、机房和机房之间、同一城市内甚至更高水平的城市之间，可以自由地进行故障情况下的紧急切换。