学习笔记基于JSON数据交换模型的实时支付系统设计和实现

Posted 2021-04-30 电子技术应用ChinaAET

摘要：随着支付行业向各类便民账单服务、金融服务类扩展，支付内核采用固定格式数据交换模型已不能适应快速灵活开发的需要。以JSON为基础构建精简3层数据交换模型，并对JSON内存分配管理、键值使用进行优化，实现了支付系统灵活高效开发，同时系统性能更优，占用内存资源更少，在实际应用中效果显著。

0引言

随着2011年5月财付通、支付宝和银联商务等27家企业获得人行第三方支付牌照，第三方支付市场发展迅速，截至2015年底共有269家企业获得支付牌照，全国银行卡联网商户1 670万户，联网POS机具2 282.1万台，金额49.5万亿元。行业呈现以下特点：（1）在终端上从传统线下POS收单向互联网、电视、移动设备等拓展；（2）在内容上由银行卡消费向各类便民服务类（水电煤缴费、充值、还款）、准金融服务类（保险、税务）、金融服务类（基金、理财、小额信贷、保理）业务拓展，业内将之统称为增值业务。增值业务已成为第三方支付行业的发展重点，在要求核心实时支付系统交易可靠、高效处理的同时，还要求新业务快速开发上线。大型实时支付系统交易种类多、功能复杂，由众多子系统和子模块组成，系统之间关联复杂，耦合度较高，选择合适的数据交换模型和交互格式很重要。本文介绍了银联商务在设计和实现新一代实时支付系统时对数据交换模型和交互格式的优化和探索，以及在实际工作中取得的成果。

1、现状分析

实时支付系统需要关联支付系统的各参与方，受理渠道要接入POS、自助机具、手机等移动设备，数据交互格式上有ISO8583、固定格式、XML、分隔符报文、行业特殊报文，支付系统的通信模块收到后转为内部格式，再发给内部子系统，内部子系统再用特殊的数据结构调用子模块，处理完毕后再依次拼接内部格式报文，转换为外部格式报文，调用通信模块发送到银联、银行、外卡组织等支付提供方，对于增值应用还需要按照行业特殊格式组包发送。按照大型系统分层次设计的原则，可以将支付系统抽象为5层数据交换模型，即：外部报文（传统POS设备和移动互联网设备发起）—内部报文—子系统接口—子函数—数据库层和文件层接口。项目组从两个方面进行优化：一是规划和选择合适的数据交换模型，使其能够减少数据转换的层次；二是选用一个合适的数据交互格式，扩展性强，灵活性好，同时易学易用。

1.1数据交换模型

异构系统数据交换模型研究关注系统之间数据交互［1］，一般采用XML/JSON(javascript Object Notation)［23］，对软件系统内部数据交互关注较少。以支付行业为例，交易从外部的终端或移动设备发起，通过接入前置发到支付核心系统已经经过了两次数据转换，而在支付系统内部还有5层数据交换。因此统一支付系统外围和内部数据交互格式，同时减少支付系统数据交换层次对于提高效率是非常必要的。

根据目前支付行业特点，5层数据交换中的外部报文和数据库层格式很难改动，只能在内部报文格式上进行优化，可以考虑将外部报文—内部报文—子系统接口—子函数—数据库层和文件层接的5层接口改为3层结构：外部报文—内部报文（子系统、子函数统一格式）—数据库层和文件层接口。这个中间数据交换层的格式应具备如下特点：

(1)扩展性好。除了必要的信息，如报文头、版本号、消息类型、路由信息，其他交易相关字段可增减。

(2)可读性好。良好的可读性有助于提高日志分析效率，对问题快速分析、生产维护尤为有利。

(3)冗余度低。低冗余则保证了对于报文的传输、字段存储和字段解析时的高性能。

(4)通用性。通用性降低了系统间连接的成本，有多种开发语言支持数据交换格式，降低开发成本，提高系统稳定性。

1.2数据交互格式

以往支付核心系统大都采用固定格式，而移动互联网业务使用XML和JSON较多。根据业界对XML、JSON这些跨平台的复杂数据格式的编码、传输、解析效率进行的实验［45］，2013年银商新支付系统设计时综合分析了固定格式、XML和JSON。

1.2.1固定格式

出于处理高效和运行稳定的考虑，传统支付核心系统使用C开发居多，内部数据交换采用固定格式（比如C STRUCT)，缺陷如下：

(1)灵活性较差。数据字段增减、字段长度变化都会影响数据格式的定义，需要完整的回归测试，导致维护类项目的周期长、工作量大。

(2)扩展性不好。如果接口修改，即使关联系统并不使用新增字段，与之关联的系统必须重新编译，不利于软件之间、进程之间的交互。原基础工具库函数因接口固定，无法直接为其他系统使用，导致软件底层函数、模块、子系统间耦合度太高，无法推广使用。

固定格式数据交互不能满足快速开发、快速投产、松耦合的技术要求。

1.2.2XML

XML在金融行业、尤其是互联网支付中广为采用。在5层数据交换模型中XML一般只用于外部系统和子系统之间，罕用于系统内部交互。XML1.0的规范比较庞大、考虑因素较多，使得XML解析复杂，在高并发、高性能的系统中要解决快速解析问题。

1.2.3JSON

JSON语法简洁冗余度较低，支持JSON的语言多（Java、C、C++、C#、php、JavaScript、Object C、Python），易于程序员阅读和编码，易于Java程序解析和生成，也是Python语言的内置类型。

1.2.4分析

从简化数据交换模型角度，项目组排除了固定报文格式，对XML和JSON进行了比较，参考业界在实验室以及城市交通领域的经验，数据处理效率主要考虑以下几个因素：

(1)数据展示。用JavaScript解析数据，不同浏览器下花费的时间JSON仅为XML的1/4~1/7,结合AJAX技术局部页面刷新可以直接使用JSON，更为节省、用户体验更为流畅［5］。

(2)数据组包和解包效率。数据组包（封装）差别不大，数据解包（反序列化）开销上JSON为XML的一半［45］。

(3)数据存储和传输效率。数据传输上的开销，在一般的应用场景中JSON比XML节省30%~36%［4］。

1.3基于JSON的数据交换模型

基于以上分析，以JSON为内部数据交换格式，将5层数据交换模型精简为3层，如图1所示，即外部报文（对于传统POS设备）—内部报文（原第二至三层改为JSON格式）-数据库层和文件层接口。对移动支付设备甚至可以直接使用JSON格式从外部发送到系统内部（通信层可支持TCP/HTTP/HTTPS，为了保证数据安全和快速路由，还需额外加报文头、签名和认证信息）。项目组以该3层模型构建新一代支付系统，并在关键模块将JSON与XML进行实证对比。

2基于JSON的数据交换模型实证分析

2.1支付系统总体架构图

抽取支付系统关键模块搭建验证系统。如图2所示，核心的金融交易流程处理采用异步模式，通信层（渠道、主机）、数据预处理层（组装、桥接）、基础服务层（加解密、超时控制）使用统一的平台数据处理格式，模型进行接口改造后即可对不同数据格式进行性能对比测试。

测试以典型的POS缴费交易为例，在交易处理的各个子系统和子程序中，对于内部数据格式的每个字段的处理总计“读”约1 200次、“写”约900次（具体次数因业务图2支付系统架构图流程有所不同），下面实证XML和JSON的性能。

2.2测试说明

2.2.1测试环境

软件环境，数据库：Oracle（Oracle11.2.0.2）；测试主机操作系统：AIX 6106 SP6；测试中间件：TUXEDO 10 R3，Weblogic 10.3.5。硬件设备由6台IBM 小型机和2台高端存储组成，如表1所示。交易模拟：2台POS仿真程序分别发起交易，2台PC使用银联仿真器模拟银联和发卡机构。表1测试硬件设备设备类别产品型号子系统用途及配置数量服务器P7系列

2.2.2测试流程及衡量指标

采用JSON作为支付平台统一数据处理格式，要求达到以下指标：TPS≥3 000 （TPS：每秒处理交易数），平均单笔交易耗时<1 s。

测试采用缴费交易，测试采用的库函数版本为：JSON：Jsonc 0.9；XML：Libxml2 DOM。

2.3测试数据

（1）测试中使用两台PC同时模拟终端发送数据，每个模拟程序均包括发送和接收线程，发送频率为每隔700~650 μs发一笔，测试结果如表2和表3所示。

说明：JSON格式TPS能达到并稳定至3000， XML格式在TPS达到2 010时CPU已接近耗尽。

（2）按照200万条交易流水对JSON和XML占用空间测试，结果如表4所示。

说明：采用JSON格式存储要节省23%。

3、对于JSON的底层优化分析

大型支付系统对于性能要求高，特别是为了应对突发性交易峰值的情况，项目组对于JSON底层进行分析和优化，并将其命名为EJSON（Extend JSON）。

3.1对JSON域键名的规划和长度压缩

优化内容主要包括对JSON键值的存储路径进行规划；对平台常用词汇的缩写定义；对各模块、组件中重合的JSON键名进行合并；对键名长度压缩（将原来用下划线分隔的键名定义方式改为缩略词与驼峰法相结合）。经优化后主要进程间通信的消息长度减少，消息的JSON序列化字符串长度从8 200 B降至5 700 B。

3.2JSON开源库对内存的分配机制优化

JSON原内存分配机制如下：在最初初始化时申请16个键值空间（其中为避免散列算法冲突，故仅使用其中的2/3），如发现空间不够则再申请2倍空间，并将原有数据拷贝到新空间。这样虽然能保证存储空间有效利用，但增加系统开销、降低处理性能。针对支付系统场景中JSON键值取值，改进JSON为一次申请足够内存块，无需每次动态申请空间。此优化使单笔交易耗时减少了约8 ms。

4、结论

（1）新数据交互模型是可行的。基于EJSON的方案大大提高了开发效率，报文自外部渠道转换为内部EJSON格式后，所有子系统、大部分子函数使用一个JSON对象作为参数传递变量，新增的业务字段不影响原有函数和系统，大大降低了维护成本。新支付系统上小型项目生命周期大大缩短，平均为49个自然日，其中用于软件开发的时间仅占25%，开发效率大大提高。

（2）EJSON 可以用于生产系统中。目前新一代支付系统已成功投产，系统采用了EJSON作为数据处理格式，并取得良好效果。平均TPS最高能稳定至约3 180笔/秒，平台在压力控制500 TPS时的单笔交易平均处理时间可控制在40 ms以内，日交易量峰值达到1 402万笔。

（3）后续改进方向。以消费者体验为中心，进一步提高移动支付设备接入的便利性和兼容性［6］，加强大数据服务、增值金融子系统支持，在以下方面进行改进：一是JSON将作为数据总线成为系统间交互的标准格式，以此为基础建立统一的JSON变量命名数据字典，对于自有系统命名内外一致，对于外部系统接入尽量只做一次内外转换；二是研究支持JSON存储的数据库，以进一步改3层数据交互为准两层数据交互，以JSON键值为数据存储的元数据，进一步适应未来移动互联网非结构化数据操作的需求。

参考文献

［1］ 钟巍,吴业福. 数据交换模型研究与实现［D］.武汉：武汉理工大学，2008.

［2］ 李聪. 基于XML的数据交换平台的设计与实现［D］.武汉：武汉理工大学，2009.

［3］ 谷方舟,沈波. JSON数据交换格式在异构系统集成中的应用研究［J］.铁路计算机应用，2012，21（2）：14.

［4］ 高静,段会川. JSON数据传输效率研究［J］. 计算机工程与设计，2011，32（7）：22672269.

［5］ 邢四为,宋杰.基于JSON的信息交互系统的研究与实现［D］. 合肥：安徽大学，2013

［6］ 吕光金,曹倩雯.基于TAMTRA的移动支付模式消费者接受影响因素研究［J］.微型机与应用,2015,34(8):8386.