本篇文章主要介绍了支付宝高可用和容灾能力建设的解决思路，高可用性指的是一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。容灾能力一般特指面对自然灾害时的处理与恢复能力。在架构设计中，作为系统高可用性技术的重要组成部分，容灾设计强调的是系统对外界环境影响具备快速响应能力，尤其是当发生灾难性事件并对IDC节点产生影响时，能够具备节点级别的快速恢复能力，保障系统的持续可用。2015年12月18日，年度高端技术盛会：“全球架构师峰会——ArchSummit”在北京国际会议中心隆重召开，会上，阿里巴巴高级系统工程师：善衡（曾欢）结合互联网金融业务及系统特性，分享了在支付宝系统架构演进中，每个阶段的高可用和容灾能力建设的解决思路。本文由其演讲内容整理而成。
支付宝的系统架构，其发展历程可以分为清晰的3个阶段，每一个阶段都有自己独特的特点和架构上相应的痛点。
1.纯真：童年时期2004年~2011年
在此阶段，支付宝的系统架构相对比较简化，如图1所示，通过商用LB（商用负载均衡）让用户的流量进到入口网关系统，支付宝的系统服务暴露也通过商用设备挂在VIP下，每个提供服务的应用机器通过VIP来进行负载均衡。早期支付宝的核心系统库都在一个数据库上（后期拆为多个数据库），即每个核心系统都只用单独的数据库。在这样一个“物理上多机房，逻辑上单机房”的架构背后，每天的业务量仅仅为数十万级，应用系统也只有数十个，容灾能力相对较低：例如单应用出现问题时无法及时有效地切换、主机和备用机进行切换时，一定程度上会导致业务中断，甚至有时会有不得不进行停机维护的情况，使得整个系统面对数据故障时显得十分被动。
随着业务量的不断增长，该架构发展到2011年，出现了一些比较典型的问题。一是由于系统内部使用的都是LB设备，商用LB的瓶颈就尤其明显，由于业务的发展累计，VIP及其上面发布的服务越堆越多，设备如果出现抖动或者宕机会对业务造成严重影响。二是数据库的单点瓶颈。随着业务量的不断增加，单一的核心数据库一旦出现异常，比如硬件故障、负载异常等等，进而会导致整个核心链路上的业务都不可用。如何消除系统架构当中存在的单点问题，解决未来1-3年之间业务量增长和机器数量增长是首先要解决的问题，于是带来了下一代架构革新。
2.懵懂：少年时期2011年~2012年
在此阶段，支付宝将逻辑上的单个机房拆分成为多个机房，通过把硬负载转换成为软负载，以实现分布式的服务调用，如下图所示。下图为基于常见的消费者和生产者模型来构建的业务模型，其中配置中心负责服务注册以及对应服务提供方可用状态变化的通知，从而将信息实时推送到消费方的订阅关系上。值得注意的是，支付宝对原有架构做了一个较大的改进：它将普通的一体化配置中心分拆成两个模块，一个Session模块，用于管理消费者和生产者的长连接保持；一个Data模块，用于注册服务时存储相关。通过这两个模块的深度解耦，进一步提高整个配置中心的性能。
除此之外，支付宝还做了数据的水平扩展。其实早在2011年之前，支付宝就已经开始从事此项工作，根据用户的UID，将一个交易库水平拆分为多个库，如下图所示。在此期间，需要解决的问题就是“对应用透明”，如何通过“应用无感知”的方式进行用户数据库的拆分，是水平扩展实施时首先要考虑的；其次，如何通过一个数据中间件来管理数据分片的规则，也是数据水平扩展过程中的关键问题。
虽然在此过程中自然解决了第一阶段的单点问题，但仍存在一个问题没有解决，即数据库日常维护时，或因为硬件的故障导致数据库宕机时，支付宝需要进行主备切换，在此过程中业务是有损的状态。一般情况下当IDC出现问题的时候，工程师们会通过前端的流量管控系统先把用户的流量从出现异常的机房切换到正常的机房中，然后进行数据库的主备切换，即将备用负载替换主用负载。在这个过程中。有两个痛点：一是主备切换时数据“一致性”的问题，即主备切换时，如何在把影响时间降至最低的情况下，保证数据不被丢失，完完整整地拷贝至备用数据库。二是主备切换时数据存取不可用导致的业务暂停问题。
一旦数据库发生故障，我们需要进行主备切换时，因为切换过程中的数据不可写，部分用户操作后的状态不对，对用户来说是会担心的。为了解决这个问题，支付宝制定了一个Failover方案。该方案主要通过业务层进行改造，例如针对流水型的业务数据。一旦故障发生，主库发生宕机，支付宝人员将通过容灾切换将所有数据的读写放置在FailOver数据层中进行。因为是实时流水型的数据，所以不会对历史数据产生任何依赖和影响。切换完成后，整个核心链路上的业务就已经全面恢复起来了。通过这种方式，使得支付宝可以将数据库在短短5分钟内进行切换，一旦故障解除，随时可以将数据读写重新切换到主存储库上来。
3.成熟：青年时期2012年~2015年
通过“多机房多活”的架构改造以及FailOver方案的实施，支付宝研发团队满以为未来三年都无需为IDC资源去发愁。但是在顺利支撑完2012年的“双11”，为下一年做规划时却发现梦想破灭了。因为他们又遇到了新的问题：
一是DB连接数不够。由于一个机房中的应用系统就是一个节点，没有分片的概念，仅仅只有数据的分片。用户进入任意应用节点时，系统需要根据用户的UID分片查用户应该去往哪个数据库，这时候每个应用节点都会与所有数据库节点保持连接。而传统关系型数据库的连接数是十分宝贵的，当支付宝面对不断增长的用户扩容需求时，因为DB连接数资源无法继续扩充，导致应用也不能继续扩容了，不仅无法满足日常增长需求，更别提“双11”这样短时间爆发式增长的用户需求。
二是城市IDC资源限制问题。2012年夏天，杭州经历了长时间高温天气，由于机房运行的耗电较高，市政为了缓解电力供应压力，下达了一纸通文，随时可能关闭掉支付宝的某些机房供电。
三是机房间高流量问题。由于一个业务请求与后端数据读取之间的比例为1:N（其中N可能是几十甚至上百），在“双11”高流量的冲击下，跨机房的流量会变得非常的大，因此对于网络带宽和网络质量也有着非常高的要求。
四是跨IDC网络延时问题。由于业务请求和后端数据读取1:N配比问题，导致同城机房之间距离稍微远一些，就会产生1、2毫秒的同城机房延时，被扩大后就会成为困扰用户的网络延时问题。
基于上述几个问题的思考，支付宝走到了单元化的一步。在传统的服务化架构下每一次调用服务时，系统都会随机选择一台机器或一个节点完成整次的调用。而单元化之后支付宝可以把任何一个节点固定到一个单独的单元内，即固定的节点对应一条固定的链路，再基于数据分片的方法完成将节点“单元化”的设置。
支付宝单元化架构实现的主要思想有两点：
一是数据水平拆分，即将所有线上核心业务分离开来。由于核心业务集合都能按照用户ID去做水平切片，支付宝团队将数据切片后按照机房进行分布，然后通过循序渐进的方式逐步将每个单元之间的调用完整地封闭掉。每一个单元的数据都是经过分片的数据，不需和其它单元进行同步。
二是上层单元化改造，即将历史的、不能拆分的业务独立出来。2013年，支付宝实现了两个单元：单元A放置核心业务，例如核心链路的支付、交易等；单元B放置无法拆分的历史业务，例如某些不重要的业务等。
本文来源于微信公众号InfoQ。