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

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

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

?

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

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

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

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

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

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

0引言

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

1現(xiàn)狀分析

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

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

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

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

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

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

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

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

1.2.1固定格式

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

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

(2)擴(kuò)展性不好。如果接口修改，即使關(guān)聯(lián)系統(tǒng)并不使用新增字段，與之關(guān)聯(lián)的系統(tǒng)必須重新編譯，不利于軟件之間、進(jìn)程之間的交互。原基礎(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ù)交換模型角度，項(xiàng)目組排除了固定報(bào)文格式，對XML和JSON進(jìn)行了比較，參考業(yè)界在實(shí)驗(yàn)室以及城市交通領(lǐng)域的經(jīng)驗(yàn)，數(shù)據(jù)處理效率主要考慮以下幾個(gè)因素：

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

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

(3)數(shù)據(jù)存儲(chǔ)和傳輸效率。數(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所示，即外部報(bào)文(對于傳統(tǒng)POS設(shè)備)—內(nèi)部報(bào)文(原第二至三層改為JSON格式)-數(shù)據(jù)庫層和文件層接口。對移動(dòng)支付設(shè)備甚至可以直接使用JSON格式從外部發(fā)送到系統(tǒng)內(nèi)部(通信層可支持TCP/HTTP/HTTPS，為了保證數(shù)據(jù)安全和快速路由，還需額外加報(bào)文頭、簽名和認(rèn)證信息)。項(xiàng)目組以該3層模型構(gòu)建新一代支付系統(tǒng)，并在關(guān)鍵模塊將JSON與XML進(jìn)行實(shí)證對比。

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

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

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

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

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

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

2.2測試說明

2.2.1測試環(huán)境

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

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

2.2.2測試流程及衡量指標(biāo)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4結(jié)論

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

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

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

參考文獻(xiàn)

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

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

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

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

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

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

中圖分類號(hào)：TP391

文獻(xiàn)標(biāo)識(shí)碼：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