胡喜支付宝高可用系统架构的演变ppt.docVIP

支付宝三年光棍节高可用系统 架构的演变 阿玺 支付宝-技术部 Mail: xi.hux@ weibo: 支付宝_阿玺 个人介绍 ? 胡喜，花名阿玺，2007年加入支付宝，主持支付 平台基础技术的架构设计与研发工作，并且参与 支付宝核心支付平台的架构设计和系统升级。 支付宝系统发展历程 服务范围: 担保交易@淘宝 交易笔数: 1万/天 代码量: 十万级 技术团队: 约 10人 服务范围: 交易@互联网 交易笔数: 50万/天 代码量: 百万级 技术团队: 约 100 人 服务范围: 多资金渠道、多支付工具、 多应用场景 交易笔数: 约1000万/天 11.11日：1280W 代码量: 千万级 技术人员: 1000人+ 服务范围: 支付宝 @everywhere 业务量: 亿级+ 11.11:3369W 代码量: 千万级+ 技术人员: 异地/开放 挑战 2005年 2006年 2007年 2008年 2009年 2010年 2011年+ 一代架构: 烟囱型 二代架构: 面向服务型 三代架构: 云平台型 架构 2012.11.11系统必须具备交易处理能力： 1亿+ 80亿+数据库事务 500亿+的SQL执行 1000亿+服务调用 500+个应用协同完成 Agenda ? 可伸缩性：提升容量百万级到亿级 ? 故障容忍：99.9%到99.99%+ ? 弹性控制：人工控制到秒级自动调度 一个简化的支付宝系统模型 IDC 交易系统 账户系统 LB 数据库 V 1 提升容量百万级到亿级 可伸缩 数据库的瓶颈 IDC 交易系统 账户系统 LB 数据库 V 1 数据可伸缩性：数据垂直拆分 IDC 交易系统 账户系统 LB 交易数据库 账户数据库 V 2 一致性瓶颈 IDC 交易系统 账户系统 LB 交易数据库 账户数据库 V 2 业务一致性：service层的分布事务 主业务服务 数据库 启动业务活动 登记业务操作 提交/回滚业务活动 1. tryX成功 tryX confirmX cancelX 2. tryY成功 3. confirmX成功 数据库 从业务服务 实现 ?一个完整的业务活动由一个主业务服务与若 干从业务服务组成 ?主业务服务负责发起并完成整个业务活动 ?从业务服务提供TCC型业务操作 ?业务活动管理器控制业务活动的一致性，它 登记业务活动中的操作，并在业务活动提交 时确认所有的TCC型操作的confirm操作， 在业务活动取消时调用所有TCC型操作的 cancel操作 业务活动 管理器 活动日志 4. confirmY成功 tryY confirmY cancelY 与2PC协议比较 从业务服务 ?没有单独的Prepare阶段，降低协议成本 ?系统故障容忍度高，恢复简单 数据库 单个库的瓶颈 IDC 交易系统 账户系统 LB 交易数据库 账户数据库 V 2 数据可伸缩性：数据水平拆分与复制 IDC 交易系统 账户系统 LB 交易数据库 账户数据库 V 3 数据可伸缩性：交易数据拆分 用户交易记录查询服务 交易处理服务 商户查询与对账 (读场景1) (写场景) (读场景2) 主交易系统 交易记录查询系统 商户查询系统 分布数据访问层 核心交易数据 (分表并分库) 交易记录数据 (分表并分库) 商户/平台商交易数据 (分表并分库) 1 1 1 主 2 2 2 n1 n2 n3 数据复制中心 网络伸缩瓶颈 IDC 交易系统 账户系统 LB 交易数据库 账户数据库 V 3 网络可伸缩性：消除网络设备瓶颈 IDC confreg 交易系统 账户系统 交易数据库 账户数据库 V 4 服务器伸缩瓶颈 IDC confreg 交易系统 账户系统 交易数据库 账户数据库 V 4 服务器伸缩：服务器扩展到多个IDC IDC1 IDC2 confreg 交易系统 交易系统 账户系统 账户系统 交易数据库 账户数据库 V 5 跨机房通讯的瓶颈 IDC1 IDC2 confreg 交易系统 交易系统 账户系统 账户系统 交易数据库 账户数据库 V 5 IDC伸缩：部分独立IDC IDC1 IDC2 confreg confreg 交易系统 交易系统 账户系统 交易数据库 账户数据库 账户系统 V 6 小结：提升容量百万级到亿级 ? 数据的可伸缩性 – 垂直，水平拆分，复制，分布式事务 ? 网络可伸缩性 ? IDC可伸缩性 应用中间件技术架构 应用 展现 协调 SOFA-MVC （full stack） SOFA-Mashup （component） 调度中心 （scheduler） 分布式 session 应用中间件平台 安全框架 security A/B Test 组件 服务容器 配置中心 （confreg2.0） 组件集合