于衛(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ù)交換模型,并對(duì)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
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í)對(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ù)庫層和文件層接口。項(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)[23],對(duì)軟件系統(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ù)交換層次對(duì)于提高效率是非常必要的。
根據(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)可讀性好。良好的可讀性有助于提高日志分析效率,對(duì)問題快速分析、生產(chǎn)維護(hù)尤為有利。
(3)冗余度低。低冗余則保證了對(duì)于報(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è)界對(duì)XML、JSON這些跨平臺(tái)的復(fù)雜數(shù)據(jù)格式的編碼、傳輸、解析效率進(jìn)行的實(shí)驗(yàn)[45],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)文格式,對(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ù)局部頁面刷新可以直接使用JSON,更為節(jié)省、用戶體驗(yàn)更為流暢[5]。
(2)數(shù)據(jù)組包和解包效率。數(shù)據(jù)組包(封裝)差別不大,數(shù)據(jù)解包(反序列化)開銷上JSON為XML的一半[45]。
(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)文(對(duì)于傳統(tǒng)POS設(shè)備)—內(nèi)部報(bào)文(原第二至三層改為JSON格式)-數(shù)據(jù)庫層和文件層接口。對(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ì)比測試。
測試以典型的POS繳費(fèi)交易為例,在交易處理的各個(gè)子系統(tǒng)和子程序中,對(duì)于內(nèi)部數(shù)據(jù)格式的每個(gè)字段的處理總計(jì)“讀”約1 200次、“寫”約900次(具體次數(shù)因業(yè)務(wù)圖2支付系統(tǒng)架構(gòu)圖流程有所不同),下面實(shí)證XML和JSON的性能。
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è)備設(shè)備類別產(chǎn)品型號(hào)子系統(tǒng)用途及配置數(shù)量服務(wù)器P7系列
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:Jsonc 0.9;XML:Libxml2 DOM。
2.3測試數(shù)據(jù)
?。?)測試中使用兩臺(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已接近耗盡。
?。?)按照200萬條交易流水對(duì)JSON和XML占用空間測試,結(jié)果如表4所示。
說明:采用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ī)劃和長度壓縮
優(yōu)化內(nèi)容主要包括對(duì)JSON鍵值的存儲(chǔ)路徑進(jìn)行規(guī)劃;對(duì)平臺(tái)常用詞匯的縮寫定義;對(duì)各模塊、組件中重合的JSON鍵名進(jìn)行合并;對(duì)鍵名長度壓縮(將原來用下劃線分隔的鍵名定義方式改為縮略詞與駝峰法相結(jié)合)。經(jīng)優(yōu)化后主要進(jìn)程間通信的消息長度減少,消息的JSON序列化字符串長度從8 200 B降至5 700 B。
3.2JSON開源庫對(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)開銷、降低處理性能。針對(duì)支付系統(tǒng)場景中JSON鍵值取值,改進(jìn)JSON為一次申請(qǐng)足夠內(nèi)存塊,無需每次動(dòng)態(tài)申請(qǐng)空間。此優(yōu)化使單筆交易耗時(shí)減少了約8 ms。
4結(jié)論
?。?)新數(shù)據(jù)交互模型是可行的?;贓JSON的方案大大提高了開發(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è)自然日,其中用于軟件開發(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萬筆。
?。?)后續(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ù)字典,對(duì)于自有系統(tǒng)命名內(nèi)外一致,對(duì)于外部系統(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)
?。?] 鐘巍,吳業(yè)福. 數(shù)據(jù)交換模型研究與實(shí)現(xiàn)[D].武漢:武漢理工大學(xué),2008.
?。?] 李聰. 基于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):14.
?。?] 高靜,段會(huì)川. JSON數(shù)據(jù)傳輸效率研究[J]. 計(jì)算機(jī)工程與設(shè)計(jì),2011,32(7):22672269.
?。?] 邢四為,宋杰.基于JSON的信息交互系統(tǒng)的研究與實(shí)現(xiàn)[D]. 合肥:安徽大學(xué),2013
?。?] 呂光金,曹倩雯.基于TAMTRA的移動(dòng)支付模式消費(fèi)者接受影響因素研究[J].微型機(jī)與應(yīng)用,2015,34(8):8386.