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

2020-02-27 576浏览

  • 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