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

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

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

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

0引言

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

1現(xiàn)狀分析

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

　　1.1數(shù)據交換模型

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

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

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

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

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

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

　　1.2數(shù)據交互格式

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

　　1.2.1固定格式

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

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

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

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

　　1.2.2XML

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

　　1.2.3JSON

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

　　1.2.4分析

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

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

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

　　(3)數(shù)據存儲和傳輸效率。數(shù)據傳輸上的開銷，在一般的應用場景中JSON比XML節(jié)省30%~36%［4］。

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

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

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

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

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

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

　　2.2測試說明

　　2.2.1測試環(huán)境

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

　　2.2.2測試流程及衡量指標

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

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

　　2.3測試數(shù)據

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

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

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

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

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

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

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

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

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

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

4結論

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

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

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

參考文獻

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

　?。?］ 李聰. 基于XML的數(shù)據交換平臺的設計與實現(xiàn)［D］.武漢：武漢理工大學，2009.

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

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

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

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