ArchSummit北京2015-《支付宝的高可用与容灾架构演进》-曾欢(善衡)

ArchSummit北京2015-《支付宝的高可用与容灾架构演进》-曾欢(善衡)

ID:8220215

大小:2.74 MB

页数:35页

时间:2018-03-10

ArchSummit北京2015-《支付宝的高可用与容灾架构演进》-曾欢(善衡)_第1页
ArchSummit北京2015-《支付宝的高可用与容灾架构演进》-曾欢(善衡)_第2页
ArchSummit北京2015-《支付宝的高可用与容灾架构演进》-曾欢(善衡)_第3页
ArchSummit北京2015-《支付宝的高可用与容灾架构演进》-曾欢(善衡)_第4页
ArchSummit北京2015-《支付宝的高可用与容灾架构演进》-曾欢(善衡)_第5页
资源描述:

《ArchSummit北京2015-《支付宝的高可用与容灾架构演进》-曾欢(善衡)》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、支付宝的高可用与容灾架构演进曾欢@阿里巴巴shanheng.zh@alibaba-inc.com个人经历2012年2013-2014年2015年负责天猫、淘宝等相关核心系统负责蚂蚁金服运维,稳定性相关加入技术保障部应用运维团队的运维工作连续两年『天猫双十一卫士』蚂蚁异地多活项目业务稳定性平台目录01纯真-童年时期OPTIONS02懵懂-少年时期OPTIONS03成熟-青年时期OPTIONS04Q&AOPTIONS05OPTIONS纯真-童年时期1初期系统架构商用LB入口网关入口网关LB账户系统交易系统账务系统

2、交易系统账务库交易库『单机房』架构的背后•容灾能力低单应用出现问题无法切换主备切换业务中断•应用系统停机维护•业务量数十个数十万级/天业务量增长带来的问题•商用LB瓶颈:VIP数量只增不减,LB宕机影响巨大入口网关LB交易系统账户系统交易系统账务系统•核心DB单库瓶颈账务库交易库新架构要解决的问题:•支撑日益增长的业务量:数百万级/天•解决容量问题:数百个系统•消除架构单点懵懂-少年时期2硬负载=>软负载:分布式服务调用Pub1Pub2一致性SessionhashData配置中心SessionDataSess

3、ionSub2Sub2数据可扩展:UID水平拆分交易系统交易系统分布式数据访问层交易库交易库1交易库交易库交易库交易库交易库1交易库2交易库3交易库41234GSLB50%50%机房A机房B配置中心配置中心交易系统账户系统交易系统账户系统交易系统账务系统交易系统账务系统交易系统账务系统交易系统账务系统交易系统账务系统交易系统账务系统交易数账户数交易数账户数交易库据库账务库据库交易库据库账务库据库01020201交易账务交易账务备库2备库2备库1备库1数据同步『多机房』架构优势扩展性&高可用应用多机房服务调用数

4、据水平拆分更高的整体可用性独立部署机房内隔离够用了吗?容灾切换过程IDC级用户流量DB主备切换别故障切换Oracle异常情况下的主备切换10min数据高可用一致性业务Failover方案MasterSlaveFailoversyncCommonworkMasterSlaveFailoverFailoverdownworkMasterSlaveFailoversyncFailbackworkworkGSLB50%50%机房A机房B配置中心配置中心交易系统账户系统交易系统账户系统交易系统账务系统交易系统账务系统交

5、易系统账务系统交易系统账务系统交易系统账务系统交易系统账务系统交易数账户数交易数账户数交易库据库账务库交易FO交易FO据库交易库据库账务库据库01库1020201库2交易账务交易账务备库2备库2备库1备库1数据同步『多机房多活』架构的容灾能力故障容忍单应用机房故障容灾切换容灾切换成熟-青年时期3严峻的新问题DB连接数城市IDC资源限制跨IDC网络延时机房间流量对新一代架构的需求010203彻底解决DB连接数问题彻底解决IDC资源限制保证业务连续性060504高可用-异地多活蓝绿发布单元化的实质单元1单元2单元

6、3接口层F1F2F3产品层P1P2P3核心层C1C2C3数据层DBDBDBDB单元化核心思想•核心业务•数据按照UserID拆分,多机房部署核心剥离•调用封闭•部分数据,不共享长尾独立•非核心业务•不能按照UID拆分•核心不依赖长尾支付宝单元化架构实现实现思路:•水平拆交易、支付、账务等,每个单元单元A单元A只有部分数据。0102APPDBAPPDB•上层单元化改造从DB层往上延伸水平拆分概念,包括应用层到入口层。单元BAPPDB走向异地的挑战城市A城市B延时50ms-5500km单元A_0单元A_10ms全

7、局数据解决延时问题城市A城市B引入单元C单元A_0单元A_1无法拆分的全量数据,全局复制。支撑核心业务本地调用读写分离0ms0ms单元C_0单元C_1数据复制解决数据一致性和时效性问题•基于DB同步的数据复制:延时非敏感业务的异地复制方案;部分业务数据,可忍受3s时效性延迟(比如大部分的配置数据)。•基于消息系统的数据复制:对于延时非常敏感的业务,更低延时的实现方案;上层基于应用进行复制,减少延时。底层DB主备同步同时进行。回顾核心问题DB连接数调用本地化单元封闭机房间流量跨IDC网络延时城市IDC资

8、源限制异地单元部署异地IDC容灾蓝绿发布100%100%100%流量调配流量调配流量调配50%50%0%-100%100%-0%50%50%A.A.A.A.A.A.BlueGreenBlueGreenBlueGreen老老新老新新支付宝单元化全局架构接入层机房A机房B机房C单元A单元A单元AA1_AA2_AA3_A管控系管控系管控系A1_B统A2_B统A3_B统单元C单元C单元C城市A城市B数据复

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。