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

　?。ㄣy聯(lián)商務(wù)有限公司 技術(shù)開(kāi)發(fā)中心，上海 201203）

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

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

0引言

　　隨著2011年5月財(cái)付通、支付寶和銀聯(lián)商務(wù)等27家企業(yè)獲得人行第三方支付牌照，第三方支付市場(chǎng)發(fā)展迅速，截至2015年底共有269家企業(yè)獲得支付牌照，全國(guó)銀行卡聯(lián)網(wǎng)商戶(hù)1 670萬(wàn)戶(hù)，聯(lián)網(wǎng)POS機(jī)具2 282.1萬(wàn)臺(tái)，金額49.5萬(wàn)億元。行業(yè)呈現(xiàn)以下特點(diǎn)：（1）在終端上從傳統(tǒng)線(xiàn)下POS收單向互聯(lián)網(wǎng)、電視、移動(dòng)設(shè)備等拓展；（2）在內(nèi)容上由銀行卡消費(fèi)向各類(lèi)便民服務(wù)類(lèi)（水電煤繳費(fèi)、充值、還款）、準(zhǔn)金融服務(wù)類(lèi)（保險(xiǎn)、稅務(wù)）、金融服務(wù)類(lèi)（基金、理財(cái)、小額信貸、保理）業(yè)務(wù)拓展，業(yè)內(nèi)將之統(tǒng)稱(chēng)為增值業(yè)務(wù)。增值業(yè)務(wù)已成為第三方支付行業(yè)的發(fā)展重點(diǎn)，在要求核心實(shí)時(shí)支付系統(tǒng)交易可靠、高效處理的同時(shí)，還要求新業(yè)務(wù)快速開(kāi)發(fā)上線(xiàn)。大型實(shí)時(shí)支付系統(tǒng)交易種類(lèi)多、功能復(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í)對(duì)數(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)、銀行、外卡組織等支付提供方，對(duì)于增值應(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ù)庫(kù)層和文件層接口。項(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］，對(duì)軟件系統(tǒng)內(nèi)部數(shù)據(jù)交互關(guān)注較少。以支付行業(yè)為例，交易從外部的終端或移動(dòng)設(shè)備發(fā)起，通過(guò)接入前置發(fā)到支付核心系統(tǒng)已經(jīng)經(jīng)過(guò)了兩次數(shù)據(jù)轉(zhuǎn)換，而在支付系統(tǒng)內(nèi)部還有5層數(shù)據(jù)交換。因此統(tǒng)一支付系統(tǒng)外圍和內(nèi)部數(shù)據(jù)交互格式，同時(shí)減少支付系統(tǒng)數(shù)據(jù)交換層次對(duì)于提高效率是非常必要的。

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

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

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

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

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

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

　　以往支付核心系統(tǒng)大都采用固定格式，而移動(dòng)互聯(lián)網(wǎng)業(yè)務(wù)使用XML和JSON較多。根據(jù)業(yè)界對(duì)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開(kāi)發(fā)居多，內(nèi)部數(shù)據(jù)交換采用固定格式（比如C STRUCT)，缺陷如下：

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

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

　　固定格式數(shù)據(jù)交互不能滿(mǎn)足快速開(kāi)發(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)中要解決快速解析問(wèn)題。

　　1.2.3JSON

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

　　1.2.4分析

　　從簡(jiǎn)化數(shù)據(jù)交換模型角度，項(xiàng)目組排除了固定報(bào)文格式，對(duì)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ù)局部頁(yè)面刷新可以直接使用JSON，更為節(jié)省、用戶(hù)體驗(yàn)更為流暢［5］。

　　(2)數(shù)據(jù)組包和解包效率。數(shù)據(jù)組包（封裝）差別不大，數(shù)據(jù)解包（反序列化）開(kāi)銷(xiāo)上JSON為XML的一半［45］。

　　(3)數(shù)據(jù)存儲(chǔ)和傳輸效率。數(shù)據(jù)傳輸上的開(kāi)銷(xiāo)，在一般的應(yīng)用場(chǎng)景中JSON比XML節(jié)省30%~36%［4］。

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

　　基于以上分析，以JSON為內(nèi)部數(shù)據(jù)交換格式，將5層數(shù)據(jù)交換模型精簡(jiǎn)為3層，如圖1所示，即外部報(bào)文（對(duì)于傳統(tǒng)POS設(shè)備）—內(nèi)部報(bào)文（原第二至三層改為JSON格式）-數(shù)據(jù)庫(kù)層和文件層接口。對(duì)移動(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í)證對(duì)比?！?/p>

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)行接口改造后即可對(duì)不同數(shù)據(jù)格式進(jìn)行性能對(duì)比測(cè)試。

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

　　2.2測(cè)試說(shuō)明

　　2.2.1測(cè)試環(huán)境

　　軟件環(huán)境，數(shù)據(jù)庫(kù)：Oracle（Oracle11.2.0.2）；測(cè)試主機(jī)操作系統(tǒng)：AIX 6106 SP6；測(cè)試中間件：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測(cè)試硬件設(shè)備設(shè)備類(lèi)別產(chǎn)品型號(hào)子系統(tǒng)用途及配置數(shù)量服務(wù)器P7系列　　

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

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

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

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

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

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

　?。?）按照200萬(wàn)條交易流水對(duì)JSON和XML占用空間測(cè)試，結(jié)果如表4所示。

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

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

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

　　3.1對(duì)JSON域鍵名的規(guī)劃和長(zhǎng)度壓縮

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

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

　　JSON原內(nèi)存分配機(jī)制如下：在最初初始化時(shí)申請(qǐng)16個(gè)鍵值空間（其中為避免散列算法沖突，故僅使用其中的2/3），如發(fā)現(xiàn)空間不夠則再申請(qǐng)2倍空間，并將原有數(shù)據(jù)拷貝到新空間。這樣雖然能保證存儲(chǔ)空間有效利用，但增加系統(tǒng)開(kāi)銷(xiāo)、降低處理性能。針對(duì)支付系統(tǒng)場(chǎng)景中JSON鍵值取值，改進(jìn)JSON為一次申請(qǐng)足夠內(nèi)存塊，無(wú)需每次動(dòng)態(tài)申請(qǐng)空間。此優(yōu)化使單筆交易耗時(shí)減少了約8 ms。

4結(jié)論

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

　?。?）后續(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ù)總線(xiàn)成為系統(tǒng)間交互的標(biāo)準(zhǔn)格式，以此為基礎(chǔ)建立統(tǒng)一的JSON變量命名數(shù)據(jù)字典，對(duì)于自有系統(tǒng)命名內(nèi)外一致，對(duì)于外部系統(tǒng)接入盡量只做一次內(nèi)外轉(zhuǎn)換；二是研究支持JSON存儲(chǔ)的數(shù)據(jù)庫(kù)，以進(jìn)一步改3層數(shù)據(jù)交互為準(zhǔn)兩層數(shù)據(jù)交互，以JSON鍵值為數(shù)據(jù)存儲(chǔ)的元數(shù)據(jù)，進(jìn)一步適應(yīng)未來(lái)移動(dòng)互聯(lián)網(wǎng)非結(jié)構(gòu)化數(shù)據(jù)操作的需求。

參考文獻(xiàn)

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

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

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

　?。?］ 高靜,段會(huì)川. JSON數(shù)據(jù)傳輸效率研究［J］. 計(jì)算機(jī)工程與設(shè)計(jì)，2011，32（7）：22672269.

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

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