Embed Size (px)
Citation preview
支付宝运维管理实践
支付宝 周明
2013-01-18
仅内部交流用
中国最多人选用的第三方网上支付平台
支付宝 – 中国最多人选用的第三方网上支付平台 支付宝成立于2004年，是中国最多人选用的第三方网上支付平台。 支付宝致力为上亿计的个人及企业用户提供安全可靠、方便快捷的网上支付和收款服务。 截至2012年6月，支付宝注册账户数突破7亿。 在2012年11月11日，支付宝完成了1.058亿笔交易，创下了单日交易量的新高。
淘宝双11 带来的高峰数据
10000万 19.5亿
1280万
2010年
2012年
191亿
54亿
3360万
2011年
交易额
交易笔数
付款峰值笔数
6.3万/分钟
2万/分钟
20.5万/分钟
2012年亚马逊11月26日，2650万件商品/天记录，平均306件商品/秒记录 “亚马逊公布”
Paypal 峰值付款
4
• 开发更简单
• 质量更可控
• 持续交付
• 降低单笔处理成本
• 无厂商依赖
• 99.99%
• 核心业务做到0停机维护
• 自动化
• 应用级灾备
• 安全
• 千万级-> 亿级->十亿级
• 同城 -> 异地->全球
• P级数据深度应用
海量 稳定
速度 成本
技术架构目标
支付宝系统发展历程
2005年
挑战 2011年+ 2006年 2007年 2008年 2009年 2010年
架构
服务范围: 担保交易@淘宝
交易笔数: <1万/天 代码量: 十万级 技术团队: 约 10人
一代架构: 烟囱型
服务范围: 交易@亏联网 交易笔数: <50万/天 代码量: 百万级 技术团队: 约 100 人
二代架构: 面向服务型
服务范围: 多资金渠道、多支付工具、多应用场景 交易笔数: 约1000万/天 11.11日：1280W 代码量: 千万级 技术人员: 1000人+
服务范围: 支付宝@everywhere 业务量: 亿级+ 11.11:3369W 代码量: 千万级+ 技术人员: 异地/开放
三代架构: 于平台型
6
现有平台技术能力
系统具备处理1亿+交易的能力 2012年全年可用率99.99%
核心数据库，完成41亿数据库事务，执行285亿次的SQL，生成15TB日志，访问1931亿次内存数据块
应用系统，完成1000亿+服务调用，由600+个应用协同完成
7
稳定性
成本
双11应对
8
稳定性
度量指标 运维不可用率时长（运维可用率）
因故障引发10分钟及以上，创建or支付笔数与基线相比下跌超20%，则计入运维不可用时长。
技术团队可控的 技术团队无法控制的
服务不可用时长=运维丌可用+计划内停机维护 + 第三方原因不可用
关键数字： 运维可用率 服务可用率（用户端感受）
（运维不可用时长） （服务不可用时长）
检验
运维能力
检验
系统架构
9
稳定性
技术步骤 基础冗余
（网络、负载均衡）
去单点 • DB 去设备单点
• 去机房单点
去依赖
快速切换（比如：单库1分钟，单机房所有DB 15分钟，含应用30分钟完成）
演练机制建立
10
稳定性
技术步骤 去单点——DB去单点
• DB 拆分，比如1拆10
原则：降低单设备故障对业务的影响 （1）由集中式分布式
（2）由小机—>多PC，高端存储—>本地存储
DB1主
DB1备
DB1主 DB2主 DBn主
DB1备 DB2备 DBn备
小机 +高端SAN存储 PC+ 本地存储+ 低端SAN 日志存储
稳定性技术关键: 消除数据库单点
数据复制中心
1
2
n1
核心交易数据 (分表/分库/failover)
主交易系统
交易处理服务 (写场景)
交易记录查询系统
用户交易记录查询服务 (读场景1)
1
2
n2
商户查询系统
交易记录数据 (分表幵分库)
商户查询不对账 (读场景2)
1
2
n3
商户/平台商交易数据 (分表幵分库)
分布数据访问层
主 备
12
稳定性
技术步骤 去单点 ——机房去单点
• 同城双中心
• 任一机房down，在可预期的时间内（比如30分钟）完成业务恢复
去依赖 • 应用分级（一级、二级）
低级的应用故障不能影响到高一级
至少主交易流程的应用不能被其他应用所影响
稳定性技术关键: 控制服务依赖
交易系统
交易引擎
流程引擎
规则引擎
资金处理
产品账接入
商户通知
数据持久
收费接入
统一事件
扩展支付工具
业务核查
收费系统
商户通知
消费记录
沟通
商户查询
营销
核心账务
风险核查 消息 系统
超时处理
业务系统 业务系统
担保交易 即时到账交易 货到付款交易
异步交易事件处理 产品账
扩展支付工具 扩展支付工具
可靠
可靠
可靠
可靠
可靠
可靠
可靠
非可靠
非可靠 强依赖
弱依赖
本地消息failover 弱依赖开关
14
稳定性
技术步骤 快速切换
• 单库 1 分钟，整机房DB 15分钟，整机房业务恢复 30分钟内完成 （某银行2012年4小时down 机事件）
• PC server 故障是常态，DB 主备切换时长不可忍受，failover 1分钟内完成
• 机房down 也是大概率事件 （09年前的淘宝机房故障、2010年淘宝120小时的油机供电，某电商2012年机房down事件）
DB1主
DB1备
DB1主 DB2主 DBn主
DB1备 DB2备 DBn备
小机 +高端SAN存储 PC+ 本地存储+ 低端SAN 日志存储
failoverDB
15
IDC1
交易系统 账户系统
交易数据库 账户数据库 交易数据库
confreg
交易系统 账户系统
IDC2
交易系统 账户系统
交易数据库 账户数据库 交易数据库
confreg
交易系统 账户系统
账户数据库 账户数据库
GTM
稳定性技术关键: 消除IDC单点
16
稳定性
技术步骤 演练机制
• 每月一次大演练，比如单机房切换 （年度大计划，每Q的小计划）
17
稳定性
夯实运维体系 运维管理体系
变更管理、故障管理、预案机制、演练机制 建立幵有效运转。
运维基础体系建立 • 标准化运维工作
配置标准化（网络、DB、应用，OS版本、参数标准化）
操作规范化
• 运维工具体系（效率&质量） 监控体系（系统、网络、DB、应用）
管理体系（Iaas 平台）
应急体系 （预案、组细体系等）
其他基础： 如优化报警等（如DB降低为年初5%）
运维架构（自研发LB & SSL 卸载& ADNS替代商用产品， IAAS 平台成型）
运维意识： 运维往前走（架构、 DBA、 ASA 提案）
18
稳定性
成本
双11应对
19
成本 预算委员会（运维、开发组成，负责预算制定、执行）
每Q 采购一次 （能否丌采贩，能否少采贩，能否晚采贩）
优化 • 性能优化 （同比2011年，所有app 2012年平均提升74%，交易关键路径提升84%）
• 业务优化
按单笔交易核算成本
20
稳定性
成本
双11应对
21
业务指标转变成系统容量 梳理应用关键路径,找出最短的板
如何把业务指标转换成对网络的压力和容量
运营的变化，是否有新增的未知地带
关键项目 如关键系统性能优化…
深入业务 支付和创建能力丌匹配的用户体验提升----活动排期；
整链条看支付环节
深入淘系运营，了解整体活动情况和红包运营、配置的绅节
了解关键运营活动进展，同时给出架构建议和需求关门时间
和宠服、公关团队就预案、预计可能出现的问题，对用户的效果提前沟通，便亍宠服解答用户问题
预案和演练 预案的有效性、可执行性、影响面
限流值的合理设置
故障应对----切换failover演练；
单机房故障影响分析和演练
突发事件的影响
双11准备关键点
开关：
降级开关
去依赖开关
弹性技术关键: 秒级监控
支付宝监控系统能够在5~10秒之内发现故障，幵且做出监控报警
监控的计算任务被动态的分配到各计算节点，可以快速的做出响应，幵且充分利用计算资源
可以通过统一的监控模型，快速的进行监控点配置
弹性技术关键: 分析决策
计算 • 脚本计算：运行用户自定义groovy脚本
• 规则计算：使用规则配置运行
决策 手动决策：选择相应资源操作开关推送值
辅助决策：弹性平台计算生成决策，人工実核，选择执行
自动决策：弹性平台生成决策，幵立即执行
数据（秒级监控） 原始监控数据
计算结果、决策
24
统一资源管理
运维管理
发布部
署
环境交
付
编译构
建
监
控
监控数
据查询
应用运行时
数据源 应用内
部开关
容器资
源
SLA流
量管理
服务组件操作
消息 调度 缓存
底层资源
网络 负载均
衡 虚拟机
应用运行数
据的收集
监控系统的
数据建模和
计算
弹性平台的
分析
产生控制命
令 指令执行
银行渠道数据采
集
银行渠道数据监
控
分析发现某银行
A渠道异常
根据模型产生调
拨指令
切换到某银行的
B渠道
弹性技术关键: 分钟级计算资源调度
2012年双11作战信息流转 最短决策链-适当放权,缩短决策链
26
淘宝业务数字： 0:01： 支付宝成交19.2万笔，同时涌入1000万人
0:10： 支付宝成交2.5亿
0:37： 支付宝成交10亿
1:10： 支付宝成交20亿
2:19： 支付宝成交33.7亿
13:38: 支付宝成交100亿, 全天支付宝成交191亿
技术数字 预案准备（250+）
预案执行 • 主站执行96项次
• 金融执行287项次
• 无线执行3项次
技术团队值班参战人员： 200+
双11的一些数字
27
运维要跟开发更近一点 双周的稳定性会议
双周的架构会议
双月技术委员会
每周生产运行会
谢谢，欢迎交流
