农行副主任工程师赵勇 - 双十一背后的银行系统

容春海

2017/11/14 发布于 技术 分类

双十一购物狂欢,在大家买买买的背后,除了各大电商平台,支付宝微信等第三方支付,传统银行系统为了保障消费者的购物顺畅也发挥了重要作用,经受了性能的考验。本次分享主要从测试保障、系统设计、运行监控、账务处理等方面,对传统银行应对双十一交易峰值挑战的经验进行总结分享。

文字内容
1. 双十一背后的银行系统 农行软件开发中心 赵勇
2. 目录页 01 业务情况 02 系统设计 03 保障工作
3. 1 业务情况--交易量 25 14000 交易笔数(亿笔) 交易金额(亿元) 12000 20 10000 15 8000 10 6000 4000 5 2000 00 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 图 1 第三方支付交易月度分布情况 Ø 截至2016年末,与农业银行开展业务合作的第三方支付机构145家。 Ø 全年第三方支付交易笔数168.91亿笔,同比增长89.21%;交易金额11.72万亿元, 同比增长 97.69%。(其中,支付宝交易笔数为74.51亿笔,占比44.11%,交易金额为7.25万亿元,占比 61.82%)
4. 1 业务情况--交易特点 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 单位(笔/小时) 12000000 10000000 8000000 零时开始的1个小时内, 系统交易量达到1024万笔 6000000 4000000 2000000 0 2015年 2016年 图2 近两年“双十一”当天第三方支付交易量情况 第三方支付交易量占全行 43.7 交易量27.69%,但交易 峰值占比达到80.65% 12.1 9.3 7.5 交易量(千万笔) 交易峰值(千笔/秒) 核心银行系统 第三方支付 图3 “双十一”当天核心银行系统与第三方支付交易情况 Ø 系统交易率在零时过后的10分钟内快速达到峰值,为日常的6.4倍。 Ø 交易量从日常的2千多万笔,增长到1.21亿笔,为日常的5.26倍。 Ø 系统面临最大的挑战来自前零时开始的1个小时。
5. 1 业务情况--小结 第三方快捷支付 持续稳定增长 第三方快捷支付方式已经成被大众广泛接受,用户习惯已经养成, 支付交易规模保持快速增长。 交易特点鲜明 系统瞬间负载极高 行业集中度 进一步提升 在“双十一”、春节红包等特殊时点,第三方支付交易吞吐量会数 倍于日常时点,给银行信息系统的生产运维保障带来极大的挑战。 在第三方支付领域,支付宝(依托电商)和财付通(依托社交)凭 借其各自在相关领域的绝对优势带动了其支付业务的快速发展,两 者占第三方支付总交易金额的90%以上。 性能 保证借记卡10000TPS,贷记卡1000TPS,交易耗时不超过1秒。
6. 2 系统设计--整体架构 第三方支付机构 LB 集中监控 日志中心 合约 限额 支付 退款 快捷支付系统 核心银行 缓存 数据库
7. 2 系统设计--数据架构 堆叠扩展的数 据库架构 Ø 采用高性能数据库RAC集群部署,保证系统的高可用性。 Ø 根据业务场景特性,按照客户维度进行分库、分表,每个表再根据日期进行分区, 实现堆叠扩展。 Ø 通过数据缓存技术实现静态数据及变化不大的数据的缓存,减少数据访问压力。 应用服务 • 数据访问层实现多数据 源、多数据表路由,对开 发人员透明。 数据路由 数据访问层 结果合并 RAC集群部署 RAC集群1 实例1 实例2 RAC集群2 实例1 实例2 ... ... 访问代理 缓存服务器部署 节点 节点 • 基于ORACLE RAC集 群部署,多实例保证数据 库高可用 • 根据业务场景特性对订 单表等重要数据库表按照 一定维度(如商户号+订 单号、卡号等)进行拆表。 • 每个拆分的表再按照日 期进行分区,便于将历史 数据转入历史数据库。 节点 节点
8. 2 系统设计--缓存服务 Ø 主要使用cluster方式,也支持sentinel方式。 Ø 集群中的数据通过分片分布在集群所有的master上,master和slave之间是主从复制的关系。 Ø 通过选举机制,master宕机后slave会立刻顶替master继续保证集群正常工作。
9. 2 系统设计--缓存服务 Ø Redis软件的配置、监控、启停、统计分析等纳入分布式缓存管理平台统一管理。 Ø 解决Redis实例碎片化问题,降低运维成本。 Ø 管理平台基于CacheCloud构建,添加了agent代理,用于执行SSH命令。 应用系统(1) HTTP Redis(1) 应用系统(2) HTTP Redis(2) ...... 应用系统(N) HTTP Redis(N) HTTP HTTP HTTP 分布式缓存管理平台
10. 2 系统设计--日志中心 权限控制 存 日 志 数 据 储 及 索 引 集 群 日志数据查询与展示 简单搜索 逻辑复合搜索 HTTP存储、查询等接口 结果展示 索引及数据存储 日志索引器 解析日志 转发日志消息 日志消息 缓存集群 接收日志 存储日志数据 应用服务器 log4netappende ... 应用服务器 Logbackappender 集群负载均衡 应用服务器 logsender Ø 分布式系统中日志 散落的每个服务器 节点,当系统出现 问题时,需要快速 的定位问题节点, 当节点出现故障时 候,错误日志需要 传送到其他服务器 ,这都需要有一套 日志统一管理系统 Ø 日志收集系统是基 于 Elasticsearch 、 logstash和kibana 搭建的实时日志查 询、收集和分析系 统,已广泛使用。
11. 2 系统设计--日志中心 Logstash Kafka ElasticSearch 应 用 1.写日志文件 或发送日志报文 日 志 2.转发给Kafka 3.读取数据 4.存入ES集群 服 收消 务 器 集 器 息 队 列 索 引 器 Kibana 5.搜索日志请求 浏 览 器 10.展示搜索结果 6.调用Kibana 日 志 网 站 9.渲染并返回子页面 展 示 组 件 7.搜索数据 8.返回搜索数据 存 储 集 群 说明:1 ~ 4 表示日志存储场景,5 ~ 10 表示日志搜索展示场景
12. 2 系统设计--日志中心
13. 2 系统设计--集中监控 权限控制 配置管理 明细数据索引存储 搜索接口 存储数据 监控数据索引器 解析数据 转发数据 监控消息队列 集群 接收数据 .Net应用 监控Agent 搜索明细数据 逻辑复合搜索 监控数据库 配置数据 监控数据 监控数据分析报警平台 分析数据 报警 存储数据 集群负载均衡 Java应用 监控Agent Ø 该系统能够为 应用监控系统 提供交易级监 控数据和服务 器系统监控数 据,并且提供 监控历史数据 详情搜索,以 及多种可配置 的报警规则等 功能。
14. 2 系统设计--集中监控 ElasticSearch Logstash Kafka C# Java 应 1.监控数据 用 服 务 器 应 1.监控数据 用 服 务 器 2.读取数据 消 息 队 列 4.读取数据 索 引 器 监 控 分 析 平 台 3.存入ES 5.分析结果 存入数据库 集 群 监 控 6.读取 数 据 库 监 控 中 心
15. 2 系统设计--集中监控 快捷支付交易概览图 交易量Top10 错误码Top10 商户交易量Top10 快捷支付交易统计 快捷支付系统双十一交易高峰时期每分钟交易量 快捷支付交易执行情况分析
16. 2 系统设计--集中监控 应用 节点 数据库 节点 系统 级别 应用 级别 交易 级别 操作 级别 事前-健康检查 1.监控配置 -监控指标配置 -数据采集配置 -健康标准配置 -处置/报警配置 2.健康检查 -系统定期自动检查 -运维人员不定期检查 缓存 节点 …... 后台 系统 事中-自动处置或人工处置 1.自动处置 -节点隔离 -切断出错通道 2.人工处置 -各种警渠道通知责任人 -各种人工处置措施 事后 – 总结与分析 1.事件日志记录 2.处置日志记录 3.事件原因分析 4.经验分享
17. 2 系统设计--双中心架构 1 客户通过支付宝发起快 捷支付业务 2 支付宝通过专线与我行两中心对接,交易随机发往 两中心。 行外系统 F5解析报文并对卡号 进行判断,根据卡号 哈希对4取余,余数为 3 2,3的交易分别发往北 京中心的集群3和集群 4。余数0、1的交易 分别发往上海中心集 群1和集群2。 4 应用服务器访问 数据库RAC,进 行数据操作。 0 RAC 1 上海中心 专线 支付宝应用 专线 3'LB LB将部分请求重定向至北京中心 01 应用服务 器集群1 跨中心备库 3' 4' 1 RAC 2 应用服务 器集群2 2 进行跨中心数据同步。 以库1为例,将库1跨中 RAC 5 心同步至北京中心的1'。 跨中心同步只能用DG方 3 式 ADG 北京中心 LB 23 应用服务 器集群3 跨中心备库 1' 2' 行内系统 应用服务 器集群4 3 RAC 4
18. 2 系统设计--账务处理 Ø 在账务处理上,如果实时入账,那么对于支付机构账户余额的更新将成为热点。为了 避免上述情况,为支付机构账户建立一 对一的过渡账户,过渡账户只有明细没有余 额,在业务低峰期,通过批量的方式对明细进行汇总入账。 明细1 明细2 明细3 明细4 明细5 ...... 明细n 过渡账户 汇总入账 支付机构账户
19. 2 系统设计--小结 Ø 按照客户维度分库分 表 Ø 数据访问层屏蔽复杂 度 分库 Ø 水平可扩展性 Ø 集群高可用 负载均衡 大并发 高可用 Ø 提高数据访问性能 Ø 降低数据库压力 缓存 日志 Ø 日志集中存储 Ø 问题分析 监控 Ø 实时监控 Ø 及时预警
20. 3 保障工作 加强系统压测 确保资源投入 具体 措施 做好运行保障
21. 3 保障工作——系统压测 目标: Ø 借记卡:10200TPS,贷记卡:1000TPS。 Ø 9500TPS-10000TPS,持续5分钟,响应时间1秒以内。 历经8次系统压测 11000TPS 2565TPS 达到目标 迭代优化 解决问题 发现瓶颈
22. 3 保障工作——系统压测 发现并解决性能隐患 准确估算系统资源 压测效果 验证运行保障机制 确定分流策略
23. 3 保障工作——资源扩容 数据库 应用服 务器 资源扩容 网络资源
24. 3 保障工作——运行保障 组建保障团队 运 流量分配策略 行 保 业务峰值时点预测 障 方 应急处置方案 案 沟通协调机制
25. 3 保障工作——小结 共同的目标和信任是前提 前提 密切的沟通机制是 纽带 纽带 顺利应对 双十一高峰 基础 高可用的系统架 构是基础 充足的资源配置 是保障 保障 关键 系统压测是关键
26. THANK YOU