支付宝架构师眼里的高可用与容灾架构演进支付宝架构师眼里的高可用与容灾架构演进
高可用和容灾架构的意义
企业服务、云计算、移动互联网领域中,高可用的分布式技术为支撑平台正常运作提供着关键性的技术支撑。从用户角度,特
别是作为主要收入来源的企业用户的角度出发,保证业务处理的正确性和服务不中断(高可用性)是支撑用户信心的重要来
源。高性能,高可用的分布式架构就成了访问量高峰期时,网站得以成功运维的关键。
在当今信息时代,数据和信息逐渐成为各行各业的业务基础和命脉。当企业因为信息化带来快捷的服务决策和方便管理时,也
必须面对着数据丢失的危险。
容灾系统,作为为计算机信息系统提供的一个能应付各种灾难的环境,尤其是计算机犯罪、计算机病毒、掉电、网络/通信失
败、硬件/软件错误和人为操作错误等人为灾难时,容灾系统将保证用户数据的安全性(数据容灾),甚至,一个更加完善的
容灾系统,还能提供不间断的应用服务(应用容灾)。可以说,容灾系统是数据存储备份的最高层次。
每年的“双11”、“双12”都是全球购物者的狂欢节,今年的双11有232个国家参与进来,成为名副其实的全球疯狂购物节。11月
11日,全天的交易额达到912.17亿元,其中在移动端交易额占比68%今年每秒的交易峰值达到14万笔,蚂蚁金服旗下的支付
宝交易峰值达到8.59万笔/秒,这一系列的数字,考验的是支付宝背后强大的IT支持能力。而持续可用和快速容灾切换的能
力,是支付宝技术人员追求的极致目标。
在架构设计中,作为系统高可用性技术的重要组成部分,容灾设计强调的是系统对外界环境影响具备快速响应能力,尤其是当
发生灾难性事件并对IDC节点产生影响时,能够具备节点级别的快速恢复能力,保障系统的持续可用。2015年12月18日,年
度高端技术盛会:“全球架构师峰会——ArchSummit”在北京国际会议中心隆重召开,会上,阿里巴巴高级系统工程师:善衡
(曾欢)结合互联网金融业务及系统特性,分享了在支付宝系统架构演进中,每个阶段的高可用和容灾能力建设的解决思路。
本文由其演讲内容整理而成。
支付宝的系统架构,其发展历程可以分为清晰的3个阶段,每一个阶段都有自己独特的特点和架构上相应的痛点。在每一个阶
段的发展过程中,支付宝的技术人员针对不同的问题进行诸多的思考,在解决这些问题的过程中也做了诸多的尝试。
纯真:童年时期2004年~2011年
在此阶段,支付宝的系统架构相对比较简化,如图1所示,通过商用LB让用户的流量进到入口网关系统,支付宝的系统服务暴
露也通过商用设备挂在VIP下,每个提供服务的应用机器通过VIP来进行负载均衡。早期支付宝的核心系统库都在一个数据库
上(后期拆为多个数据库),即每个核心系统都只用单独的数据库。在这样一个“物理上多机房,逻辑上单机房”的架构背后,
每天的业务量仅仅为数十万级,应用系统也只有数十个,容灾能力相对较低:例如单应用出现问题时无法及时有效地切换、主
机和备用机进行切换时,一定程度上会导致业务中断,甚至有时会有不得不进行停机维护的情况,使得整个系统面对数据故障
时显得十分被动。
随着业务量的不断增长,该架构发展到2011年,出现了一些比较典型的问题。如下图所示:由于系统内部使用的都是LB设
备,商用LB的瓶颈就尤其明显,由于业务的发展累计,VIP及其上面发布的服务越堆越多,设备如果出现抖动或者宕机会对业
务造成严重影响,这即是架构上的单点。第二个问题就是数据库的单点瓶颈。随着业务量的不断增加,单一的核心数据库一旦
出现异常,比如硬件故障、负载异常等等,进而会导致整个核心链路上的业务都不可用。