1. 梦飞科技 > 中国IDC > IDC新闻 > 国内资讯 >
  2. 支付宝架构师眼里的高可用与容灾架构演进(4)

支付宝架构师眼里的高可用与容灾架构演进(4)

高可用和容灾架构的意义

企业服务、云计算、移动互联网领域中,高可用的分布式技术为支撑平台正常运作提供着关键性的技术支撑。从用户角度,特别是作为主要收入来源的企业用户的角度出发,保证业务处理的正确性和服务不中断(高可用性)是支撑用户信心的重要来源。高性能,高可用的分布式架构就成了访问量高峰期时,网站得以成功运维的关键。

在当今信息时代,数据和信息逐渐成为各行各业的业务基础和命脉。当企业因为信息化带来快捷的服务决策和方便管理时,也必须面对着数据丢失的危险。

容灾系统,作为为计算机信息系统提供的一个能应付各种灾难的环境,尤其是计算机犯罪、计算机病毒、掉电、网络/通信失败、硬件/软件错误和人为操作错误等人为灾难时,容灾系统将保证用户数据的安全性(数据容灾),甚至,一个更加完善的容灾系统,还能提供不间断的应用服务(应用容灾)。可以说,容灾系统是数据存储备份的最高层次。

支付宝架构师眼里的高可用与容灾架构演进

每年的“双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及其上面发布的服务越堆越多,设备如果出现抖动或者宕机会对业务造成严重影响,这即是架构上的单点。第二个问题就是数据库的单点瓶颈。随着业务量的不断增加,单一的核心数据库一旦出现异常,比如硬件故障、负载异常等等,进而会导致整个核心链路上的业务都不可用。

支付宝架构师眼里的高可用与容灾架构演进

如何消除系统架构当中存在的单点问题,优雅解决未来1-3年之间业务量增长(数百万级/天)和机器数量增长(数百个系统),是首先要解决的问题,于是带来了下一代架构革新。

懵懂:少年时期2011年~2012年

鉴于第一阶段支付宝碰到的这些痛点,在第二个阶段,它将逻辑上的单个机房拆分成为多个机房,通过把硬负载转换成为软负载,以实现分布式的服务调用,如下图所示。下图为基于常见的消费者和生产者模型来构建的业务模型,其中配置中心负责服务注册以及对应服务提供方可用状态变化的通知,从而将信息实时推送到消费方的订阅关系上。值得注意的是,支付宝对原有架构做了一个较大的改进:它将普通的一体化配置中心分拆成两个模块,一个Session模块,用于管理消费者和生产者的长连接保持;一个Data模块,用于注册服务时存储相关。通过这两个模块的深度解耦,进一步提高整个配置中心的性能。

支付宝架构师眼里的高可用与容灾架构演进

(责任编辑:梦飞科技)

扫描二维码

关注梦飞科技最新资讯