摘要：随着支付行业向各类便民账单服务、金融服务类扩展，支付内核采用固定格式数据交换模型已不能适应快速灵活开发的需要。以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)［23］，对软件系统内部数据交互关注较少。以支付行业为例，交易从外部的终端或移动设备发起，通过接入前置发到支付核心系统已经经过了两次数据转换，而在支付系统内部还有5层数据交换。因此统一支付系统外围和内部数据交互格式，同时减少支付系统数据交换层次对于提高效率是非常必要的。

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

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

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

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

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

1.2数据交互格式

以往支付核心系统大都采用固定格式，而移动互联网业务使用XML和JSON较多。根据业界对XML、JSON这些跨平台的复杂数据格式的编码、传输、解析效率进行的实验［45］，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的一半［45］。

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

1.3基于JSON的数据交换模型