隨着支付行業向各類便民賬單服務、金融服務類擴展，支付內核採用固定格式數據交換模型已不能適應快速靈活開發的需要。以JSON爲基礎構建精簡3層數據交換模型，並對JSON內存分配管理、鍵值使用進行優化，實現了支付系統靈活高效開發，同時系統性能更優，佔用內存資源更少，在實際應用中效果顯著。
：實時支付系統；第三方支付；數據交換模型；EJSON
隨着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的數據交換模型
基於以上分析，以JSON爲內部數據交換格式，將5層數據交換模型精簡爲3層，如圖1所示，即外部報文（對於傳統POS設備）—內部報文（原第二至三層改爲JSON格式）-數據庫層和文件層接口。對移動支付設備甚至可以直接使用JSON格式從外部發送到系統內部（通信層可支持TCP/HTTP/HTTPS，爲了保證數據安全和快速路由，還需額外加報文頭、簽名和認證信息）。項目組以該3層模型構建新一代支付系統，並在關鍵模塊將JSON與XML進行實證對比。
2基於JSON的數據交換模型實證分析
2.1支付系統總體架構圖
抽取支付系統關鍵模塊搭建驗證系統。如圖2所示，核心的金融交易流程處理採用異步模式，通信層（渠道、主機）、數據預處理層（組裝、橋接）、基礎服務層（加解密、超時控制）使用統一的平臺數據處理格式，模型進行接口改造後即可對不同數據格式進行性能對比測試。
測試以典型的POS繳費交易爲例，在交易處理的各個子系統和子程序中，對於內部數據格式的每個字段的處理總計“讀”約1 200次、“寫”約900次（具體次數因業務圖2支付系統架構圖流程有所不同），下面實證XML和JSON的性能。
2.2測試說明
2.2.1測試環境
軟件環境，數據庫：Oracle（Oracle11.2.0.2）；測試主機操作系統：AIX 6106 SP6；測試中間件：TUXEDO 10 R3，Weblogic 10.3.5。硬件設備由6臺IBM 小型機和2臺高端存儲組成，如表1所示。交易模擬：2臺POS仿真程序分別發起交易，2臺PC使用銀聯仿真器模擬銀聯和髮卡機構。表1測試硬件設備設備類別產品型號子系統用途及配置數量服務器P7系列
2.2.2測試流程及衡量指標
採用JSON作爲支付平臺統一數據處理格式，要求達到以下指標：TPS≥3 000 （TPS：每秒處理交易數），平均單筆交易耗時<1 s。
測試採用繳費交易，測試採用的庫函數版本爲：JSON：Jsonc 0.9；XML：Libxml2 DOM。
2.3測試數據
（1）測試中使用兩臺PC同時模擬終端發送數據，每個模擬程序均包括髮送和接收線程，發送頻率爲每隔700~650 μs發一筆，測試結果如表2和表3所示。
說明：JSON格式TPS能達到並穩定至3000， XML格式在TPS達到2 010時CPU已接近耗盡。
（2）按照200萬條交易流水對JSON和XML佔用空間測試，結果如表4所示。
說明：採用JSON格式存儲要節省23%。
3對於JSON的底層優化分析
大型支付系統對於性能要求高，特別是爲了應對突發性交易峯值的情況，項目組對於JSON底層進行分析和優化，並將其命名爲EJSON（Extend JSON）。
3.1對JSON域鍵名的規劃和長度壓縮
優化內容主要包括對JSON鍵值的存儲路徑進行規劃；對平臺常用詞彙的縮寫定義；對各模塊、組件中重合的JSON鍵名進行合併；對鍵名長度壓縮（將原來用下劃線分隔的鍵名定義方式改爲縮略詞與駝峯法相結合）。經優化後主要進程間通信的消息長度減少，消息的JSON序列化字符串長度從8 200 B降至5 700 B。
3.2JSON開源庫對內存的分配機制優化
JSON原內存分配機制如下：在最初初始化時申請16個鍵值空間（其中爲避免散列算法衝突，故僅使用其中的2/3），如發現空間不夠則再申請2倍空間，並將原有數據拷貝到新空間。這樣雖然能保證存儲空間有效利用，但增加系統開銷、降低處理性能。針對支付系統場景中JSON鍵值取值，改進JSON爲一次申請足夠內存塊，無需每次動態申請空間。此優化使單筆交易耗時減少了約8 ms。
4結論
（1）新數據交互模型是可行的。基於EJSON的方案大大提高了開發效率，報文自外部渠道轉換爲內部EJSON格式後，所有子系統、大部分子函數使用一個JSON對象作爲參數傳遞變量，新增的業務字段不影響原有函數和系統，大大降低了維護成本。新支付系統上小型項目生命週期大大縮短，平均爲49個自然日，其中用於軟件開發的時間僅佔25%，開發效率大大提高。
（2）EJSON 可以用於生產系統中。目前新一代支付系統已成功投產，系統採用了EJSON作爲數據處理格式，並取得良好效果。平均TPS最高能穩定至約3 180筆/秒，平臺在壓力控制500 TPS時的單筆交易平均處理時間可控制在40 ms以內，日交易量峯值達到1 402萬筆。
（3）後續改進方向。以消費者體驗爲中心，進一步提高移動支付設備接入的便利性和兼容性［6］，加強大數據服務、增值金融子系統支持，在以下方面進行改進：一是JSON將作爲數據總線成爲系統間交互的標準格式，以此爲基礎建立統一的JSON變量命名數據字典，對於自有系統命名內外一致，對於外部系統接入儘量只做一次內外轉換；二是研究支持JSON存儲的數據庫，以進一步改3層數據交互爲準兩層數據交互，以JSON鍵值爲數據存儲的元數據，進一步適應未來移動互聯網非結構化數據操作的需求。
參考文獻
［1］ 鍾巍,吳業福. 數據交換模型研究與實現［D］.武漢：武漢理工大學，2008.
［2］ 李聰. 基於XML的數據交換平臺的設計與實現［D］.武漢：武漢理工大學，2009.
［3］ 谷方舟,沈波. JSON數據交換格式在異構系統集成中的應用研究［J］.鐵路計算機應用，2012，21（2）：14.
［4］ 高靜,段會川. JSON數據傳輸效率研究［J］. 計算機工程與設計，2011，32（7）：22672269.
［5］ 邢四爲,宋傑.基於JSON的信息交互系統的研究與實現［D］. 合肥：安徽大學，2013
［6］ 呂光金,曹倩雯.基於TAMTRA的移動支付模式消費者接受影響因素研究［J］.微型機與應用,2015,34(8):8386.