999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

基于JSON數據交換模型的實時支付系統設計和實現

2016-08-01 07:19:22于衛國陳澤瀛文黎明
網絡安全與數據管理 2016年12期

于衛國,陳澤瀛,文黎明

(銀聯商務有限公司 技術開發中心,上海 201203)

?

基于JSON數據交換模型的實時支付系統設計和實現

于衛國,陳澤瀛,文黎明

(銀聯商務有限公司 技術開發中心,上海 201203)

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

關鍵詞:實時支付系統;第三方支付;數據交換模型;EJSON

引用格式:于衛國,陳澤瀛,文黎明. 基于JSON數據交換模型的實時支付系統設計和實現[J].微型機與應用,2016,35(12):84-86,89.

0引言

隨著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)[2-3],對軟件系統內部數據交互關注較少。以支付行業為例,交易從外部的終端或移動設備發起,通過接入前置發到支付核心系統已經經過了兩次數據轉換,而在支付系統內部還有5層數據交換。因此統一支付系統外圍和內部數據交互格式,同時減少支付系統數據交換層次對于提高效率是非常必要的。

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

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

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

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

(4)通用性。通用性降低了系統間連接的成本,有多種開發語言支持數據交換格式,降低開發成本,提高系統穩定性。

1.2數據交互格式

以往支付核心系統大都采用固定格式,而移動互聯網業務使用XML和JSON較多。根據業界對XML、JSON這些跨平臺的復雜數據格式的編碼、傳輸、解析效率進行的實驗[4-5],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的一半[4-5]。

(3)數據存儲和傳輸效率。數據傳輸上的開銷,在一般的應用場景中JSON比XML節省30%~36%[4]。

1.3基于JSON的數據交換模型

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

圖1 基于JSON支付系統三層交換模型

2基于JSON的數據交換模型實證分析

2.1支付系統總體架構圖

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

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

圖2 支付系統架構圖

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 測試硬件設備

2.2.2測試流程及衡量指標

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

測試采用繳費交易,測試采用的庫函數版本為:JSON:Json-c 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)。

表2 使用JSON作為內部格式時系統資源和性能

表3 使用XML作為內部格式時系統資源和性能

表4 交易實際占用數據庫空間分析

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):1-4.

[4] 高靜,段會川. JSON數據傳輸效率研究[J]. 計算機工程與設計,2011,32(7):2267-2269.

[5] 邢四為,宋杰.基于JSON的信息交互系統的研究與實現[D]. 合肥:安徽大學,2013

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

中圖分類號:TP391

文獻標識碼:A

DOI:10.19358/j.issn.1674- 7720.2016.12.027

(收稿日期:2016-02-18)

作者簡介:

于衛國(1970-),男,碩士,工程師,主要研究方向:第三方支付、軟件工程、數據安全。

陳澤瀛(1965-),男,學士,工程師,主要研究方向:第三方支付、軟件工程。

文黎明(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

主站蜘蛛池模板: 国产经典三级在线| AV老司机AV天堂| 久久精品国产电影| 欧美色亚洲| 久久午夜夜伦鲁鲁片无码免费 | 国产麻豆福利av在线播放| 无码又爽又刺激的高潮视频| 国产av一码二码三码无码| 精品少妇人妻av无码久久| 伊人成人在线| 免费看一级毛片波多结衣| 伊人久综合| 国产99欧美精品久久精品久久| 日韩国产无码一区| 五月激激激综合网色播免费| 美女国产在线| 五月丁香在线视频| 亚洲丝袜第一页| 国产H片无码不卡在线视频| 国产欧美日韩专区发布| 国产精品毛片一区视频播| 国产自无码视频在线观看| a色毛片免费视频| 麻豆精品久久久久久久99蜜桃| 日韩毛片在线播放| 日韩精品亚洲一区中文字幕| 福利国产微拍广场一区视频在线| 欧美日韩综合网| 国产探花在线视频| lhav亚洲精品| 91国内视频在线观看| 成人精品区| 久久精品一品道久久精品| 国产经典三级在线| 99九九成人免费视频精品| 91精品在线视频观看| 国产亚洲欧美日韩在线一区| 福利在线不卡一区| 无码国产偷倩在线播放老年人 | 激情亚洲天堂| 国产综合精品一区二区| 日韩无码真实干出血视频| 狠狠色成人综合首页| 亚洲天堂伊人| 亚洲国产精品无码久久一线| 好紧太爽了视频免费无码| 天天综合网亚洲网站| 黄色免费在线网址| 毛片大全免费观看| 91成人在线观看视频| 久久99久久无码毛片一区二区 | 91久久国产热精品免费| 国产精品三区四区| 日韩福利在线视频| 久久精品嫩草研究院| 日韩无码真实干出血视频| 国产亚洲视频中文字幕视频| 黄片一区二区三区| 国产在线观看第二页| 久夜色精品国产噜噜| 综合天天色| 国产精品国产三级国产专业不| 老司机午夜精品网站在线观看| 日韩 欧美 国产 精品 综合| 亚洲丝袜第一页| 国产美女主播一级成人毛片| 亚洲精品自在线拍| 日本欧美午夜| 91福利国产成人精品导航| 国产亚洲精品资源在线26u| 国产xxxxx免费视频| 亚洲乱码精品久久久久..| 欧美区国产区| 麻豆精品在线视频| 日韩中文欧美| 日本AⅤ精品一区二区三区日| 亚洲欧洲日韩久久狠狠爱| 在线无码av一区二区三区| 精品一区二区三区无码视频无码| 国产精品私拍99pans大尺度 | 国产精品手机视频一区二区| 成年片色大黄全免费网站久久|