于衛(wèi)國，陳澤瀛，文黎明

(銀聯(lián)商務(wù)有限公司 技術(shù)開發(fā)中心，上海 201203)

?

基于JSON數(shù)據(jù)交換模型的實時支付系統(tǒng)設(shè)計和實現(xiàn)

于衛(wèi)國，陳澤瀛，文黎明

(銀聯(lián)商務(wù)有限公司 技術(shù)開發(fā)中心，上海 201203)

摘要：隨著支付行業(yè)向各類便民賬單服務(wù)、金融服務(wù)類擴展，支付內(nèi)核采用固定格式數(shù)據(jù)交換模型已不能適應(yīng)快速靈活開發(fā)的需要。以JSON為基礎(chǔ)構(gòu)建精簡3層數(shù)據(jù)交換模型，并對JSON內(nèi)存分配管理、鍵值使用進行優(yōu)化，實現(xiàn)了支付系統(tǒng)靈活高效開發(fā)，同時系統(tǒng)性能更優(yōu)，占用內(nèi)存資源更少，在實際應(yīng)用中效果顯著。

關(guān)鍵詞：實時支付系統(tǒng)；第三方支付；數(shù)據(jù)交換模型；EJSON

引用格式：于衛(wèi)國，陳澤瀛，文黎明. 基于JSON數(shù)據(jù)交換模型的實時支付系統(tǒng)設(shè)計和實現(xiàn)[J].微型機與應(yīng)用，2016,35(12)：84-86,89.

0引言

隨著2011年5月財付通、支付寶和銀聯(lián)商務(wù)等27家企業(yè)獲得人行第三方支付牌照，第三方支付市場發(fā)展迅速，截至2015年底共有269家企業(yè)獲得支付牌照，全國銀行卡聯(lián)網(wǎng)商戶1 670萬戶，聯(lián)網(wǎng)POS機具2 282.1萬臺，金額49.5萬億元。行業(yè)呈現(xiàn)以下特點：(1)在終端上從傳統(tǒng)線下POS收單向互聯(lián)網(wǎng)、電視、移動設(shè)備等拓展；(2)在內(nèi)容上由銀行卡消費向各類便民服務(wù)類(水電煤繳費、充值、還款)、準金融服務(wù)類(保險、稅務(wù))、金融服務(wù)類(基金、理財、小額信貸、保理)業(yè)務(wù)拓展，業(yè)內(nèi)將之統(tǒng)稱為增值業(yè)務(wù)。增值業(yè)務(wù)已成為第三方支付行業(yè)的發(fā)展重點，在要求核心實時支付系統(tǒng)交易可靠、高效處理的同時，還要求新業(yè)務(wù)快速開發(fā)上線。大型實時支付系統(tǒng)交易種類多、功能復(fù)雜，由眾多子系統(tǒng)和子模塊組成，系統(tǒng)之間關(guān)聯(lián)復(fù)雜，耦合度較高，選擇合適的數(shù)據(jù)交換模型和交互格式很重要。本文介紹了銀聯(lián)商務(wù)在設(shè)計和實現(xiàn)新一代實時支付系統(tǒng)時對數(shù)據(jù)交換模型和交互格式的優(yōu)化和探索，以及在實際工作中取得的成果。

1現(xiàn)狀分析

實時支付系統(tǒng)需要關(guān)聯(lián)支付系統(tǒng)的各參與方，受理渠道要接入POS、自助機具、手機等移動設(shè)備，數(shù)據(jù)交互格式上有ISO8583、固定格式、XML、分隔符報文、行業(yè)特殊報文，支付系統(tǒng)的通信模塊收到后轉(zhuǎn)為內(nèi)部格式，再發(fā)給內(nèi)部子系統(tǒng)，內(nèi)部子系統(tǒng)再用特殊的數(shù)據(jù)結(jié)構(gòu)調(diào)用子模塊，處理完畢后再依次拼接內(nèi)部格式報文，轉(zhuǎn)換為外部格式報文，調(diào)用通信模塊發(fā)送到銀聯(lián)、銀行、外卡組織等支付提供方，對于增值應(yīng)用還需要按照行業(yè)特殊格式組包發(fā)送。按照大型系統(tǒng)分層次設(shè)計的原則，可以將支付系統(tǒng)抽象為5層數(shù)據(jù)交換模型，即：外部報文(傳統(tǒng)POS設(shè)備和移動互聯(lián)網(wǎng)設(shè)備發(fā)起)—內(nèi)部報文—子系統(tǒng)接口—子函數(shù)—數(shù)據(jù)庫層和文件層接口。項目組從兩個方面進行優(yōu)化：一是規(guī)劃和選擇合適的數(shù)據(jù)交換模型，使其能夠減少數(shù)據(jù)轉(zhuǎn)換的層次；二是選用一個合適的數(shù)據(jù)交互格式，擴展性強，靈活性好，同時易學(xué)易用。

1.1數(shù)據(jù)交換模型

異構(gòu)系統(tǒng)數(shù)據(jù)交換模型研究關(guān)注系統(tǒng)之間數(shù)據(jù)交互[1]，一般采用XML/JSON(JavaScript Object Notation)[2-3]，對軟件系統(tǒng)內(nèi)部數(shù)據(jù)交互關(guān)注較少。以支付行業(yè)為例，交易從外部的終端或移動設(shè)備發(fā)起，通過接入前置發(fā)到支付核心系統(tǒng)已經(jīng)經(jīng)過了兩次數(shù)據(jù)轉(zhuǎn)換，而在支付系統(tǒng)內(nèi)部還有5層數(shù)據(jù)交換。因此統(tǒng)一支付系統(tǒng)外圍和內(nèi)部數(shù)據(jù)交互格式，同時減少支付系統(tǒng)數(shù)據(jù)交換層次對于提高效率是非常必要的。

根據(jù)目前支付行業(yè)特點，5層數(shù)據(jù)交換中的外部報文和數(shù)據(jù)庫層格式很難改動，只能在內(nèi)部報文格式上進行優(yōu)化，可以考慮將外部報文—內(nèi)部報文—子系統(tǒng)接口—子函數(shù)—數(shù)據(jù)庫層和文件層接的5層接口改為3層結(jié)構(gòu)：外部報文—內(nèi)部報文(子系統(tǒng)、子函數(shù)統(tǒng)一格式)—數(shù)據(jù)庫層和文件層接口。這個中間數(shù)據(jù)交換層的格式應(yīng)具備如下特點：

(1)擴展性好。除了必要的信息，如報文頭、版本號、消息類型、路由信息，其他交易相關(guān)字段可增減。

(2)可讀性好。良好的可讀性有助于提高日志分析效率，對問題快速分析、生產(chǎn)維護尤為有利。

(3)冗余度低。低冗余則保證了對于報文的傳輸、字段存儲和字段解析時的高性能。

(4)通用性。通用性降低了系統(tǒng)間連接的成本，有多種開發(fā)語言支持數(shù)據(jù)交換格式，降低開發(fā)成本，提高系統(tǒng)穩(wěn)定性。

1.2數(shù)據(jù)交互格式

以往支付核心系統(tǒng)大都采用固定格式，而移動互聯(lián)網(wǎng)業(yè)務(wù)使用XML和JSON較多。根據(jù)業(yè)界對XML、JSON這些跨平臺的復(fù)雜數(shù)據(jù)格式的編碼、傳輸、解析效率進行的實驗[4-5]，2013年銀商新支付系統(tǒng)設(shè)計時綜合分析了固定格式、XML和JSON。

1.2.1固定格式

出于處理高效和運行穩(wěn)定的考慮，傳統(tǒng)支付核心系統(tǒng)使用C開發(fā)居多，內(nèi)部數(shù)據(jù)交換采用固定格式(比如C STRUCT)，缺陷如下：

(1)靈活性較差。數(shù)據(jù)字段增減、字段長度變化都會影響數(shù)據(jù)格式的定義，需要完整的回歸測試，導(dǎo)致維護類項目的周期長、工作量大。

(2)擴展性不好。如果接口修改，即使關(guān)聯(lián)系統(tǒng)并不使用新增字段，與之關(guān)聯(lián)的系統(tǒng)必須重新編譯，不利于軟件之間、進程之間的交互。原基礎(chǔ)工具庫函數(shù)因接口固定，無法直接為其他系統(tǒng)使用，導(dǎo)致軟件底層函數(shù)、模塊、子系統(tǒng)間耦合度太高，無法推廣使用。

固定格式數(shù)據(jù)交互不能滿足快速開發(fā)、快速投產(chǎn)、松耦合的技術(shù)要求。

1.2.2XML

XML在金融行業(yè)、尤其是互聯(lián)網(wǎng)支付中廣為采用。在5層數(shù)據(jù)交換模型中XML一般只用于外部系統(tǒng)和子系統(tǒng)之間，罕用于系統(tǒng)內(nèi)部交互。XML1.0的規(guī)范比較龐大、考慮因素較多，使得XML解析復(fù)雜，在高并發(fā)、高性能的系統(tǒng)中要解決快速解析問題。

1.2.3JSON

JSON語法簡潔冗余度較低，支持JSON的語言多(Java、C、C++、C#、PHP、JavaScript、Object C、Python)，易于程序員閱讀和編碼，易于Java程序解析和生成，也是Python語言的內(nèi)置類型。

1.2.4分析

從簡化數(shù)據(jù)交換模型角度，項目組排除了固定報文格式，對XML和JSON進行了比較，參考業(yè)界在實驗室以及城市交通領(lǐng)域的經(jīng)驗，數(shù)據(jù)處理效率主要考慮以下幾個因素：

(1)數(shù)據(jù)展示。用JavaScript解析數(shù)據(jù)，不同瀏覽器下花費的時間JSON僅為XML的1/4～1/7,結(jié)合AJAX技術(shù)局部頁面刷新可以直接使用JSON，更為節(jié)省、用戶體驗更為流暢[5]。

(2)數(shù)據(jù)組包和解包效率。數(shù)據(jù)組包(封裝)差別不大，數(shù)據(jù)解包(反序列化)開銷上JSON為XML的一半[4-5]。

(3)數(shù)據(jù)存儲和傳輸效率。數(shù)據(jù)傳輸上的開銷，在一般的應(yīng)用場景中JSON比XML節(jié)省30%～36%[4]。

1.3基于JSON的數(shù)據(jù)交換模型

基于以上分析，以JSON為內(nèi)部數(shù)據(jù)交換格式，將5層數(shù)據(jù)交換模型精簡為3層，如圖1所示，即外部報文(對于傳統(tǒng)POS設(shè)備)—內(nèi)部報文(原第二至三層改為JSON格式)-數(shù)據(jù)庫層和文件層接口。對移動支付設(shè)備甚至可以直接使用JSON格式從外部發(fā)送到系統(tǒng)內(nèi)部(通信層可支持TCP/HTTP/HTTPS，為了保證數(shù)據(jù)安全和快速路由，還需額外加報文頭、簽名和認證信息)。項目組以該3層模型構(gòu)建新一代支付系統(tǒng)，并在關(guān)鍵模塊將JSON與XML進行實證對比。

圖1　基于JSON支付系統(tǒng)三層交換模型

2基于JSON的數(shù)據(jù)交換模型實證分析

2.1支付系統(tǒng)總體架構(gòu)圖

抽取支付系統(tǒng)關(guān)鍵模塊搭建驗證系統(tǒng)。如圖2所示，核心的金融交易流程處理采用異步模式，通信層(渠道、主機)、數(shù)據(jù)預(yù)處理層(組裝、橋接)、基礎(chǔ)服務(wù)層(加解密、超時控制)使用統(tǒng)一的平臺數(shù)據(jù)處理格式，模型進行接口改造后即可對不同數(shù)據(jù)格式進行性能對比測試。

測試以典型的POS繳費交易為例，在交易處理的各個子系統(tǒng)和子程序中，對于內(nèi)部數(shù)據(jù)格式的每個字段的處理總計“讀”約1 200次、“寫”約900次(具體次數(shù)因業(yè)務(wù)流程有所不同)，下面實證XML和JSON的性能。

圖2　支付系統(tǒng)架構(gòu)圖

2.2測試說明

2.2.1測試環(huán)境

軟件環(huán)境，數(shù)據(jù)庫：Oracle(Oracle11.2.0.2)；測試主機操作系統(tǒng)：AIX 6106 SP6；測試中間件：TUXEDO 10 R3，Weblogic 10.3.5。硬件設(shè)備由6臺IBM 小型機和2臺高端存儲組成，如表1所示。交易模擬：2臺POS仿真程序分別發(fā)起交易，2臺PC使用銀聯(lián)仿真器模擬銀聯(lián)和發(fā)卡機構(gòu)。

表1　測試硬件設(shè)備

2.2.2測試流程及衡量指標

采用JSON作為支付平臺統(tǒng)一數(shù)據(jù)處理格式，要求達到以下指標：TPS≥3 000 (TPS：每秒處理交易數(shù))，平均單筆交易耗時<1 s。

測試采用繳費交易，測試采用的庫函數(shù)版本為：JSON：Json-c 0.9；XML：Libxml2 DOM。

2.3測試數(shù)據(jù)

(1)測試中使用兩臺PC同時模擬終端發(fā)送數(shù)據(jù)，每個模擬程序均包括發(fā)送和接收線程，發(fā)送頻率為每隔700～650 μs發(fā)一筆，測試結(jié)果如表2和表3所示。

說明：JSON格式TPS能達到并穩(wěn)定至3000， XML格式在TPS達到2 010時CPU已接近耗盡。

(2)按照200萬條交易流水對JSON和XML占用空間測試，結(jié)果如表4所示。

說明：采用JSON格式存儲要節(jié)省23%。

3對于JSON的底層優(yōu)化分析

大型支付系統(tǒng)對于性能要求高，特別是為了應(yīng)對突發(fā)性交易峰值的情況，項目組對于JSON底層進行分析和優(yōu)化，并將其命名為EJSON(Extend JSON)。

表2　使用JSON作為內(nèi)部格式時系統(tǒng)資源和性能

表3　使用XML作為內(nèi)部格式時系統(tǒng)資源和性能

表4　交易實際占用數(shù)據(jù)庫空間分析

3.1對JSON域鍵名的規(guī)劃和長度壓縮

優(yōu)化內(nèi)容主要包括對JSON鍵值的存儲路徑進行規(guī)劃；對平臺常用詞匯的縮寫定義；對各模塊、組件中重合的JSON鍵名進行合并；對鍵名長度壓縮(將原來用下劃線分隔的鍵名定義方式改為縮略詞與駝峰法相結(jié)合)。經(jīng)優(yōu)化后主要進程間通信的消息長度減少，消息的JSON序列化字符串長度從8 200 B降至5 700 B。

3.2JSON開源庫對內(nèi)存的分配機制優(yōu)化

JSON原內(nèi)存分配機制如下：在最初初始化時申請16個鍵值空間(其中為避免散列算法沖突，故僅使用其中的2/3)，如發(fā)現(xiàn)空間不夠則再申請2倍空間，并將原有數(shù)據(jù)

拷貝到新空間。這樣雖然能保證存儲空間有效利用，但增加系統(tǒng)開銷、降低處理性能。針對支付系統(tǒng)場景中JSON鍵值取值，改進JSON為一次申請足夠內(nèi)存塊，無需每次動態(tài)申請空間。此優(yōu)化使單筆交易耗時減少了約8 ms。

4結(jié)論

(1)新數(shù)據(jù)交互模型是可行的。基于EJSON的方案大大提高了開發(fā)效率，報文自外部渠道轉(zhuǎn)換為內(nèi)部EJSON格式后，所有子系統(tǒng)、大部分子函數(shù)使用一個JSON對象作為參數(shù)傳遞變量，新增的業(yè)務(wù)字段不影響原有函數(shù)和系統(tǒng)，大大降低了維護成本。新支付系統(tǒng)上小型項目生命周期大大縮短，平均為49個自然日，其中用于軟件開發(fā)的時間僅占25%，開發(fā)效率大大提高。

(2)EJSON 可以用于生產(chǎn)系統(tǒng)中。目前新一代支付系統(tǒng)已成功投產(chǎn)，系統(tǒng)采用了EJSON作為數(shù)據(jù)處理格式，并取得良好效果。平均TPS最高能穩(wěn)定至約3 180筆/秒，平臺在壓力控制500 TPS時的單筆交易平均處理時間可控制在40 ms以內(nèi)，日交易量峰值達到1 402萬筆。

(3)后續(xù)改進方向。以消費者體驗為中心，進一步提高移動支付設(shè)備接入的便利性和兼容性[6]，加強大數(shù)據(jù)服務(wù)、增值金融子系統(tǒng)支持，在以下方面進行改進：一是JSON將作為數(shù)據(jù)總線成為系統(tǒng)間交互的標準格式，以此為基礎(chǔ)建立統(tǒng)一的JSON變量命名數(shù)據(jù)字典，對于自有系統(tǒng)命名內(nèi)外一致，對于外部系統(tǒng)接入盡量只做一次內(nèi)外轉(zhuǎn)換；二是研究支持JSON存儲的數(shù)據(jù)庫，以進一步改3層數(shù)據(jù)交互為準兩層數(shù)據(jù)交互，以JSON鍵值為數(shù)據(jù)存儲的元數(shù)據(jù)，進一步適應(yīng)未來移動互聯(lián)網(wǎng)非結(jié)構(gòu)化數(shù)據(jù)操作的需求。

參考文獻

[1] 鐘巍,吳業(yè)福. 數(shù)據(jù)交換模型研究與實現(xiàn)[D].武漢：武漢理工大學(xué)，2008.

[2] 李聰. 基于XML的數(shù)據(jù)交換平臺的設(shè)計與實現(xiàn)[D].武漢：武漢理工大學(xué)，2009.

[3] 谷方舟,沈波. JSON數(shù)據(jù)交換格式在異構(gòu)系統(tǒng)集成中的應(yīng)用研究[J].鐵路計算機應(yīng)用，2012，21(2)：1-4.

[4] 高靜,段會川. JSON數(shù)據(jù)傳輸效率研究[J]. 計算機工程與設(shè)計，2011，32(7)：2267-2269.

[5] 邢四為,宋杰.基于JSON的信息交互系統(tǒng)的研究與實現(xiàn)[D]. 合肥：安徽大學(xué)，2013

[6] 呂光金,曹倩雯.基于TAM-TRA的移動支付模式消費者接受影響因素研究[J].微型機與應(yīng)用,2015,34(8):83-86.

中圖分類號：TP391

文獻標識碼：A

DOI：10.19358/j.issn.1674- 7720.2016.12.027

(收稿日期：2016-02-18)

作者簡介：

于衛(wèi)國(1970-)，男，碩士，工程師，主要研究方向：第三方支付、軟件工程、數(shù)據(jù)安全。

陳澤瀛(1965-)，男，學(xué)士，工程師，主要研究方向：第三方支付、軟件工程。

文黎明(1979-)，男，碩士，工程師，主要研究方向：第三方支付。

Design and implementation of JSON based data exchange model on online payment system

Yu Weiguo，Chen Zeying，Wen Liming

(Technology Development Center, China Unionpay Merchant Services Co.,LTD., Shanghai 201203, China)

Abstract:With the traditional payment industry extending to Internet financial business and electronic bill payment, payment software systems need find a fast and flexible iterative development method. Traditional fixed data exchange model is replaced by JSON based simplified three-layer dynamic data exchange model. This model decreases times of data format conversion. In addition the team optimized memory management and key name rule of JSON. The new designed online payment system using JSON based data exchange model occupies less memory, gets excellent performance, and can support fast and flexible iterative development.

Key words:online payment system; the third party payment; data exchange model;EJSON