按照嘉宾的要求，本文不对外公开。如果你是意外看到这篇文章，请勿将链接发送给其他人。

主题分享

大家好 我今天分享一下某国有银行对接网联后压测结果的架构漫谈；

1 背景

根据央行规定，支付结构和银行直接通道将被切断，就是通俗的断直联；所有银行将对接网联；

举例：支付宝发起到网联，网联到银行，日粗；

2 压测流程简介

image
这里压力源模拟网联过来的请求，真实的请求是：

  1. 请求1到f5–>f5到https加速器–>返回后到第二层f5–>第二层f5到对接epcc应用websphere集群–>对接epcc应用再到贷授权处理系统;
    • 其中epcc对接系统和贷授权处理系统各自拥有分布式数据库
    • https加密属于第一层最外面加密，根据网联规范，请求发送的是xml报文，报文带有签名信息，签名信息来自于军工级加密机处理的返回结果，属于硬加密；
    • 除签名报文，对于关键字段，如账号，金额，或者密码会另外再做加密处理;
    • 因此，网联送过来的报文实际上已经是加签报文，银行拿到报文时除了https转http还要解签；
    • 加密机的处理能力非常高，单台加密机外加前置系统对外能提供8000tps的处理能力，支持横向扩展；
    • https加速器处理效率也很高，基本上都是几个毫秒的处理，支持几万tps；
    • 因此大部分消耗都会在网联对接处理系统和贷授权系统；
  2. ++网联对接系统简称epcc++，对应网络清算支付公司的epcc，使用was集群，只要是银联支付，协议支付，退款，签约，查询，差错提交等常用功能，和通俗意义上的支付系统别无二差，epcc会落地报文；
  3. ++贷授权是新一代分布式式核心记账处理系统++，传统的主机因为资源mips问题和成本问题逐渐会被开放式架构所替代，作为开发系统，贷授权的核心在于分布式数据库；
  4. 因此通过多轮比较，对比，逐步进行epcc和贷授权的系统进行优化，提升网联支付系统处理能力，从500tps到2000tps，到6500tps，到1万tps；

3 优化方案

3.1 优化核心点

  1. 日志处理从logback单机落盘转为kafka数据集中处理;
  2. 对分布式数据库多表join的sql转为按主键查询避免使用分布式数据库不擅长功能;
  3. 对多个并发锁从应用代码层进行分化处理;

以上分别能在原基础上提高30%到50%不等的性能提升;

3.2 批量清算问题

  1. cbase会定时异步将数据同步到关系数据库db2上，在db2上使用传统关系型sql，多表join操作进行清算，钆差操作，避免去出发cbase的弱项；
  2. 当前的架构很多依靠异步批量和纯分布式架构去处理支付请求，并未融合进主机资源；
  3. 传统四大行已经在讨论异构的方式；
    • 所谓异构就是核心系统拥有主机和开放两种核心；同时提供对外联机服务；
    • 主机拥有主机的优势，稳定，基本不用过多考虑优化的方案，只要关注账务类业务逻辑，开放横向扩展能力强，但对开发能力要求更高，尤其是作为核心系统；
    • 如何同时提供对外联机功能，让适合主机的业务到主机，适合开放的业务到开放
  4. 有一种方案是通过智能路由，内存数据库对比，通过类似账号+version的方式判断进行路由是到主机还是开放，这样的话就成了3个核心，内存db+主机+开放3节点；
    • 当路由到开放后，开放处理完继续发送异步mq消息到主机去同步状态信息，同理对于主机优先处理情况；
    • 这样一个3节点，对于异常交易，异常通讯需要考虑很多，因为你是核心系统；
    • 所以必须还要有智能监控系统；通过智能监控系统去对错帐进行冲正，补偿操作；
    • 这个架构是有点三角形节点部署，每个顶点支持横向扩张；三角形前面可以是微服务或者soa企业级总线。

以上，是一种思路，不代表最佳方案，还有的方案是作为一前一后的处理，个人觉得两种方案各有利弊；

Q&A

Q: cbase支持跨分片分布式事务？db2在面对海量数据对帐性能怎样？
A: cb不是直接到落盘处理，他会有merger；server对分片数据去做多节点合并操作，所以你的事务应该是在单节点内存内内先完成，db2不会去做海量数据的处理，更多是当日内批次间的处理操作，数据会按批次或会计日迁移走，避免海量数据，去挑战数据库极限；
Q: 没有直接落地磁盘，只保存在内存的话，如何避免crush导致的数据丢失？
A: cb有完整的日志追踪机制，具体要另外展开；
Q: cbase，这是一种开源数据库吗，还是自研的？
A: 扩展的ob；

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。