主管 ：上海證券交易所

主辦 ：上海證券交易所

總編 ：邱勇、蔡建春

副總編 ：王泊

執(zhí)行總編 ：唐憶

責(zé)任編輯 ：徐廣斌、徐丹、陸偉、王昕、黃淦

上海市楊高南路 388 號

郵編 ：200127

電話 ：021-68607129，021-68607131

傳真 ：021-68813188

投稿郵箱 ：ftt.editor@sse.com.cn

內(nèi)部資料 2022 年第四期（總第 51 期）

準(zhǔn)印證號 ：滬（K）0671

NO.4

交易技術(shù)前沿THE FORELAND OF TRADING TECHNOLOGY

資本市場在現(xiàn)代經(jīng)濟活動的重要作用日益凸顯，交易系統(tǒng)作為資本市場運作和發(fā)展的直接承載體 ,

對于維護市場安全穩(wěn)定高效運行發(fā)揮著至關(guān)重要的作用。開展交易系統(tǒng)核心技術(shù)研究 , 有利于行業(yè)機

構(gòu)改良自身技術(shù)、降低運行風(fēng)險 , 亦有利于促進我國資本市場國際競爭力和影響力的提升。本期《交

易技術(shù)前沿》以“交易系統(tǒng)”為主題，收錄行業(yè)交易系統(tǒng)研究及前沿技術(shù)探索等方面的優(yōu)秀文章，其中。

《異構(gòu)交易系統(tǒng)介紹》展現(xiàn)了中金所自主研發(fā)異構(gòu)交易平臺的系統(tǒng)架構(gòu)和技術(shù)亮點，該平臺借鑒

了航空航天業(yè)在軟件可靠性上的最佳實踐，旨在降低交易系統(tǒng)故障率、提高容災(zāi)容錯性。

《可復(fù)用數(shù)據(jù)處理框架在證券數(shù)據(jù)處理中的探索和實踐》在主流的數(shù)據(jù)處理框架基礎(chǔ)上，開發(fā)了

批處理系統(tǒng)的處理框架和元數(shù)據(jù)管理模式，在提高數(shù)據(jù)維護質(zhì)量的同時降低數(shù)據(jù)血緣關(guān)系維護難度。

目前該開發(fā)模式已運用在創(chuàng)新業(yè)務(wù)和交易系統(tǒng)的實際研發(fā)中。

《海通證券兼容多基礎(chǔ)平臺的新一代核心交易系統(tǒng)運營管理平臺設(shè)計與實現(xiàn)》采用全面自主可控

的鏈路技術(shù)，實現(xiàn)智能路由識別、統(tǒng)一路由管理，在保證平臺兼容性的前提下，有效提升核心交易系

統(tǒng)運營管理效率并降低運營管理成本。

《機構(gòu)交易接入中臺建設(shè)實踐》聚焦于屏蔽核心交易系統(tǒng)差異性的自主可控交易接入中臺，為各

類交易終端接入 OST 極速交易系統(tǒng)、第三方快速交易系統(tǒng)等打下基礎(chǔ)。

《基于證通云的數(shù)據(jù)跨境流動管理方案的研究與實現(xiàn)》旨在通過綜合運用數(shù)據(jù)加密、權(quán)限控制、

操作留痕等技術(shù)手段，在現(xiàn)有政策環(huán)境下，提出一種基于“證通云”的數(shù)據(jù)跨境流動管理解決方案。

《交易技術(shù)前沿》編輯部

2023 年 3 月 23 日

篇首語

本期熱點

探索與應(yīng)用

1 異構(gòu)交易系統(tǒng)介紹 / 應(yīng)國力、仇沂、李雯、王維

2 海通證券兼容多基礎(chǔ)平臺的新一代核心交易系統(tǒng)運營管理平臺設(shè)計與實現(xiàn) / 霍軼倫、周尤珠、

陸頌華、王東、袁康

3 機構(gòu)交易接入中臺建設(shè)實踐 / 胡長春、單興邦、高春蕾、李沁、黃賽、何少鋒

4 可復(fù)用數(shù)據(jù)處理框架在證券數(shù)據(jù)處理中的探索和實踐 / 蔡文博、張舒、鮑倩倩、杜小靜、胡紅星

5 基于 oneAPI 的金融衍生品定價加速 / 馬輝、鄒經(jīng)緯、白君潔、鐘浪輝、韓大偉、黃琦、余洋洋、

李彪

4

11

17

24

34

目錄

信息資訊采擷

監(jiān)管科技全球追蹤 98

6 證券運維系統(tǒng)自動化代理平臺建設(shè)實踐 / 肖鋼、徐志彬、柴晨、王軍、喻文強、張皓凌

7 基于上證云的數(shù)據(jù)跨境流動管理方案研究與實現(xiàn) / 操浩東、劉政言、何雷

8 安信證券網(wǎng)絡(luò)系統(tǒng)自動化運維平臺建設(shè)實踐 / 梁德漢、何洲星、武孟軍

9 興業(yè)證券應(yīng)用性能監(jiān)控系統(tǒng)建設(shè)思路、方法和實踐 / 劉洋、石良生、楊洋

10 一種可擴展的多因素訪問控制方法及實踐 / 姜洪濤、宮珂、于慧

11 證券公司智慧營銷與服務(wù)平臺建設(shè) / 潘建東、徐政鈞、劉逸雄、谷航宇

12 證券行業(yè)網(wǎng)站智能數(shù)據(jù)搜索服務(wù)的研究與實踐 / 季曉娟、王中澎、李煒、趙冬昊、王漢杰、李蓉

13 關(guān)于 ION GROUP 遭遇勒索病毒攻擊事件的分析思考報告 / 張濤、盧雅哲、徐廣斌、謝毅

45

51

57

71

79

85

91

94

本期熱點

1 異構(gòu)交易系統(tǒng)介紹

2 海通證券兼容多基礎(chǔ)平臺的新一代核心交易系統(tǒng)運營

管理平臺設(shè)計與實現(xiàn)

3 機構(gòu)交易接入中臺建設(shè)實踐

4 可復(fù)用數(shù)據(jù)處理框架在證券數(shù)據(jù)處理中的探索和實踐

5 基于 oneAPI 的金融衍生品定價加速

本期熱點

異構(gòu)交易系統(tǒng)介紹

應(yīng)國力、仇沂、李雯、王維 / 上海金融期貨信息技術(shù)有限公司 交易系統(tǒng)部 上海 200127

E-mail ：yinggl@cffex.com.cn

4

1、關(guān)鍵技術(shù)問題

如何提升軟件可靠性 ：軟件可靠性是軟件質(zhì)

量體系中最重要的衡量指標(biāo)之一，根據(jù)軟件可靠

性理論，缺陷是無法完全窮舉羅列的，無法完全

避免。中金所已具備完備的硬件故障恢復(fù)體系，

應(yīng)對軟件故障也有較豐富的應(yīng)對手段，如圖 1 所

示，但面對其他軟件邏輯缺陷或架構(gòu)級別嚴(yán)重缺

近年來，在全球經(jīng)濟復(fù)蘇疲軟疊加疫情沖擊的背景下，全球交易所核心系統(tǒng)穩(wěn)定性

面臨較大考驗，軟件故障頻發(fā)。針對軟件缺陷類故障無有效應(yīng)對方式的現(xiàn)狀，中國金融期

貨交易所（以下簡稱為“中金所”）自主設(shè)計研發(fā)打造了異構(gòu)交易系統(tǒng)，該系統(tǒng)是一套軟

件架構(gòu)與主交易相異的容錯備系統(tǒng)，通過多版本容錯技術(shù)、維護多個異構(gòu)交易系統(tǒng)來降低

服務(wù)的整體故障率，在主交易系統(tǒng)發(fā)生嚴(yán)重軟件缺陷、且已有的應(yīng)急保障措施均失效的情

況下，可嘗試快速接管，持續(xù)為市場提供基本的交易及行情服務(wù)。

!\"#$%&'(

應(yīng)國力 1

，仇沂 1

，李雯 1

，王維 1

1上海金融期貨信息技術(shù)有限公司 交易系統(tǒng)部 上海 200127

E-mail ：yinggl@cffex.com.cn

摘 要：近年來，在全球經(jīng)濟復(fù)蘇疲軟疊加疫情沖擊的背景下，全球交易所核心系統(tǒng)穩(wěn)定性面臨較大考驗，

軟件故障頻發(fā)。針對軟件缺陷類故障無有效應(yīng)對方式的現(xiàn)狀，中國金融期貨交易所（以下簡稱為“中金所”）

自主設(shè)計研發(fā)打造了異構(gòu)交易系統(tǒng)，該系統(tǒng)是一套軟件架構(gòu)與主交易相異的容錯備系統(tǒng)，通過多版本容錯

技術(shù)、維護多個異構(gòu)交易系統(tǒng)來降低服務(wù)的整體故障率，在主交易系統(tǒng)發(fā)生嚴(yán)重軟件缺陷、且已有的應(yīng)急

保障措施均失效的情況下，可嘗試快速接管，持續(xù)為市場提供基本的交易及行情服務(wù)。

關(guān)鍵詞：異構(gòu)；交易系統(tǒng)；軟件故障；業(yè)務(wù)連續(xù)性

1 )*+,-.

如何提升軟件可靠性：軟件可靠性是軟件質(zhì)量體系中最重要的衡量指標(biāo)之一，根據(jù)軟件可靠性理論，

缺陷是無法完全窮舉羅列的，無法完全避免。中金所已具備完備的硬件故障恢復(fù)體系，應(yīng)對軟件故障也有

較豐富的應(yīng)對手段，如圖 1 所示，但面對其他軟件邏輯缺陷或架構(gòu)級別嚴(yán)重缺陷類故障仍缺乏解決方案。

運

維

類

事

故

基礎(chǔ)設(shè)施類

事故

軟件類事故

應(yīng)用層

架構(gòu)層

兩套實時

監(jiān)控軟件

應(yīng)急并行

排障環(huán)境

每15分鐘

人工巡檢

現(xiàn)場應(yīng)急

處理小組

突發(fā)事件

應(yīng)急預(yù)案

IT 災(zāi)難

恢復(fù)計劃

業(yè)務(wù)持續(xù)

性計劃

硬件單點

故障

硬件大面

積故障

軟件單

指令故障

其他軟件

邏輯缺陷

軟件主備切換

硬件雙機冗余

同城災(zāi)備切換

異地遠備切換

應(yīng)用自動避障

跳過1條致命指令

?

圖 1 核心系統(tǒng)事故應(yīng)急方案

極簡架構(gòu)下的高性能：交易核心系統(tǒng)對性能容量有著極致的要求。建設(shè)一套全新的系統(tǒng)需要較大資源

投入，一是研發(fā)階段的成本投入，需要實現(xiàn)所有線上業(yè)務(wù)功能；二是運維階段的成本投入，需要同時維護

兩套線上系統(tǒng)。因此，在資源極簡的前提下，如何實現(xiàn)高性能目標(biāo)也是難點之一。

圖 1 ：核心系統(tǒng)事故應(yīng)急方案

交易技術(shù)前沿

5

陷類故障仍缺乏解決方案。

極簡架構(gòu)下的高性能 ：交易核心系統(tǒng)對性能

容量有著極致的要求。建設(shè)一套全新的系統(tǒng)需要

較大資源投入，一是研發(fā)階段的成本投入，需要

實現(xiàn)所有線上業(yè)務(wù)功能 ；二是運維階段的成本投

入，需要同時維護兩套線上系統(tǒng)。因此，在資源

極簡的前提下，如何實現(xiàn)高性能目標(biāo)也是難點之

一。

切換影響最小化 ：當(dāng)主系統(tǒng)發(fā)生軟件故障切

換到異構(gòu)交易系統(tǒng)時，需要盡可能降低內(nèi)外部影

響。一方面是切換效率要高，對市場無影響，會

員端需要做到無感切換 ；另一方面是對交易所內(nèi)

部上下游系統(tǒng)無影響，需要做到切換后周邊各業(yè)

務(wù)系統(tǒng)持續(xù)平穩(wěn)運行。

數(shù)據(jù)一致性：異構(gòu)系統(tǒng)與主系統(tǒng)架構(gòu)不一致，

存在業(yè)務(wù)不一致的風(fēng)險，如何保證異構(gòu)系統(tǒng)接管

后仍能正確運行不出錯，也是關(guān)鍵之一。

“卡脖子”問題仍需攻關(guān) ：面對嚴(yán)峻多變的

國際形勢，提升交易所技術(shù)的安全自主可控性更

是迫在眉睫。打造核心技術(shù)的安全自主可控體系、

探索交易所核心系統(tǒng)在自主可控環(huán)境落地，才能

在面對不同局勢時從容不迫。

2、異構(gòu)交易系統(tǒng)架構(gòu)介紹

異構(gòu)交易系統(tǒng)內(nèi)部異構(gòu)于主交易系統(tǒng)，采用

了以高性能通信組件為連接件、多級交易流水線

為中心、內(nèi)置查詢業(yè)務(wù)和行情生成的架構(gòu)，外部

復(fù)用了主系統(tǒng)前置和外圍系統(tǒng)。異構(gòu)交易系統(tǒng)總

體架構(gòu)如圖 2 所示。

高性能通信組件是中金所在多年來交易系統(tǒng)

研發(fā)的基礎(chǔ)上，對底層開發(fā)框架及通用功能組件

進行分離封裝，形成的一套功能豐富的開發(fā)框架。

開發(fā)框架由 C++ 實現(xiàn)，包含了事件處理框架、高

性能通信、可靠多播、高級容錯組件等。

多級流水線模型是異構(gòu)交易系統(tǒng)的消息處理

架構(gòu)，異構(gòu)于主交易的業(yè)務(wù)單線程處理，后續(xù)章

節(jié)中將詳細(xì)介紹。

內(nèi)置查詢業(yè)務(wù)和行情生成是考慮到查詢模

塊和行情生成模塊的輕量性及其與交易行為的耦

合，將這兩個模塊納入異構(gòu)交易系統(tǒng)核心進程中，

可降低異構(gòu)系統(tǒng)運維的復(fù)雜度。

復(fù)用主交易前置和外圍接口模塊可以保證在

切換時省去反演恢復(fù)數(shù)據(jù)的時間，提高切換效率，

并且可維持切換后對外服務(wù)地址不變，降低切換

2 !\"#$%&/\"'(

異構(gòu)交易系統(tǒng)內(nèi)部異構(gòu)于主交易系統(tǒng)，采用了以高性能通信組件為連接件、多級交易流水線為中心、

內(nèi)置查詢業(yè)務(wù)和行情生成的架構(gòu)，外部復(fù)用了主系統(tǒng)前置和外圍系統(tǒng)。異構(gòu)交易系統(tǒng)總體架構(gòu)如圖 2 所示：

交易前置 交易前置 交易前置

上行流 行情流

結(jié)果流

主交易系

統(tǒng)

會員柜臺系統(tǒng)

FibPro

xy

生產(chǎn)結(jié)果流

切換指令

初始化 上場

異構(gòu)交易核心

行情生成

交易前置 交易前置 行情前置

查詢

交易流水線

查詢請求

查詢應(yīng)答

圖 2 異構(gòu)交易系統(tǒng)架構(gòu)

高性能通信組件是中金所在多年來交易系統(tǒng)研發(fā)的基礎(chǔ)上，對底層開發(fā)框架及通用功能組件進行分離

封裝，形成的一套功能豐富的開發(fā)框架。開發(fā)框架由 C++實現(xiàn)，包含了事件處理框架、高性能通信、可靠

多播、高級容錯組件等。

圖 2 ：異構(gòu)交易系統(tǒng)架構(gòu)

本期熱點

6

對會員端及交易所內(nèi)部上下游系統(tǒng)的影響。

從運行方式與數(shù)據(jù)流向上來看，異構(gòu)交易系

統(tǒng)日常作備并行運行，實時訂閱主系統(tǒng)撮合結(jié)果

流水，實時恢復(fù)最小完整狀態(tài)集。當(dāng)主交易系統(tǒng)

出現(xiàn)故障切換至異構(gòu)交易系統(tǒng)時，開始訂閱外部

前置及上場消息繼續(xù)進行交易業(yè)務(wù)。

3、系統(tǒng)關(guān)鍵技術(shù)

3.1 運行模式及流水復(fù)制恢復(fù)技術(shù)

異構(gòu)交易系統(tǒng)支持兩種運行模式 ：撮合模式

和恢復(fù)模式。運行模式屬于架構(gòu)層的概念，它決

定了系統(tǒng)的訂閱關(guān)系、流持久化邏輯等。詳細(xì)介

紹如下 ：

撮合模式 ：異構(gòu)交易系統(tǒng)做主系統(tǒng)運行，從

上場模塊進行初始化，從交易前置接收外部指令

（如報單、報價等）。業(yè)務(wù)層進行撮合操作，撮合

結(jié)果直接寫入結(jié)果流。此模式下與主系統(tǒng)運行模

式無異，當(dāng)主系統(tǒng)故障切換至異構(gòu)系統(tǒng)時，異構(gòu)

系統(tǒng)以此模式運行。

恢復(fù)模式 ：異構(gòu)交易系統(tǒng)作為備系統(tǒng)運行，

此時作為主系統(tǒng)的并行系統(tǒng)，將訂閱主中心發(fā)來

的全量流。此模式下應(yīng)用了流水復(fù)制恢復(fù)技術(shù)，

只處理結(jié)果消息，用來復(fù)制主中心的撮合結(jié)果，

恢復(fù)構(gòu)建對應(yīng)業(yè)務(wù)域狀態(tài)、內(nèi)存表以及相關(guān)變量

的狀態(tài)，如資金占用、倉位統(tǒng)計、活躍訂單簿等，

保證異構(gòu)一致性。收到切換指令后，異構(gòu)交易系

統(tǒng)會切換為主中心，發(fā)生訂閱關(guān)系和業(yè)務(wù)層操作

模式的變化 ：取消訂閱主中心結(jié)果流，轉(zhuǎn)向訂閱

上場模塊消息，開始接收前置的外部消息，業(yè)務(wù)

層操作由流水復(fù)制恢復(fù)切換為撮合。線上運行默

認(rèn)為此模式。

3.2 基于聚合根的多層領(lǐng)域模型

通過抽取基于交易參與者 + 合約的最細(xì)粒度

數(shù)據(jù)聚合根，將不同業(yè)務(wù)域數(shù)據(jù)按層級進行掛載，

實現(xiàn)數(shù)據(jù)訪問的簡化和高效率，對原主交易系統(tǒng)

的業(yè)務(wù)模型進行了完全的重構(gòu)，通過異構(gòu)避免嚴(yán)

重故障，提升了軟件可靠性。

全新的領(lǐng)域服務(wù)校驗?zāi)Ｐ蛢?nèi)部通過業(yè)務(wù)功

能、領(lǐng)域模型、內(nèi)存數(shù)據(jù)三層進行劃分，配合數(shù)

據(jù)聚合根，業(yè)務(wù)邏輯不再關(guān)心數(shù)據(jù)存取訪問，模

型抽象程度更高。同時，領(lǐng)域服務(wù)不依賴外部系

統(tǒng)、不保存狀態(tài)，所以更容易進行單元測試，這

對于提高系統(tǒng)的質(zhì)量是非常有幫助的。

3.3 高性能多級流水線模型

異構(gòu)交易系統(tǒng)的消息傳遞采用多級流水線模

型，將業(yè)務(wù)數(shù)據(jù)處理流程在邏輯上劃分成相互獨

立的若干部分，每個部分由一個線程驅(qū)動，線程

之間共享消息隊列。

從總體業(yè)務(wù)模型的角度上來看，如圖 3 所示，

相比于主交易系統(tǒng)的訂閱 -> 單線程撮合 -> 發(fā)布

的結(jié)構(gòu)，異構(gòu)交易系統(tǒng)將撮合線程按延時占比拆

分為撮合前、撮合、撮合后三部分異步處理消息。

在同一測試環(huán)境進行測試，多級流水線性能

提升顯著，具體如表 1 所示。引入撮合流水線后，

系統(tǒng)吞吐能力顯著提升。由于架構(gòu)上進行了本地

持久化的原因，延時略微增加，但仍在合理范圍

以內(nèi)。

從技術(shù)模型實現(xiàn)來看，異構(gòu)交易系統(tǒng)的業(yè)務(wù)

處理部分由四個線程驅(qū)動，分別為訂閱消息加工

認(rèn)為此模式。

3.2 :;<=>?@ABC2D

通過抽取基于交易參與者+合約的最細(xì)粒度數(shù)據(jù)聚合根，將不同業(yè)務(wù)域數(shù)據(jù)按層級進行掛載，實現(xiàn)數(shù)

據(jù)訪問的簡化和高效率，對原主交易系統(tǒng)的業(yè)務(wù)模型進行了完全的重構(gòu)，通過異構(gòu)避免嚴(yán)重故障，提升了

軟件可靠性。

全新的領(lǐng)域服務(wù)校驗?zāi)Ｐ蛢?nèi)部通過業(yè)務(wù)功能、領(lǐng)域模型、內(nèi)存數(shù)據(jù)三層進行劃分，配合數(shù)據(jù)聚合根，

業(yè)務(wù)邏輯不再關(guān)心數(shù)據(jù)存取訪問，模型抽象程度更高。同時，領(lǐng)域服務(wù)不依賴外部系統(tǒng)、不保存狀態(tài)，所

以更容易進行單元測試，這對于提高系統(tǒng)的質(zhì)量是非常有幫助的。

3.3 EFG@H56I2D

異構(gòu)交易系統(tǒng)的消息傳遞采用多級流水線模型，將業(yè)務(wù)數(shù)據(jù)處理流程在邏輯上劃分成相互獨立的若干

部分，每個部分由一個線程驅(qū)動，線程之間共享消息隊列。

從總體業(yè)務(wù)模型的角度上來看，如圖 3 所示，相比于主交易系統(tǒng)的訂閱->單線程撮合->發(fā)布的結(jié)構(gòu)，

異構(gòu)交易系統(tǒng)將撮合線程按延時占比拆分為撮合前、撮合、撮合后三部分異步處理消息。

訂閱 撮合 發(fā)布 訂

閱

撮

合

前

撮

合

撮

合

后

共享動態(tài)消息隊列

發(fā)

布

圖 3 交易系統(tǒng)多級流水線業(yè)務(wù)模型

在同一測試環(huán)境進行測試，多級流水線性能提升顯著，具體如表 1 所示。引入撮合流水線后，系統(tǒng)吞

吐能力顯著提升。由于架構(gòu)上進行了本地持久化的原因，延時略微增加，但仍在合理范圍以內(nèi)。

表 1 異構(gòu)交易性能比對表

系統(tǒng)處理延時吞吐能力圖 3 ：交易系統(tǒng)多級流水線業(yè)務(wù)模型

交易技術(shù)前沿

7

線程、撮合前檢查線程、撮合及撮合后處理線程、

發(fā)布消息處理線程，與圖 4 中線程一一對應(yīng)。其

中，訂閱消息加工線程將異構(gòu)交易上行的消息包

進行解包，生成消息隊列的包頭以及流水線的第

零級消息，消息隊列包頭是多個線程訪問消息隊

列的關(guān)鍵，控制著線程對同一個消息的讀寫權(quán)限，

第零級消息通常是上行數(shù)據(jù)包的原始數(shù)據(jù)，也就

是輸入的請求包 ；撮合前檢查線程消費消息隊列

包頭和第零級流水線的消息，同時生成第一級流

水線的消息 ；撮合及撮合后處理線程消費消息隊

列包頭和第零、一級流水線的消息，同時生成第

二級流水線的消息 ；發(fā)布消息處理線程消費消息

隊列包頭和第零、一、二級流水線的消息，并將

消息打包，提供給其他模塊消費。消息隊列保存

了每一級流水生成的消息，并維護了消息之間的

對應(yīng)關(guān)系。

其中，動態(tài)消息隊列是為了適配多級流水線

模型而設(shè)計的組件，它的生產(chǎn)消費模式與多級流

水線模型是緊耦合的。對于消息隊列而言，訂閱

消息加工線程是生產(chǎn)者，發(fā)布消息處理線程是消

費者，撮合前檢查線程和撮合及撮合后處理線程

既是生產(chǎn)者又是消費者。

在動態(tài)消息隊列中，消息頭的結(jié)構(gòu)至關(guān)重要，

對于一個原始請求消息及其在各級流水線中生成

的衍生消息，消息頭記錄了流水線的處理結(jié)果和

上一級處理該消息的流水線序號，各級流水線通

過消息頭判斷消息是否可讀。動態(tài)消息隊列內(nèi)部

實現(xiàn)大致如圖 5 所示。

3.4 架構(gòu)極簡及業(yè)務(wù)極簡

在技術(shù)架構(gòu)方面，異構(gòu)交易系統(tǒng)主要用于應(yīng)

急場景，因此在架構(gòu)上剝離了分布式容錯撮合集

群，僅保留訂單、行情關(guān)鍵路徑模塊，構(gòu)成最小

完整狀態(tài)集，使得架構(gòu)層代碼減少 20%。

在業(yè)務(wù)架構(gòu)方面，基于全新的抽象程度更高、

基于聚合根的領(lǐng)域服務(wù)業(yè)務(wù)模型，剝離了非必須

業(yè)務(wù)，僅保留交易業(yè)務(wù)最小集，去除了為擴展性

預(yù)留的以及未開啟的業(yè)務(wù)功能，在確保業(yè)務(wù)延續(xù)

性的同時，保證了業(yè)務(wù)應(yīng)用層的簡化，精簡了核

心計算邏輯。以不同的實現(xiàn)方式重構(gòu)之后，實現(xiàn)

了相同的業(yè)務(wù)功能，業(yè)務(wù)代碼行數(shù)減少 55%，減

少了開發(fā)成本。

在模塊架構(gòu)方面，對比主交易系統(tǒng)，考慮到

查詢模塊和行情生成模塊的輕量性及其與交易行

7

訂閱 撮合 發(fā)布 訂

閱

撮

合

前

撮

合

撮

合

后

共享動態(tài)消息隊列

發(fā)

布

圖 3 交易系統(tǒng)多級流水線業(yè)務(wù)模型

在同一測試環(huán)境進行測試，多級流水線性能提升顯著，具體如表 1 所示。引入撮合流水線后，系統(tǒng)吞

吐能力顯著提升。由于架構(gòu)上進行了本地持久化的原因，延時略微增加，但仍在合理范圍以內(nèi)。

表 1 異構(gòu)交易性能比對表

系統(tǒng) 處理延時 吞吐能力

主交易系統(tǒng) 98us 7.1 萬筆/秒

異構(gòu)交易系統(tǒng) 110us 16.5 萬筆/秒

從技術(shù)模型實現(xiàn)來看，異構(gòu)交易系統(tǒng)的業(yè)務(wù)處理部分由四個線程驅(qū)動，分別為訂閱消息加工線程、撮

合前檢查線程、撮合及撮合后處理線程、發(fā)布消息處理線程，與圖 4 中線程一一對應(yīng)。其中，訂閱消息加

工線程將異構(gòu)交易上行的消息包進行解包，生成消息隊列的包頭以及流水線的第零級消息，消息隊列包頭

是多個線程訪問消息隊列的關(guān)鍵，控制著線程對同一個消息的讀寫權(quán)限，第零級消息通常是上行數(shù)據(jù)包的

原始數(shù)據(jù)，也就是輸入的請求包；撮合前檢查線程消費消息隊列包頭和第零級流水線的消息，同時生成第

一級流水線的消息；撮合及撮合后處理線程消費消息隊列包頭和第零、一級流水線的消息，同時生成第二

級流水線的消息；發(fā)布消息處理線程消費消息隊列包頭和第零、一、二級流水線的消息，并將消息打包，

提供給其他模塊消費。消息隊列保存了每一級流水生成的消息，并維護了消息之間的對應(yīng)關(guān)系。

圖 4 異構(gòu)交易系統(tǒng)多級流水線運行架構(gòu)

認(rèn)為此模式。

3.2 :;<=>?@ABC2D

通過抽取基于交易參與者+合約的最細(xì)粒度數(shù)據(jù)聚合根，將不同業(yè)務(wù)域數(shù)據(jù)按層級進行掛載，實現(xiàn)數(shù)

據(jù)訪問的簡化和高效率，對原主交易系統(tǒng)的業(yè)務(wù)模型進行了完全的重構(gòu)，通過異構(gòu)避免嚴(yán)重故障，提升了

軟件可靠性。

全新的領(lǐng)域服務(wù)校驗?zāi)Ｐ蛢?nèi)部通過業(yè)務(wù)功能、領(lǐng)域模型、內(nèi)存數(shù)據(jù)三層進行劃分，配合數(shù)據(jù)聚合根，

業(yè)務(wù)邏輯不再關(guān)心數(shù)據(jù)存取訪問，模型抽象程度更高。同時，領(lǐng)域服務(wù)不依賴外部系統(tǒng)、不保存狀態(tài)，所

以更容易進行單元測試，這對于提高系統(tǒng)的質(zhì)量是非常有幫助的。

3.3 EFG@H56I2D

異構(gòu)交易系統(tǒng)的消息傳遞采用多級流水線模型，將業(yè)務(wù)數(shù)據(jù)處理流程在邏輯上劃分成相互獨立的若干

部分，每個部分由一個線程驅(qū)動，線程之間共享消息隊列。

從總體業(yè)務(wù)模型的角度上來看，如圖 3 所示，相比于主交易系統(tǒng)的訂閱->單線程撮合->發(fā)布的結(jié)構(gòu)，

異構(gòu)交易系統(tǒng)將撮合線程按延時占比拆分為撮合前、撮合、撮合后三部分異步處理消息。

訂閱 撮合 發(fā)布 訂

閱

撮

合

前

撮

合

撮

合

后

共享動態(tài)消息隊列

發(fā)

布

圖 3 交易系統(tǒng)多級流水線業(yè)務(wù)模型

在同一測試環(huán)境進行測試，多級流水線性能提升顯著，具體如表 1 所示。引入撮合流水線后，系統(tǒng)吞

吐能力顯著提升。由于架構(gòu)上進行了本地持久化的原因，延時略微增加，但仍在合理范圍以內(nèi)。

表 1 異構(gòu)交易性能比對表

系統(tǒng) 處理延時 吞吐能力

主交易系統(tǒng) 98us 7.1 萬筆/秒

異構(gòu)交易系統(tǒng) 110us 16.5 萬筆/秒

從技術(shù)模型實現(xiàn)來看，異構(gòu)交易系統(tǒng)的業(yè)務(wù)處理部分由四個線程驅(qū)動，分別為訂閱消息加工線程、撮

合前檢查線程、撮合及撮合后處理線程、發(fā)布消息處理線程，與圖 4 中線程一一對應(yīng)。其中，訂閱消息加

工線程將異構(gòu)交易上行的消息包進行解包，生成消息隊列的包頭以及流水線的第零級消息，消息隊列包頭

是多個線程訪問消息隊列的關(guān)鍵，控制著線程對同一個消息的讀寫權(quán)限，第零級消息通常是上行數(shù)據(jù)包的

原始數(shù)據(jù)，也就是輸入的請求包；撮合前檢查線程消費消息隊列包頭和第零級流水線的消息，同時生成第

一級流水線的消息；撮合及撮合后處理線程消費消息隊列包頭和第零、一級流水線的消息，同時生成第二

級流水線的消息；發(fā)布消息處理線程消費消息隊列包頭和第零、一、二級流水線的消息，并將消息打包，

提供給其他模塊消費。消息隊列保存了每一級流水生成的消息，并維護了消息之間的對應(yīng)關(guān)系。

圖 4 異構(gòu)交易系統(tǒng)多級流水線運行架構(gòu)

表 1 ：異構(gòu)交易性能比對表

圖 4 ：異構(gòu)交易系統(tǒng)多級流水線運行架構(gòu)

本期熱點

8

為的耦合，將這兩個模塊納入異構(gòu)交易系統(tǒng)核心

進程中。除了復(fù)用的主交易前置及外圍模塊，異

構(gòu)交易系統(tǒng)僅有一個進程，保證了異構(gòu)交易系統(tǒng)

的輕量級和靈活性。

3.5 運維視圖及故障根因分析系統(tǒng)

為了實現(xiàn)故障的快速發(fā)現(xiàn)和定位，在開發(fā)異

構(gòu)交易系統(tǒng)的同時，交付了一套基于大數(shù)據(jù)、集成

了運維視圖及故障根因分析系統(tǒng)的智能運維平臺，

實時跟蹤主交易系統(tǒng)及異構(gòu)交易系統(tǒng)運行狀態(tài)。

根因分析系統(tǒng)融合了 Logging+Tracing+Metrics 的監(jiān)控設(shè)計理念，定義了異構(gòu)交易系統(tǒng)健康

運行五大黃金指標(biāo) ：通訊量、錯誤率、資源飽和

度、進程狀態(tài)、同步數(shù)據(jù)落差，通過數(shù)十個監(jiān)控

子指標(biāo)監(jiān)控系統(tǒng)運行狀況，運用 Splunk 搭建了運

維指標(biāo)視圖，所有指標(biāo)均支持分鐘粒度告警和回

溯，實現(xiàn)了事前監(jiān)控、事中定位、事后回溯的全

時段功能。

指標(biāo)監(jiān)控報錯監(jiān)測到故障時，可通過根因自

動分析系統(tǒng)（圖 6）查看故障根因，也可通過日

志全鏈路追蹤，進行主系統(tǒng)的故障發(fā)現(xiàn)及定位，

大幅減少根因定位時間，快速為切換異構(gòu)交易系

統(tǒng)決策提供輔助依據(jù)。同時，智能運維平臺也支

持一鍵切換，切換至異構(gòu)交易系統(tǒng)后同樣可持續(xù)

監(jiān)控異構(gòu)系統(tǒng)作為主系統(tǒng)運行時的各項指標(biāo)。

智能運維平臺針對日常運維和特殊排障場景

提供了全面的運維方案和體系，減少了異構(gòu)交易

系統(tǒng)的運維成本。

3.6 平滑切換

接口一致性 ：異構(gòu)交易系統(tǒng)在設(shè)計開發(fā)中維

持對外 API 及對內(nèi)上下游系統(tǒng)接口不變，使得切

換時會員端系統(tǒng)、所內(nèi)上下游系統(tǒng)可持續(xù)平穩(wěn)運

行。在故障切換時，對外會員無需任何操作，做

到會員端無感知。對內(nèi)支持?jǐn)帱c續(xù)傳，保證了數(shù)

據(jù)一致性與完整性。在業(yè)務(wù)層面保證了平滑切換，

切換后的所支持的業(yè)務(wù)也維持不變。

業(yè)務(wù)一致性：異構(gòu)交易系統(tǒng)以備模式運行時，

其中，動態(tài)消息隊列是為了適配多級流水線模型而設(shè)計的組件，它的生產(chǎn)消費模式與多級流水線模型

是緊耦合的。對于消息隊列而言，訂閱消息加工線程是生產(chǎn)者，發(fā)布消息處理線程是消費者，撮合前檢查

線程和撮合及撮合后處理線程既是生產(chǎn)者又是消費者。

在動態(tài)消息隊列中，消息頭的結(jié)構(gòu)至關(guān)重要，對于一個原始請求消息及其在各級流水線中生成的衍生

消息，消息頭記錄了流水線的處理結(jié)果和上一級處理該消息的流水線序號，各級流水線通過消息頭判斷消

息是否可讀。動態(tài)消息隊列內(nèi)部實現(xiàn)大致如圖 5 所示。

圖 5 動態(tài)消息隊列實現(xiàn)結(jié)構(gòu)

3.4 /\"JK4LMJK

在技術(shù)架構(gòu)方面，異構(gòu)交易系統(tǒng)主要用于應(yīng)急場景，因此在架構(gòu)上剝離了分布式容錯撮合集群，僅保

留訂單、行情關(guān)鍵路徑模塊，構(gòu)成最小完整狀態(tài)集，使得架構(gòu)層代碼減少 20%。

在業(yè)務(wù)架構(gòu)方面，基于全新的抽象程度更高、基于聚合根的領(lǐng)域服務(wù)業(yè)務(wù)模型，剝離了非必須業(yè)務(wù)，

僅保留交易業(yè)務(wù)最小集，去除了為擴展性預(yù)留的以及未開啟的業(yè)務(wù)功能，在確保業(yè)務(wù)延續(xù)性的同時，保證

了業(yè)務(wù)應(yīng)用層的簡化，精簡了核心計算邏輯。以不同的實現(xiàn)方式重構(gòu)之后，實現(xiàn)了相同的業(yè)務(wù)功能，業(yè)務(wù)

代碼行數(shù)減少 55%，減少了開發(fā)成本。

在模塊架構(gòu)方面，對比主交易系統(tǒng)，考慮到查詢模塊和行情生成模塊的輕量性及其與交易行為的耦合，

將這兩個模塊納入異構(gòu)交易系統(tǒng)核心進程中。除了復(fù)用的主交易前置及外圍模塊，異構(gòu)交易系統(tǒng)僅有一個

進程，保證了異構(gòu)交易系統(tǒng)的輕量級和靈活性。

3.5 0NOP4QR>STU%&

為了實現(xiàn)故障的快速發(fā)現(xiàn)和定位，在開發(fā)異構(gòu)交易系統(tǒng)的同時，交付了一套基于大數(shù)據(jù)、集成了運維

視圖及故障根因分析系統(tǒng)的智能運維平臺，實時跟蹤主交易系統(tǒng)及異構(gòu)交易系統(tǒng)運行狀態(tài)。

根因分析系統(tǒng)融合了 Logging+Tracing+Metrics 的監(jiān)控設(shè)計理念，定義了異構(gòu)交易系統(tǒng)健康運行五大黃

金指標(biāo)：通訊量、錯誤率、資源飽和度、進程狀態(tài)、同步數(shù)據(jù)落差，通過數(shù)十個監(jiān)控子指標(biāo)監(jiān)控系統(tǒng)運行

狀況，運用 Splunk 搭建了運維指標(biāo)視圖，所有指標(biāo)均支持分鐘粒度告警和回溯，實現(xiàn)了事前監(jiān)控、事中定

圖 5 ：動態(tài)消息隊列實現(xiàn)結(jié)構(gòu)

交易技術(shù)前沿

9

實時接收來自主系統(tǒng)的數(shù)據(jù)，并將數(shù)據(jù)進行重構(gòu)，

使得異構(gòu)交易系統(tǒng)的數(shù)據(jù)及狀態(tài)與主系統(tǒng)保持一

致。以主模式運行時，為了保證重構(gòu)結(jié)果的一致

性，通過近年的交易流水反演比對和同步一致性

比對，驗證了異構(gòu)交易系統(tǒng)在主模式下與主系統(tǒng)

業(yè)務(wù)功能結(jié)果完全一致。業(yè)務(wù)一致性保證了切換

后異構(gòu)交易系統(tǒng)可平滑接管業(yè)務(wù)。

為了保證異構(gòu)交易系統(tǒng)與主交易系統(tǒng)的業(yè)

務(wù)、行情的一致性，采用了兩套同步一致性比對

方案 ：

一是實時接收主交易系統(tǒng)和異構(gòu)交易系統(tǒng)恢

復(fù)模式下的撮合結(jié)果及行情流水，進行交易結(jié)果

數(shù)據(jù)、行情發(fā)布數(shù)據(jù)的業(yè)務(wù)比對稽核，確保在恢

復(fù)模式下主系統(tǒng)與異構(gòu)系統(tǒng)的數(shù)據(jù)一致性 ；

二是在并行環(huán)境上部署了一套以撮合模式運

行的異構(gòu)交易系統(tǒng)，實時接收主中心的請求消息

并進行撮合，將撮合及行情結(jié)果與主中心進行比

對。此系統(tǒng)僅用作撮合模式的結(jié)果比對，驗證異

構(gòu)系統(tǒng)撮合模式的正確性，不參與應(yīng)急切換。

極速切換 ：異構(gòu)交易系統(tǒng)復(fù)用主交易的交易

前置和行情前置，切換后核心與前置均無需進行

反演就可直接進行交易，除去停止主交易核心進

程和決策的時間，可以做到秒級切換，最大程度

保證業(yè)務(wù)連續(xù)性。

3.7 國產(chǎn)化自主可控

異構(gòu)交易系統(tǒng)在設(shè)計階段充分考慮跨平臺

運行需求，在組件開發(fā)階段嚴(yán)格在自主可控環(huán)境

進行測試驗證，確保自主可控環(huán)境的可用性。在

基于 X86_64 架構(gòu)、浪潮服務(wù)器、麒麟操作系統(tǒng)、

海光 CPU 的自主可控環(huán)境上，異構(gòu)交易系統(tǒng)的

各項功能平穩(wěn)運行、延時及吞吐的性能指標(biāo)達標(biāo)，

并在自主可控環(huán)境成功上線，平穩(wěn)運行至今。

在功能方面，異構(gòu)交易系統(tǒng)在自主可控環(huán)境

上累計執(zhí)行回歸測試用例 14 余萬條，并通過了

近兩年的生產(chǎn)流水反演比對測試 ；在性能方面，

對環(huán)境特性及參數(shù)進行了分析和調(diào)優(yōu)，使得性能

提升了 8%，異構(gòu)交易系統(tǒng)在自主可控環(huán)境中的

報單吞吐量為9萬筆/秒，報單延時約為150微秒。

4、系統(tǒng)建設(shè)成效

提高交易所業(yè)務(wù)連續(xù)性保障能力。交易系統(tǒng)

是交易所核心競爭力的重要體現(xiàn)，是金融市場中

位、事后回溯的全時段功能。

指標(biāo)監(jiān)控報錯監(jiān)測到故障時，可通過根因自動分析系統(tǒng)（圖 6）查看故障根因，也可通過日志全鏈路

追蹤，進行主系統(tǒng)的故障發(fā)現(xiàn)及定位，大幅減少根因定位時間，快速為切換異構(gòu)交易系統(tǒng)決策提供輔助依

據(jù)。同時，智能運維平臺也支持一鍵切換，切換至異構(gòu)交易系統(tǒng)后同樣可持續(xù)監(jiān)控異構(gòu)系統(tǒng)作為主系統(tǒng)運

行時的各項指標(biāo)。

數(shù)據(jù)庫（事件庫，交易知識庫，推導(dǎo)規(guī)則庫，歷史事件庫）

EventMatch

事件匹配

事件

GenGraph

生成故障分析圖譜

交易知識 圖譜存儲

EventAnalysis

根因推導(dǎo)

推導(dǎo)規(guī)則

② ④

時間序列數(shù)據(jù)庫

③

LogParse

日志解析

EventShow

根因展示

⑤

智能運維交互終端

⑥

砸緯紉愿

LightCam ①

同步日志

告警

①

圖 6 根因自動分析系統(tǒng)

智能運維平臺針對日常運維和特殊排障場景提供了全面的運維方案和體系，減少了異構(gòu)交易系統(tǒng)的運

維成本。

3.6 VWXY

接口一致性：異構(gòu)交易系統(tǒng)在設(shè)計開發(fā)中維持對外 API 及對內(nèi)上下游系統(tǒng)接口不變，使得切換時會員

端系統(tǒng)、所內(nèi)上下游系統(tǒng)可持續(xù)平穩(wěn)運行。在故障切換時，對外會員無需任何操作，做到會員端無感知。

對內(nèi)支持?jǐn)帱c續(xù)傳，保證了數(shù)據(jù)一致性與完整性。在業(yè)務(wù)層面保證了平滑切換，切換后的所支持的業(yè)務(wù)也

維持不變。

業(yè)務(wù)一致性：異構(gòu)交易系統(tǒng)以備模式運行時，實時接收來自主系統(tǒng)的數(shù)據(jù)，并將數(shù)據(jù)進行重構(gòu)，使得

異構(gòu)交易系統(tǒng)的數(shù)據(jù)及狀態(tài)與主系統(tǒng)保持一致。以主模式運行時，為了保證重構(gòu)結(jié)果的一致性，通過近年

的交易流水反演比對和同步一致性比對，驗證了異構(gòu)交易系統(tǒng)在主模式下與主系統(tǒng)業(yè)務(wù)功能結(jié)果完全一致。

業(yè)務(wù)一致性保證了切換后異構(gòu)交易系統(tǒng)可平滑接管業(yè)務(wù)。

為了保證異構(gòu)交易系統(tǒng)與主交易系統(tǒng)的業(yè)務(wù)、行情的一致性，采用了兩套同步一致性比對方案：

一是實時接收主交易系統(tǒng)和異構(gòu)交易系統(tǒng)恢復(fù)模式下的撮合結(jié)果及行情流水，進行交易結(jié)果數(shù)據(jù)、行

情發(fā)布數(shù)據(jù)的業(yè)務(wù)比對稽核，確保在恢復(fù)模式下主系統(tǒng)與異構(gòu)系統(tǒng)的數(shù)據(jù)一致性；

二是在并行環(huán)境上部署了一套以撮合模式運行的異構(gòu)交易系統(tǒng)，實時接收主中心的請求消息并進行撮

合，將撮合及行情結(jié)果與主中心進行比對。此系統(tǒng)僅用作撮合模式的結(jié)果比對，驗證異構(gòu)系統(tǒng)撮合模式的

正確性，不參與應(yīng)急切換。

極速切換：異構(gòu)交易系統(tǒng)復(fù)用主交易的交易前置和行情前置，切換后核心與前置均無需進行反演就可

直接進行交易，除去停止主交易核心進程和決策的時間，可以做到秒級切換，最大程度保證業(yè)務(wù)連續(xù)性。

3.7 Z[\\]^_`

異構(gòu)交易系統(tǒng)在設(shè)計階段充分考慮跨平臺運行需求，在組件開發(fā)階段嚴(yán)格在自主可控環(huán)境進行測試驗

圖 6 ：根因自動分析系統(tǒng)

本期熱點

最為核心的交易基礎(chǔ)設(shè)施。異構(gòu)交易系統(tǒng)上線后，

可提高核心系統(tǒng)的整體可用性。在主系統(tǒng)可用性

為 99.999% 的情況下，主系統(tǒng)每年的宕機時間為

36 秒以下，而加入了異構(gòu)交易系統(tǒng)后，在異構(gòu)系

統(tǒng)本身可用性為 99%、異構(gòu)率為 50% 的情況下，

根據(jù)計算，整體系統(tǒng)每年的宕機時間將下降為 18

秒，且隨著異構(gòu)率的上升，宕機時間還將繼續(xù)減

少。異構(gòu)交易系統(tǒng)的上線，有效提高了交易所的

業(yè)務(wù)連續(xù)性保障能力，降低了技術(shù)故障對市場的

沖擊，在保障金融市場安全穩(wěn)定運行方面起到重

要作用。

探索實踐下一代核心系統(tǒng)。異構(gòu)交易系統(tǒng)作

為具備主交易系統(tǒng)完備業(yè)務(wù)功能的異構(gòu)系統(tǒng)和下

一代交易系統(tǒng)的原型，在簡化了部分可靠性保障

機制的情況下，比照全面建設(shè)一套新系統(tǒng)再上線

的時間周期，異構(gòu)交易系統(tǒng)在上線周期上大約可

縮短 60%。其在生產(chǎn)環(huán)境上的運行，絕大部分時

間在作備的場景下運行，既能作為主系統(tǒng)軟件故

障時的應(yīng)急補充，又能使其經(jīng)歷生產(chǎn)環(huán)境真實場

景的考驗逐步迭代完善，大大降低了下一代系統(tǒng)

驗證的成本。此外，異構(gòu)交易系統(tǒng)中投入使用的

更先進的框架、組件、模型等不但可作為下一代

核心系統(tǒng)的技術(shù)底座，還可以在其他項目組中被

復(fù)用，也可為公司節(jié)省下一定軟件研發(fā)費用，并

縮短研發(fā)周期。

核心系統(tǒng)自主可控環(huán)境落地。異構(gòu)交易系統(tǒng)

在設(shè)計階段充分考慮跨平臺運行需求，在開發(fā)階

段嚴(yán)格在自主可控環(huán)境進行測試驗證，確保系統(tǒng)

在自主可控環(huán)境的可用性。在基于國產(chǎn)海光服務(wù)

器、麒麟操作系統(tǒng)的自主可控環(huán)境，異構(gòu)交易系

統(tǒng)運行平穩(wěn)、各項功能正常、延時及吞吐等性能

指標(biāo)達標(biāo)。異構(gòu)交易系統(tǒng)在自主可控環(huán)境的成功

落地，實現(xiàn)了軟件層硬件層雙異構(gòu)，提升了核心

系統(tǒng)在基礎(chǔ)設(shè)施層的自主可控性。

5、總結(jié)與展望

本文對異構(gòu)交易系統(tǒng)的技術(shù)難點、架構(gòu)、關(guān)

鍵技術(shù)分別進行了介紹和闡述。異構(gòu)交易系統(tǒng)在

大規(guī)模數(shù)據(jù)量、極低時延要求的應(yīng)用場景下，可

實時接替主系統(tǒng)提供全量交易服務(wù)，大幅提升核

心系統(tǒng)的可靠性，降低由于軟件故障導(dǎo)致系統(tǒng)性

風(fēng)險發(fā)生的可能性。同時在自主可控環(huán)境中，維

持內(nèi)部延時基本不變的前提下，相比非自主可控

環(huán)境撮合吞吐仍可提升 135%。

目前，異構(gòu)交易系統(tǒng)已在生產(chǎn)環(huán)境順利上線，

成功主備并行運行至今。同時，在測試演練方面，

先后組織了多次自主可控生產(chǎn)環(huán)境的會員切換演

練，在會員接入的情況下，成功從非自主可控主

核心系統(tǒng)切換至自主可控異構(gòu)交易系統(tǒng)，業(yè)務(wù)持

續(xù)平穩(wěn)運行。

未來隨著中國金融市場的發(fā)展，各家交易所

的系統(tǒng)復(fù)雜性必然會不斷上升，外部環(huán)境也趨更

加變幻莫測，“交易不斷，數(shù)據(jù)不亂”的目標(biāo)仍

會是重中之重，如何在軟件層面建立完備的容錯

機制就顯得更加重要。異構(gòu)交易系統(tǒng)將結(jié)合各家

交易所先進經(jīng)驗，持續(xù)探索優(yōu)化，為金融市場穩(wěn)

定運行作出貢獻。

10

交易技術(shù)前沿

隨著客戶數(shù)量的增加，業(yè)務(wù)功能的完善，以及多節(jié)點的擴展需求，海通證券新一代

核心交易系統(tǒng)運營管理平臺的統(tǒng)一路由模式應(yīng)運而生。海通證券新一代核心交易系統(tǒng)的運

營管理平臺鏈路技術(shù)創(chuàng)新，全面自主可控，適配多種基礎(chǔ)平臺及中間件。其采用了智能路

由識別、統(tǒng)一路由管理機制，并支持全節(jié)點匯總數(shù)據(jù)查詢，具有高可擴展性、安全性、靈

活性的特征。

海通證券兼容多基礎(chǔ)平臺的新一代核

心交易系統(tǒng)運營管理平臺設(shè)計與實現(xiàn)

霍軼倫、周尤珠、陸頌華、王東、袁康 / 海通證券股份有限公司

E-mail ：hyl13866@haitong.com

1、引言

在證券行業(yè)快速發(fā)展、金融科技廣泛應(yīng)用

的背景下，分布式系統(tǒng)逐漸成為了證券行業(yè)核心

交易業(yè)務(wù)的發(fā)展趨勢，全球許多證券交易所和投

行機構(gòu)都在使用分布式的平臺和架構(gòu)用以提高交

易系統(tǒng)的處理能力，降低交易系統(tǒng)響應(yīng)時間。海

通證券新一代核心交易系統(tǒng)擁有上海和深圳兩個

交易中心，多個分布式交易節(jié)點，因此其對于使

用一套運營管理平臺運營維護多個分布式交易節(jié)

點也提出了更高的技術(shù)要求。此外，全面自主可

控的鏈路技術(shù)也是保障數(shù)據(jù)安全與網(wǎng)絡(luò)安全的關(guān)

鍵。在這種情形下，海通證券新一代核心交易系

統(tǒng)急需一個統(tǒng)一的運營管理平臺，實現(xiàn)用一套運

營管理平臺統(tǒng)一路由分發(fā)，進行全節(jié)點客戶交易

與運營管理，并對多個交易節(jié)點數(shù)據(jù)匯總查詢的

功能。有效提升運營管理效率、降低運營管理成

本，滿足統(tǒng)一平臺運營管理多節(jié)點的市場需求。

并需要開發(fā)適配各種創(chuàng)新可控的應(yīng)用服務(wù)器與中

間件，兼容多種創(chuàng)新瀏覽器及版本，高度保障網(wǎng)

11

本期熱點

12

絡(luò)安全、數(shù)據(jù)安全。

2、多技術(shù)平臺兼容適配

目前證券公司交易系統(tǒng)的核心部件大多依賴

于外部供應(yīng)廠商，自主選擇余地較小。同時關(guān)鍵

領(lǐng)域的自主可控能力已經(jīng)逐漸發(fā)展為行業(yè)可持續(xù)

發(fā)展的核心競爭力。海通證券的新一代核心交易

系統(tǒng)研發(fā)出一套自主可控、應(yīng)用技術(shù)創(chuàng)新的核心

交易系統(tǒng)運營管理平臺并成功投產(chǎn)運行。

2.1 采用海通統(tǒng)一研發(fā)平臺

海通證券新一代核心交易系統(tǒng)的統(tǒng)一運營管

理平臺采用海通證券統(tǒng)一的研發(fā)管理平臺技術(shù)，

在開源框架 GUNSV6.0 的基礎(chǔ)上開發(fā)集成，并整

合了海通管理類框架的技術(shù)優(yōu)勢。其基于主流的

前后端開發(fā)技術(shù) Vue+SpringBoot，并擁有豐富的

UI 組件體系。研發(fā)平臺提供統(tǒng)一的技術(shù)標(biāo)準(zhǔn)與

腳手架，封裝通用技術(shù)能力，有效提高研發(fā)效率

和質(zhì)量。

新一代核心交易系統(tǒng)的運營管理平臺除支持

例如微服務(wù)框架、安全機制、鏈路監(jiān)控、配置中

心等核心模塊外，還擁有豐富的插件化架構(gòu)體系，

使得在平臺建設(shè)過程中可以自由組合各模塊，實

現(xiàn)不同功能的結(jié)合與分離，從而更加便捷高效地

搭建可擴展的業(yè)務(wù)系統(tǒng)。整個運營管理平臺采用

“基座 + 插件”的架構(gòu)模式，“基座”保證整體框

架的穩(wěn)定性、兼容性、連續(xù)性。“插件”用于擴

展整體框架的適配性，提高連通性、安全性，用

以快速響應(yīng)客戶需求。

整體運營管理平臺架構(gòu)規(guī)范、完善，并具有

較高的研發(fā)效率和研發(fā)質(zhì)量，擁有更高的設(shè)計和

源碼掌控能力。

2.2 兼容多個應(yīng)用技術(shù)創(chuàng)新平臺

海通證券新一代核心交易系統(tǒng)的統(tǒng)一運營管

理平臺采用 B/S 架構(gòu)，開放兼容多個應(yīng)用技術(shù)創(chuàng)

新平臺，并可以靈活進行平臺之間的遷移。高度

保障網(wǎng)絡(luò)安全、數(shù)據(jù)安全，搭建了穩(wěn)固的自有生

態(tài)。

如圖 2 所示，對于瀏覽器，其可兼容多種應(yīng)

用技術(shù)創(chuàng)新瀏覽器，如 360 瀏覽器、奇安信可信

瀏覽器等，并適配支持瀏覽器的多個版本，保障

用戶無感遷移使用。對于各種瀏覽器均能保證頁

面顯示兼容性、插件兼容性與代碼兼容性。對于

應(yīng)用中間件、Nginx 及緩存服務(wù)，其兼容東方通

的 tongWeb tongWeb、tongRDS tongRDS，及保蘭德的 BES 等。對

于數(shù)據(jù)庫，其適配 Oracle、達夢數(shù)據(jù)庫、巨杉數(shù)

據(jù)庫等數(shù)據(jù)獨立存儲的關(guān)系型數(shù)據(jù)庫，也適配

MYSQL、GOLDENDB GOLDENDB、TiDB 等 分 布 式 數(shù) 據(jù) 庫。 等 分 布 式 數(shù) 據(jù) 庫。

對于操作系統(tǒng)，可適配諸如麒麟操作系統(tǒng)（基于

Hygon 芯片）、歐拉操作系統(tǒng)等面向企業(yè)級的通

N I?6789*+CDOPN

新一代核心交易系統(tǒng)的運營管理平臺除支持例如微服務(wù)框架、安全機制、鏈路監(jiān)控、配置中心等核心

模塊外，還擁有豐富的插件化架構(gòu)體系，使得在平臺建設(shè)過程中可以自由組合各模塊，實現(xiàn)不同功能的結(jié)

圖 1 ：運營管理平臺技術(shù)框架圖

交易技術(shù)前沿

13

用服務(wù)器架構(gòu)平臺。

3、統(tǒng)一路由應(yīng)用層設(shè)計與實現(xiàn)

隨著我國證券交易市場的發(fā)展與完善，證券

交易業(yè)務(wù)愈發(fā)多樣化、復(fù)雜化。為提升證券交易

這一核心業(yè)務(wù)的低時延、高可用、高擴展能力，

滿足不同業(yè)務(wù)場景需要，海通證券新一代核心交

易系統(tǒng)采用了基于開放平臺和消息總線的分布式

架構(gòu)，支持各分布式節(jié)點靈活部署與水平擴展。

海通證券新一代核心交易系統(tǒng)擁有上海和深圳兩

個交易中心，多個分布式交易節(jié)點，其對于統(tǒng)一

運營管理也提出了更高的技術(shù)要求。因此為了運

營維護多個分布式交易節(jié)點并支持后續(xù)節(jié)點高效

擴展的需求，海通證券新一代核心交易系統(tǒng)采用

了統(tǒng)一路由的策略進行路由識別與轉(zhuǎn)發(fā)，實現(xiàn)一

個運營管理平臺對多個分布式節(jié)點的運營管理。

3.1 運營管理平臺統(tǒng)一路由功能實現(xiàn)

3.1.1 統(tǒng)一路由鏈路設(shè)計

如圖 3 所示，運營管理平臺由 WEB 服務(wù)、

統(tǒng)一路由微服務(wù)、公司級企業(yè)服務(wù)總線有機組成。

柜員從瀏覽器端發(fā)起訪問請求，各個訪問請求通

過 Nginx 反向代理發(fā)送至運營管理平臺的統(tǒng)一路

由微服務(wù)，并根據(jù)系統(tǒng)節(jié)點、客戶節(jié)點及指令節(jié)

點增加節(jié)點信息字段，將此信息發(fā)送至公司級企

業(yè)服務(wù)總線，并在此進行路由分發(fā)，各節(jié)點的數(shù)

據(jù)庫變更內(nèi)容實時采集同步至匯總數(shù)據(jù)庫，用于

匯總數(shù)據(jù)查詢。

適配 MYSQL、GOLDENDB、TiDB 等分布式數(shù)據(jù)庫。對于操作系統(tǒng)，可適配諸如麒麟操作系統(tǒng)（基于 Hygon 芯

片）、歐拉操作系統(tǒng)等面向企業(yè)級的通用服務(wù)器架構(gòu)平臺。!

!

T?5.UVRKW:;<=>?

隨著我國證券交易市場的發(fā)展與完善，證券交易業(yè)務(wù)愈發(fā)多樣化、復(fù)雜化。為提升證券交易這一核心

業(yè)務(wù)的低時延、高可用、高擴展能力，滿足不同業(yè)務(wù)場景需要，海通證券新一代核心交易系統(tǒng)采用了基于

開放平臺和消息總線的分布式架構(gòu)，支持各分布式節(jié)點靈活部署與水平擴展。海通證券新一代核心交易系

統(tǒng)擁有上海和深圳兩個交易中心，多個分布式交易節(jié)點，其對于統(tǒng)一運營管理也提出了更高的技術(shù)要求。

因此為了運營維護多個分布式交易節(jié)點并支持后續(xù)節(jié)點高效擴展的需求，海通證券新一代核心交易系統(tǒng)采

用了統(tǒng)一路由的策略進行路由識別與轉(zhuǎn)發(fā)，實現(xiàn)一個運營管理平臺對多個分布式節(jié)點的運營管理。

XHI?6789*+5.UVYZ=>?

3.1.1 統(tǒng)一路由鏈路設(shè)計

如圖 3 所示，運營管理平臺由 WEB 服務(wù)、統(tǒng)一路由微服務(wù)、公司級企業(yè)服務(wù)總線有機組成。柜員從瀏

覽器端發(fā)起訪問請求，各個訪問請求通過 Nginx 反向代理發(fā)送至運營管理平臺的統(tǒng)一路由微服務(wù)，并根據(jù)

系統(tǒng)節(jié)點、客戶節(jié)點及指令節(jié)點增加節(jié)點信息字段，將此信息發(fā)送至公司級企業(yè)服務(wù)總線，并在此進行路

由分發(fā)，各節(jié)點的數(shù)據(jù)庫變更內(nèi)容實時采集同步至匯總數(shù)據(jù)庫，用于匯總數(shù)據(jù)查詢。

N X?6789*+[U

1）WEB 服務(wù)采用 Nginx 反向代理負(fù)載均衡

為提高系統(tǒng)并發(fā)處理能力，解決系統(tǒng)同一時間段接受到大量客戶端請求的問題，采用 Nginx 反向代理

模式，將請求信息根據(jù) Nginx 配置的服務(wù)器地址隨機分發(fā)到負(fù)載均衡的微服務(wù)中進行處理，以保證更快的

響應(yīng)和更好的用戶體驗。

2） 統(tǒng)一路由微服務(wù)解析客戶端信息

圖 3 ：運營管理平臺鏈路

1）WEB 服務(wù)采用 Nginx 反向代理負(fù)載均衡

為提高系統(tǒng)并發(fā)處理能力，解決系統(tǒng)同一時

間段接受到大量客戶端請求的問題，采用 Nginx

反向代理模式，將請求信息根據(jù) Nginx 配置的服

務(wù)器地址隨機分發(fā)到負(fù)載均衡的微服務(wù)中進行處

理，以保證更快的響應(yīng)和更好的用戶體驗。

2） 統(tǒng)一路由微服務(wù)解析客戶端信息

統(tǒng)一路由微服務(wù)是解析處理客戶端請求并連

接公司級企業(yè)服務(wù)總線的信息轉(zhuǎn)換器，其根據(jù)瀏

覽器請求中攜帶的系統(tǒng)節(jié)點、客戶節(jié)點、指令節(jié)

點在消息的報頭中添加代表節(jié)點信息的字段，并

能力。!

GHG?%&'QRKCDS-*+?

海通證券新一代核心交易系統(tǒng)的統(tǒng)一運營管理平臺采用 B/S 架構(gòu)，開放兼容多個應(yīng)用技術(shù)創(chuàng)新平臺，

并可以靈活進行平臺之間的遷移。高度保障網(wǎng)絡(luò)安全、數(shù)據(jù)安全，搭建了穩(wěn)固的自有生態(tài)。

N G?%&'RKCDS-*+

如圖 2 所示，對于瀏覽器，其可兼容多種應(yīng)用技術(shù)創(chuàng)新瀏覽器，如 360 瀏覽器、奇安信可信瀏覽器等，

并適配支持瀏覽器的多個版本，保障用戶無感遷移使用。對于各種瀏覽器均能保證頁面顯示兼容性、插件

兼容性與代碼兼容性。對于應(yīng)用中間件、Nginx 及緩存服務(wù)，其兼容東方通的 tongWeb、tongRDS，及保蘭

德的 BES 等。對于數(shù)據(jù)庫，其適配 Oracle、達夢數(shù)據(jù)庫、巨杉數(shù)據(jù)庫等數(shù)據(jù)獨立存儲的關(guān)系型數(shù)據(jù)庫，也

圖 2 ：兼容多應(yīng)用技術(shù)創(chuàng)新平臺

本期熱點

14

將此信息發(fā)送至公司級企業(yè)服務(wù)總線。

3） 公司級企業(yè)服務(wù)總線分發(fā)多個分布式節(jié)點

公司級企業(yè)服務(wù)總線也稱 ESB（Enterprise

Service Bus），主要負(fù)責(zé)對于消息進行路由節(jié)點分

發(fā)。根據(jù)滬深兩個交易中心，ESB 設(shè)置了兩個安

全集成平臺（也稱 DataPower），并為每一個交易

節(jié)點配置一個協(xié)議轉(zhuǎn)換平臺（也稱 CpackPower）

進行消息分發(fā)。DataPower 根據(jù)請求中攜帶的節(jié)

點信息發(fā)至不同的 CpackPower，并將 HTTP 協(xié)議

轉(zhuǎn)換為加密后的安全協(xié)議。

3.1.2 統(tǒng)一路由分發(fā)機制

如何正確反映客戶端請求與各節(jié)點后臺組件

之間的映射關(guān)系從而讓請求發(fā)送至對應(yīng)的系統(tǒng)節(jié)

點是成功實現(xiàn)多節(jié)點路由分發(fā)的關(guān)鍵，簡潔可靠

的路由分發(fā)機制可以保障運營管理平臺的路由安

全性與路由準(zhǔn)確性。

1）節(jié)點信息映射

每一個節(jié)點的后臺組件都有相應(yīng)的系統(tǒng)編

號，在數(shù)據(jù)庫中存在一個系統(tǒng)路由映射表，其

唯一確認(rèn)并代表著網(wǎng)頁端選擇的系統(tǒng)節(jié)點和后臺

組件系統(tǒng)編號的映射關(guān)系，根據(jù)此映射表，可以

準(zhǔn)確獲取前后臺節(jié)點之間的對應(yīng)關(guān)系。統(tǒng)一路由

微服務(wù)根據(jù)前臺界面中選擇的節(jié)點號在系統(tǒng)路由

映射表中獲得此請求對應(yīng)的后臺組件節(jié)點號，并

為此 WEB 前端請求補充了代表后臺節(jié)點信息的

route 字段。

2）路由分發(fā)中心

DataPower 作為公司級企業(yè)服務(wù)總線的關(guān)鍵

組成部分，其也是運營管理平臺的節(jié)點路由分發(fā)

中心。節(jié)點路由分發(fā)中心的各子元素的節(jié)點名稱

為統(tǒng)一路由微服務(wù)中的 route 字段值，子元素的

值則為對應(yīng)節(jié)點適配器的負(fù)載均衡地址，該地址

指定請求所發(fā)往的后臺組件系統(tǒng)，從而進行安全

可靠的路由分發(fā)。

3.2 統(tǒng)一路由技術(shù)亮點

3.2.1 動態(tài)擴展路由

新一代核心交易系統(tǒng)的運營管理平臺支持在

系統(tǒng)路由界面動態(tài)擴展系統(tǒng)路由并實時生效，該

動態(tài)路由策略具備很好的可靠性和靈活性，為系

統(tǒng)靈活擴展的需求提供了有效的技術(shù)途徑。

1）擴展可靠性

支持配置某個節(jié)點作為默認(rèn)的系統(tǒng)路由，當(dāng)

操作人員在界面既不選擇操作的節(jié)點，也不選擇

相應(yīng)的客戶號時，則選取此運營管理平臺配置的

默認(rèn)節(jié)點作為其發(fā)送的系統(tǒng)節(jié)點，進行請求數(shù)據(jù)

的分發(fā)，保證系統(tǒng)的可靠性。

2）配置靈活性

當(dāng)需要新增或者減少系統(tǒng)節(jié)點時，僅需在系

統(tǒng)路由界面針對相應(yīng)的節(jié)點配置或刪除對應(yīng)的系統(tǒng)

名稱、系統(tǒng)編碼、企業(yè)服務(wù)總線地址即可，支持橫

向擴展配置，沒有流量限制，可以任意配置多個節(jié)

點且能夠及時生效，增強系統(tǒng)的靈活擴展性。

3.2.2 路由策略控制

新一代核心交易系統(tǒng)的路由策略主要可分為

節(jié)點級、客戶級、指令級三個控制力度，分級可控。

1）節(jié)點級 ：對于每個系統(tǒng)節(jié)點可以在系統(tǒng)

路由中進行節(jié)點配置，選擇是否為運營管理平臺

的默認(rèn)系統(tǒng)路由，同時也可以直接選擇訪問節(jié)點，

實現(xiàn)節(jié)點級別的路由控制。

2）客戶級 ：根據(jù)客戶號獲取客戶所屬交易

節(jié)點 , 自動進行對應(yīng)節(jié)點的請求發(fā)送，簡化操作

人員的操作復(fù)雜度，無需進行節(jié)點的選擇即可自

動控制路由配置進行請求的發(fā)送。

3）指令級 ：針對每一個不同的業(yè)務(wù)和交易，

運營管理平臺都為其分配有對應(yīng)的交易編碼指令

號，對于每一個交易編碼系統(tǒng)都支持配置其可發(fā)

送的路由節(jié)點，實現(xiàn)控制每條操作指令對應(yīng)的系

統(tǒng)路由。

3.3 統(tǒng)一路由業(yè)務(wù)亮點

3.3.1 適配多種統(tǒng)一路由業(yè)務(wù)場景

新一代核心交易系統(tǒng)運營管理平臺的統(tǒng)一路

由適配的業(yè)務(wù)場景主要分為以下幾類，涵蓋了全

交易技術(shù)前沿

15

部業(yè)務(wù)人員使用需求 ：

1）參數(shù)設(shè)置類 ：操作人員使用同一客戶端

即可對于證券基本信息等參數(shù)設(shè)置業(yè)務(wù)指定需要

同時修改的相應(yīng)節(jié)點，進行一次設(shè)置多節(jié)點分發(fā)

的參數(shù)設(shè)置模式。

2）查詢類 ：查詢類路由場景可分為客戶類查

詢和節(jié)點類查詢。對于客戶類查詢，即操作人員

輸入客戶號后由系統(tǒng)自動識別客戶所在節(jié)點，并

將查詢請求發(fā)送至此客戶所在節(jié)點進行針對此客

戶的數(shù)據(jù)查詢。節(jié)點類查詢即操作人員指定系統(tǒng)

節(jié)點，對于此節(jié)點內(nèi)的全部有權(quán)限數(shù)據(jù)進行查詢。

3）交易類 ：操作人員輸入客戶號后系統(tǒng)即

可自動識別客戶所在系統(tǒng)節(jié)點，并將此下單信息

發(fā)送至客戶對應(yīng)節(jié)點的后臺組件進行交易類功

能。

4）清算管理類 ：運維人員在清算管理全流

程中靈活配置，對于多個節(jié)點統(tǒng)一管理，并清晰

記錄操作日志，使得運維人員在一個清算管理模

塊即可清晰直觀地統(tǒng)一維護多節(jié)點清算管理步

驟。

3.3.2 降低運營管理復(fù)雜度，簡化運維升級

流程

對于運營部門的參數(shù)管理崗位人員，其需要

對于全部分布式節(jié)點中的權(quán)限數(shù)據(jù)、基本信息等

參數(shù)進行維護。采用統(tǒng)一路由機制的運營管理平

臺可以使得運營人員僅在一個平臺進行設(shè)置即可

實時同步至多個交易節(jié)點后臺，提升參數(shù)管理維

護的效率，及參數(shù)維護的安全性、一致性。

對于運維升級人員，原有的一套運營管理平

臺對應(yīng)一套分布式交易節(jié)點后臺的模式需要對于

多個運營管理平臺進行升級維護，耗時較大，維

護成本較高。統(tǒng)一路由的運營管理平臺解決了此

運維痛點，同時其簡化了整個運維升級流程，采

用配置中心模式，極大的縮減了運維升級時間，

提高了運維升級效率。

4、分布式節(jié)點數(shù)據(jù)匯總

分布式架構(gòu)逐漸成為證券行業(yè)核心交易系統(tǒng)

的技術(shù)發(fā)展必然趨勢，隨著客戶量的增加，業(yè)務(wù)

復(fù)雜度的增長，分布式節(jié)點也在快速水平擴展。

各節(jié)點的數(shù)據(jù)信息分散在各自節(jié)點的數(shù)據(jù)庫中，

對于需要同時獲取多節(jié)點信息的場景，在節(jié)點路

由分發(fā)的過程中，考慮到數(shù)據(jù)請求的全面性、實

時性，以及對于多交易節(jié)點請求的復(fù)雜度，其不

再適用各節(jié)點分別分發(fā)請求并對返回數(shù)據(jù)匯總的

方式。因此如何能夠在同一套運營管理平臺對于

全節(jié)點的客戶數(shù)據(jù)、交易信息進行匯總查詢是適

N ^?_`UVab

1）節(jié)點級：對于每個系統(tǒng)節(jié)點可以在系統(tǒng)路由中進行節(jié)點配置，選擇是否為運營管理平臺的默認(rèn)系統(tǒng)

路由，同時也可以直接選擇訪問節(jié)點，實現(xiàn)節(jié)點級別的路由控制。

2）客戶級：根據(jù)客戶號獲取客戶所屬交易節(jié)點,自動進行對應(yīng)節(jié)點的請求發(fā)送，簡化操作人員的操作

復(fù)雜度，無需進行節(jié)點的選擇即可自動控制路由配置進行請求的發(fā)送。

3）指令級：針對每一個不同的業(yè)務(wù)和交易，運營管理平臺都為其分配有對應(yīng)的交易編碼指令號，對于

每一個交易編碼系統(tǒng)都支持配置其可發(fā)送的路由節(jié)點，實現(xiàn)控制每條操作指令對應(yīng)的系統(tǒng)路由。

XHX?5.UVcd\\]?

3.3.1 適配多種統(tǒng)一路由業(yè)務(wù)場景

新一代核心交易系統(tǒng)運營管理平臺的統(tǒng)一路由適配的業(yè)務(wù)場景主要分為以下幾類，涵蓋了全部業(yè)務(wù)人

員使用需求：

1）參數(shù)設(shè)置類：操作人員使用同一客戶端即可對于證券基本信息等參數(shù)設(shè)置業(yè)務(wù)指定需要同時修改的

相應(yīng)節(jié)點，進行一次設(shè)置多節(jié)點分發(fā)的參數(shù)設(shè)置模式。

2）查詢類：查詢類路由場景可分為客戶類查詢和節(jié)點類查詢。對于客戶類查詢，即操作人員輸入客戶

號后由系統(tǒng)自動識別客戶所在節(jié)點，并將查詢請求發(fā)送至此客戶所在節(jié)點進行針對此客戶的數(shù)據(jù)查詢。節(jié)

點類查詢即操作人員指定系統(tǒng)節(jié)點，對于此節(jié)點內(nèi)的全部有權(quán)限數(shù)據(jù)進行查詢。

3）交易類：操作人員輸入客戶號后系統(tǒng)即可自動識別客戶所在系統(tǒng)節(jié)點，并將此下單信息發(fā)送至客戶

對應(yīng)節(jié)點的后臺組件進行交易類功能。

4）清算管理類：運維人員在清算管理全流程中靈活配置，對于多個節(jié)點統(tǒng)一管理，并清晰記錄操作日

志，使得運維人員在一個清算管理模塊即可清晰直觀地統(tǒng)一維護多節(jié)點清算管理步驟。

3.3.2 降低運營管理復(fù)雜度，簡化運維升級流程

對于運營部門的參數(shù)管理崗位人員，其需要對于全部分布式節(jié)點中的權(quán)限數(shù)據(jù)、基本信息等參數(shù)進行

維護。采用統(tǒng)一路由機制的運營管理平臺可以使得運營人員僅在一個平臺進行設(shè)置即可實時同步至多個交

易節(jié)點后臺，提升參數(shù)管理維護的效率，及參數(shù)維護的安全性、一致性。

圖 4 ：分級路由策略

本期熱點

應(yīng)分布式節(jié)點擴展的關(guān)鍵。為了解決此問題，海

通證券新一代核心交易系統(tǒng)的運營管理平臺采用

了將各自節(jié)點數(shù)據(jù)實時同步更新至匯總數(shù)據(jù)庫的

機制，有效提升匯總查詢效率，保障查詢的實時

性、全面性。

整個運維升級流程，采用配置中心模式，極大的縮減了運維升級時間，提高了運維升級效率。

fgh]ijkl?

布式架構(gòu)逐漸成為證券行業(yè)核心交易系統(tǒng)的技術(shù)發(fā)展必然趨勢，隨著客戶量的增加，業(yè)務(wù)復(fù)雜度的

分布式節(jié)點也在快速水平擴展。各節(jié)點的數(shù)據(jù)信息分散在各自節(jié)點的數(shù)據(jù)庫中，對于需要同時獲取

信息的場景，在節(jié)點路由分發(fā)的過程中，考慮到數(shù)據(jù)請求的全面性、實時性，以及對于多交易節(jié)點

復(fù)雜度，其不再適用各節(jié)點分別分發(fā)請求并對返回數(shù)據(jù)匯總的方式。因此如何能夠在同一套運營管

對于全節(jié)點的客戶數(shù)據(jù)、交易信息進行匯總查詢是適應(yīng)分布式節(jié)點擴展的關(guān)鍵。為了解決此問題，

券新一代核心交易系統(tǒng)的運營管理平臺采用了將各自節(jié)點數(shù)據(jù)實時同步更新至匯總數(shù)據(jù)庫的機制，

升匯總查詢效率，保障查詢的實時性、全面性。

N m?klijn

]oijn,=pqr?

個分布式節(jié)點的數(shù)據(jù)庫都有主備機制，為不影響主庫的正常使用，使用備數(shù)據(jù)庫進行數(shù)據(jù)同步至匯

庫節(jié)點。保證對于生產(chǎn)系統(tǒng)和網(wǎng)絡(luò)影響最小化，同時在秒級水平進行數(shù)據(jù)同步，保證數(shù)據(jù)的實時性

性。

數(shù)據(jù)庫不僅支持本地局域網(wǎng)數(shù)據(jù)同步，還支持跨廣域網(wǎng)數(shù)據(jù)同步。同時其還支持增量同步，數(shù)據(jù)

輸，減少網(wǎng)絡(luò)帶寬。

tgklij?

數(shù)據(jù)庫除了包含各個節(jié)點備數(shù)據(jù)庫同步過來的節(jié)點數(shù)據(jù)庫對象集合，還有一個以各個數(shù)據(jù)庫對象

構(gòu)建的視圖，根據(jù)不同數(shù)據(jù)表結(jié)構(gòu)和業(yè)務(wù)含義將不同的表進行去重排序。采用視圖的形式使得基

數(shù)據(jù)安全性得以保障，同時可以聚焦于特定的數(shù)據(jù)集合，增強邏輯數(shù)據(jù)的獨立性。

圖 5 ： 匯總數(shù)據(jù)庫

4.1 節(jié)點備數(shù)據(jù)庫的實時同步

每個分布式節(jié)點的數(shù)據(jù)庫都有主備機制，為

不影響主庫的正常使用，使用備數(shù)據(jù)庫進行數(shù)據(jù)

同步至匯總數(shù)據(jù)庫節(jié)點。保證對于生產(chǎn)系統(tǒng)和網(wǎng)

絡(luò)影響最小化，同時在秒級水平進行數(shù)據(jù)同步，

保證數(shù)據(jù)的實時性和一致性。

匯總數(shù)據(jù)庫不僅支持本地局域網(wǎng)數(shù)據(jù)同步，

還支持跨廣域網(wǎng)數(shù)據(jù)同步。同時其還支持增量同

步，數(shù)據(jù)壓縮傳輸，減少網(wǎng)絡(luò)帶寬。

4.2 視圖形式匯總數(shù)據(jù)

匯總數(shù)據(jù)庫除了包含各個節(jié)點備數(shù)據(jù)庫同步

過來的節(jié)點數(shù)據(jù)庫對象集合，還有一個以各個數(shù)

據(jù)庫對象集合匯總構(gòu)建的視圖，根據(jù)不同數(shù)據(jù)表

結(jié)構(gòu)和業(yè)務(wù)含義將不同的表進行去重排序。采用

視圖的形式使得基表中的數(shù)據(jù)安全性得以保障，

同時可以聚焦于特定的數(shù)據(jù)集合，增強邏輯數(shù)據(jù)

的獨立性。

4.3 匯總數(shù)據(jù)查詢服務(wù)、盯市服務(wù)

匯總數(shù)據(jù)查詢服務(wù)部署于匯總數(shù)據(jù)庫的服務(wù)

器上，其作為一個特殊節(jié)點的后臺組件，用以查

詢匯總庫中的數(shù)據(jù)。對于匯總類公共數(shù)據(jù)，操作

人員選擇節(jié)點為匯總節(jié)點，即可將請求通過統(tǒng)一

路由微服務(wù)及企業(yè)級消息總線發(fā)送至匯總節(jié)點的

匯總數(shù)據(jù)查詢服務(wù)，對于此匯總數(shù)據(jù)庫內(nèi)的全部

有權(quán)限數(shù)據(jù)進行查詢。

盯市服務(wù)作為對于融資融券客戶進行維保比

例監(jiān)控的重要組件，其通過數(shù)據(jù)同步機制將匯總

數(shù)據(jù)庫的數(shù)據(jù)實時同步至服務(wù)內(nèi)的內(nèi)存數(shù)據(jù)庫中

進行實時計算并盯市監(jiān)控，通過匯總數(shù)據(jù)庫模式，

其可同時對于全部分布式節(jié)點的客戶數(shù)據(jù)進行匯

總監(jiān)控，更加高效便捷。

5、總結(jié)

本文首先介紹了基于分布式架構(gòu)的海通證券

新一代核心交易系統(tǒng)運營管理平臺建設(shè)的客觀背

景，隨后介紹了應(yīng)用技術(shù)創(chuàng)新、多技術(shù)平臺兼容

機制，統(tǒng)一路由的設(shè)計方案與具體實現(xiàn)，及分布

式節(jié)點數(shù)據(jù)匯總模式。運營管理平臺采用了海通

統(tǒng)一的研發(fā)平臺，并兼容多個應(yīng)用技術(shù)創(chuàng)新平臺，

整個鏈路技術(shù)創(chuàng)新，全面自主可控，保障數(shù)據(jù)與

網(wǎng)絡(luò)安全。海通證券新一代核心交易系統(tǒng)采用分

布式架構(gòu)，有效提高交易系統(tǒng)的處理能力，降低

交易系統(tǒng)響應(yīng)時間。為適應(yīng)多分布式節(jié)點的發(fā)展

需要，運營管理平臺采用了統(tǒng)一路由分發(fā)模式，

其具有節(jié)點策略多樣性、動態(tài)靈活擴展的特點，

同時符合業(yè)務(wù)功能使用的全部場景，降低了系統(tǒng)

運營維護成本。分布式節(jié)點的數(shù)據(jù)匯總模式有效

提升了系統(tǒng)的實時性、全面性，有效解決了多節(jié)

點統(tǒng)一查詢匯總問題。以上是海通證券兼容多基

礎(chǔ)平臺的新一代核心交易系統(tǒng)運營管理平臺建設(shè)

過程中的實踐總結(jié)，希望能給業(yè)內(nèi)同行提供一點

參考與借鑒。

16

交易技術(shù)前沿

17

隨著東方證券機構(gòu)交易服務(wù)的深入發(fā)展和東方雨燕極速交易系統(tǒng)的日趨完善，為支

持各類機構(gòu)交易終端以非極速的方式接入到東方雨燕極速交易系統(tǒng)、集中交易系統(tǒng)、新一

代業(yè)務(wù)核心系統(tǒng)、及其他第三方快速交易系統(tǒng)，并支持客戶在不同交易系統(tǒng)中切換，以及

為構(gòu)建機構(gòu)交易生態(tài)圈打好基礎(chǔ)，需要建設(shè)屏蔽核心交易系統(tǒng)差異性的自主可控的機構(gòu)交

易接入中臺。本文將重點介紹東方證券機構(gòu)交易接入中臺系統(tǒng)建設(shè)方案和實踐經(jīng)驗。

機構(gòu)交易接入中臺建設(shè)實踐

胡長春、單興邦、高春蕾、李沁、黃賽、何少鋒 / 東方證券股份有限公司 系統(tǒng)運行總部 上海 200010

E-mail ：huchangchun@orientsec.com.cn

1、引言

由東方證券和東證期貨聯(lián)合自主研發(fā)的東方

雨燕 OST 極速交易系統(tǒng)上線平穩(wěn)運行，大量對交

易速度有極致要求的量化私募、量化策略及做市

交易型客戶、量化社區(qū)客戶、銀行 / 保險 / 公募 /

期貨等持牌機構(gòu)量化業(yè)務(wù)客戶通過類 CTP 的 API

接口對接進行證券交易，日均交易量百億規(guī)模。

隨著東方證券機構(gòu)交易生態(tài)圈逐漸完善以及 OST

極速交易系統(tǒng)在量化客戶中口碑穩(wěn)步提升，除極

速量化客戶外，越來越多高凈值客戶及活躍交易

型客戶均希望通過原有機構(gòu)交易終端在 OST 極速

交易系統(tǒng)中進行交易。其次為夯實財富管理業(yè)務(wù)

基石，快速響應(yīng)公司財富管理業(yè)務(wù)轉(zhuǎn)型發(fā)展需要，

提升公司核心業(yè)務(wù)系統(tǒng)的連續(xù)服務(wù)能力，保障安

全穩(wěn)定，東方證券開始構(gòu)建統(tǒng)一技術(shù)架構(gòu)的新一

本期熱點

18

代核心業(yè)務(wù)系統(tǒng)逐步替換原有集中交易系統(tǒng)。另

外為進一步落實以量化交易為重點的機構(gòu)經(jīng)紀(jì)業(yè)

務(wù)的定位，為客戶提供從策略生成到交易執(zhí)行、

軟硬件配置等一系列優(yōu)化支持服務(wù)，在量化交易

領(lǐng)域中的保持領(lǐng)先優(yōu)勢，滿足特定客戶需求可能

會進一步引入 FPGA 極速交易系統(tǒng)。

為支持機構(gòu)交易終端接入 OST 極速交易系

統(tǒng)、集中交易系統(tǒng)、新一代核心業(yè)務(wù)系統(tǒng)、以及

可能后續(xù)可能引入的 FPGA 極速交易系統(tǒng)等第三

方快速交易系統(tǒng)，機構(gòu)交易接入中臺兼容不同交

易系統(tǒng)接口協(xié)議，為機構(gòu)交易終端提供統(tǒng)一接入，

屏蔽后臺復(fù)雜性和差異性。機構(gòu)交易終端對接中

臺后，客戶在不同交易系統(tǒng)切換，機構(gòu)交易終端

系統(tǒng)無需重新對接開發(fā)，通過驗收測試后即可投

入生產(chǎn)，極大提高機構(gòu)交易終端接入效率。

2、背景

2.1 交易系統(tǒng)

2.1.1 普通交易系統(tǒng)

普通交易系統(tǒng)即集中交易系統(tǒng)為證券公司的

核心業(yè)務(wù)系統(tǒng)，定位于面向所有普通客戶進行全

部場內(nèi)和部分場外交易。系統(tǒng)實現(xiàn)的目標(biāo)是穩(wěn)定、

容量大并支持全業(yè)務(wù)，技術(shù)上主要基于傳統(tǒng)的關(guān)

系型數(shù)據(jù)庫模式，交易延時較高，并發(fā)有一定限制。

2.1.2 快速交易系統(tǒng)

快速交易系統(tǒng)目標(biāo)客戶為有快速交易需求的

量化客戶 ；系統(tǒng)通常追求高性能、高可靠性、容

量可擴展，并支持場內(nèi)大部分業(yè)務(wù) ；技術(shù)上主要

采用內(nèi)存交易技術(shù)，部分采用硬件加速機制。為

滿足客戶上海深圳報盤極致速度的要求，通常支

持靈活的雙節(jié)點，在上海和深圳分別部署，支持

同一投資者的兩個證券賬戶兩地就近報盤。

2.2 客戶交易渠道

2.2.1 普通散戶

客戶通過互聯(lián)網(wǎng)使用手機 APP、網(wǎng)上交易

PC 終端如同花順、通達信等接入普通交易系統(tǒng)

進行場內(nèi)和場外交易。客戶對交易速度不敏感，

由于通過純手工操作，對百毫秒級別的延遲感知

不明顯。

2.2.2 極速量化客戶

極速量化客戶通常托管系統(tǒng)對接快速交易系

統(tǒng)進行場內(nèi)競價交易。托管系統(tǒng)主要指極速量化

客戶自建的一套系統(tǒng)，該系統(tǒng)通過 API 對接證券

公司快速交易系統(tǒng)，并由證券公司向客戶購買后

部署在證券公司機房，僅提供給該客戶使用?？?/p>

戶對交易速度非常敏感，毫秒級延遲可能影響程

序化交易的收益，通常追求微秒級延遲?？蛻舫?/p>

主要通過托管系統(tǒng)進行交易外，通常還需要一套

備用機構(gòu)交易終端，滿足客戶除托管系統(tǒng)交易外

的全業(yè)務(wù)交易需求。

2.2.3 機構(gòu)交易終端客戶

機構(gòu)交易終端客戶指通過機構(gòu)交易終端進行

交易的客戶，主要包括使用 PB 交易終端，如迅

投 PB、恒生 PB 客戶、卡方、宇量策略平臺，和

機構(gòu) PC 交易終端，如同花順機構(gòu)版、通達信機

構(gòu)版、日內(nèi)快速交易終端等的客戶。機構(gòu)交易終

端客戶中的交易型客戶通常對交易速度較敏感，

通常追求毫秒級延遲，將客戶從普通交易系統(tǒng)遷

移至快速交易系統(tǒng)，能提升客戶交易體驗。

3、方案

3.1 總體方案

機構(gòu)交易接入中臺核心需求為提供成熟的、

符合競價交易速度、穩(wěn)定性、連續(xù)性要求的統(tǒng)一

入口，承載機構(gòu)交易統(tǒng)一協(xié)議，實現(xiàn)路由控制、

負(fù)載均衡、安全控制、流量控制、訪問控制、運

維支持等功能。

中臺基于多套交易系統(tǒng)提供的接口協(xié)議定

義機構(gòu)交易統(tǒng)一協(xié)議，實現(xiàn) C++、Java、Python

語言的 API 封裝機構(gòu)交易統(tǒng)一協(xié)議 ；基于開源

Netty 開發(fā)實現(xiàn) API 網(wǎng)關(guān)支持機構(gòu)交易終端系統(tǒng)

交易技術(shù)前沿

19

接入，通過會話管控保證安全和訪問控制并通過

gRPC 協(xié)議實現(xiàn) API 網(wǎng)關(guān)與交易系統(tǒng)適配模塊之

間內(nèi)部通訊 ；并基于微服務(wù) gRPC 框架實現(xiàn)交易

系統(tǒng)適配模塊，負(fù)責(zé)將機構(gòu)交易統(tǒng)一協(xié)議適配轉(zhuǎn)

換為各種交易系統(tǒng)的接口協(xié)議。另外為簡化系統(tǒng)

復(fù)雜度并提高系統(tǒng)可用性，引入開源 Nginx 服務(wù)

器提供具體路由控制、負(fù)載均衡、流量控制能力；

為支持主推送方式接入，引入開源 Kafka 消息中

間件存儲回報消息，由 API 網(wǎng)關(guān)通過訂閱 Kafka

獲取和緩存回報消息并通過 TCP 協(xié)議推送至機構(gòu)

交易終端。

3.2 API 與 gRPC 選擇

關(guān)于機構(gòu)交易終端系統(tǒng)接入方式，支持類

CTP API 方式還是采用公司業(yè)務(wù)中臺廣泛推廣的

gRPC 接口，在比較 API 方式和 gRPC 接口的特

點后，考慮到主流 PB 交易終端系統(tǒng)的對接習(xí)慣，

以及 gRPC 接口在支持互聯(lián)網(wǎng)接入情況下可能遭

遇非法終端接入的風(fēng)險，最終選擇支持 API 方式。

3.3 API 網(wǎng)關(guān)請求處理過程

為減少中心節(jié)點 API 網(wǎng)關(guān)的復(fù)雜度，提高系

統(tǒng)穩(wěn)定性，API 網(wǎng)關(guān)采用基于機構(gòu)交易統(tǒng)一協(xié)議

<=3.1 >?<=

機構(gòu)交易接入中臺核心需求為提供成熟的、符合競價交易速度、穩(wěn)定性、連續(xù)性要求的統(tǒng)一入口，

承載機構(gòu)交易統(tǒng)一協(xié)議，實現(xiàn)路由控制、負(fù)載均衡、安全控制、流量控制、訪問控制、運維支持等功能。

圖 1 機構(gòu)交易接入中臺總體架構(gòu)圖

中臺基于多套交易系統(tǒng)提供的接口協(xié)議定義機構(gòu)交易統(tǒng)一協(xié)議，實現(xiàn) C++、Java、Python 語言的 API

封裝機構(gòu)交易統(tǒng)一協(xié)議；基于開源 Netty 開發(fā)實現(xiàn) API 網(wǎng)關(guān)支持機構(gòu)交易終端系統(tǒng)接入，通過會話管控保

證安全和訪問控制并通過 gRPC 協(xié)議實現(xiàn) API 網(wǎng)關(guān)與交易系統(tǒng)適配模塊之間內(nèi)部通訊；并基于微服務(wù)

gRPC 框架實現(xiàn)交易系統(tǒng)適配模塊，負(fù)責(zé)將機構(gòu)交易統(tǒng)一協(xié)議適配轉(zhuǎn)換為各種交易系統(tǒng)的接口協(xié)議。另外

為簡化系統(tǒng)復(fù)雜度并提高系統(tǒng)可用性，引入開源 Nginx 服務(wù)器提供具體路由控制、負(fù)載均衡、流量控制能

力；為支持主推送方式接入，引入開源 Kafka 消息中間件存儲回報消息，由 API 網(wǎng)關(guān)通過訂閱 Kafka 獲取

和緩存回報消息并通過 TCP 協(xié)議推送至機構(gòu)交易終端。

圖 1 ： 機構(gòu)交易接入中臺總體架構(gòu)圖

3.2 API @ gRPC AB

關(guān)于機構(gòu)交易終端系統(tǒng)接入方式，支持類 CTP API 方式還是采用公司業(yè)務(wù)中臺廣泛推廣的 gRPC 接

口，在比較 API 方式和 gRPC 接口的特點后，考慮到主流 PB 交易終端系統(tǒng)的對接習(xí)慣，以及 gRPC 接口

在支持互聯(lián)網(wǎng)接入情況下可能遭遇非法終端接入的風(fēng)險，最終選擇支持 API 方式。

表 1 API 方式與 gRPC 接口對比

API 方式 gRPC 接口

對接模式 主查詢模式、主推送模式 主查詢模式、主推送模式

支持語言 C++、Java、Python Java、C++、Python、C#、Go、Kotlin、Node、PHP、

Ruby

支持平臺 Linux、Windows Linux、Windows、Mac

API 開發(fā) 需定制開發(fā) 無需 API 開發(fā)，僅提供接口文檔，可通過工具自動生成

客戶端 API

通訊特點 通過 TCP 長連接通訊，委托、回報時延低 采用 HTTP2 通訊，gRPC 協(xié)議相對 TCP 協(xié)議復(fù)雜，委

托、回報時延相對較高

適用場景 符合主流 PB 交易終端系統(tǒng)對接習(xí)慣 微服務(wù)架構(gòu)，無需維護連接，無會話狀態(tài)，容易橫向擴

展

3.3 API CDEFGHIJ

為減少中心節(jié)點 API 網(wǎng)關(guān)的復(fù)雜度，提高系統(tǒng)穩(wěn)定性，API 網(wǎng)關(guān)采用基于機構(gòu)交易統(tǒng)一協(xié)議的 gRPC

接交系統(tǒng)模塊機構(gòu)交統(tǒng)協(xié)交系統(tǒng)接協(xié)的轉(zhuǎn)換交系統(tǒng)模塊完表 1 ：API 方式與 gRPC 接口對比

本期熱點

的 gRPC 接口調(diào)用交易系統(tǒng)適配模塊，機構(gòu)交易

統(tǒng)一協(xié)議和交易系統(tǒng)接口協(xié)議的適配轉(zhuǎn)換由交易

系統(tǒng)適配模塊完成，API 網(wǎng)關(guān)負(fù)責(zé)解析通訊報文、

校驗報文入?yún)?、校驗會話、并根?jù)業(yè)務(wù)功能、客戶、

請求參數(shù)確定路由信息，轉(zhuǎn)發(fā)請求和處理響應(yīng)。

3.4 API 網(wǎng)關(guān)設(shè)計

API 網(wǎng)關(guān)主要內(nèi)容包括 API 消息協(xié)議、API

網(wǎng)關(guān)初始化、會話管理、路由管理、訂閱推送等

功能。

API 消息協(xié)議 TCP 報文內(nèi)容結(jié)構(gòu)包括消息

頭、消息體、校驗位三部分。消息頭包括請求類

型、請求編號、業(yè)務(wù)消息長度、壓縮標(biāo)志、最后

報文標(biāo)志、API版本等內(nèi)容；消息體包括業(yè)務(wù)消息；

校驗位為檢查報文內(nèi)容有效性。

API 網(wǎng)關(guān)啟動初始化過程中，從管理數(shù)據(jù)庫

獲取資金賬戶白名單、以及關(guān)聯(lián)的 IP、MAC 信息，

并通過調(diào)用交易系統(tǒng)適配模塊 gRPC 服務(wù)獲取各

交易系統(tǒng)節(jié)點支持的資金賬戶和市場。

機構(gòu)交易終端在與 API 網(wǎng)關(guān)建立 TCP 連接

后，調(diào)用登錄接口認(rèn)證建立會話。建立會話過程

主要包括資金賬戶白名單、終端 IP、MAC 信息

校驗，以及交易密碼校驗，校驗通過后建立會話。

API 網(wǎng)關(guān)管理會話相關(guān)的 TCP 連接、資金賬戶、

消息訂閱狀態(tài)、終端信息等信息。在 TCP 連接斷

開時，API 網(wǎng)關(guān)注銷會話并清理會話相關(guān)內(nèi)容。

API 網(wǎng)關(guān)根據(jù)請求資金賬戶和市場代碼，確定

客戶競價交易相關(guān)請求對應(yīng)的交易系統(tǒng)節(jié)點。針對

圖 2 API 網(wǎng)關(guān)請求處理過程

3.4 API CD*K

API 網(wǎng)關(guān)主要內(nèi)容包括 API 消息協(xié)議、API 網(wǎng)關(guān)初始化、會話管理、路由管理、訂閱推送等功能。

API消息協(xié)議TCP報文內(nèi)容結(jié)構(gòu)包括消息頭消息體校驗位三部分消息頭包括請求類型請求圖 2 ：API 網(wǎng)關(guān)請求處理過程

20

交易技術(shù)前沿

快速交易系統(tǒng)不支持的業(yè)務(wù)，確定客戶對應(yīng)的普通

交易系統(tǒng)。通過在發(fā)往 Nginx 服務(wù)器的 gRPC 請求

元數(shù)據(jù)中加入交易系統(tǒng)類型信息，由 Nginx 服務(wù)器

將請求轉(zhuǎn)發(fā)至對應(yīng)交易系統(tǒng)適配模塊。

3.5 交易系統(tǒng)適配模塊

東方證券制定了企業(yè)技術(shù)架構(gòu)向以微服務(wù)為

核心的現(xiàn)代化架構(gòu)轉(zhuǎn)型并選擇了具有跨語言特性

的 gRPC 為核心框架，并在其基礎(chǔ)之上新增服務(wù)

治理特性和星辰服務(wù)治理平臺，優(yōu)化改進服務(wù)質(zhì)

量。綜合考慮 gRPC 協(xié)議多路復(fù)用、高效編解碼

方式、框架成熟度以及復(fù)用公司服務(wù)治理平臺提

供的監(jiān)控和告警等功能，交易系統(tǒng)適配模塊采用

gRPC 接口方式實現(xiàn)機構(gòu)交易統(tǒng)一協(xié)議，供 API

網(wǎng)關(guān)內(nèi)部調(diào)用。基于機構(gòu)交易統(tǒng)一協(xié)議，快速交

易系統(tǒng)適配模塊提供給其支持的競價交易相關(guān)的

接口，普通交易系統(tǒng)適配模塊基本涵蓋機構(gòu)交易

統(tǒng)一協(xié)議定義的全部接口。

在引入新交易系統(tǒng)的情況下，通過新增交易

系統(tǒng)適配模塊，并在 API 網(wǎng)關(guān)和 Nginx 調(diào)整路由

配置，即可支持原有機構(gòu)交易終端接入新的交易

系統(tǒng)。

4、實踐

4.1 統(tǒng)一協(xié)議

不同系統(tǒng)對于新股申購、ETF 申贖等業(yè)務(wù)功

能接口提供方式，資金賬戶、市場代碼等業(yè)務(wù)字

段命名，委托市價、信用交易相關(guān)參數(shù)的組成，

市場代碼、委托狀態(tài)字段取值均可能不同。

機構(gòu)交易統(tǒng)一協(xié)議主要以快速交易系統(tǒng)提供

的接口為基礎(chǔ)，補充機構(gòu)交易終端支持客戶全業(yè)

務(wù)交易時所需證券交易接口。其中針對普通賬戶，

支持普通買賣、ETF 申贖、國債逆回購、新股申

購、配股配債、轉(zhuǎn)股回售、港股通業(yè)務(wù) ；針對信

用賬戶，提供擔(dān)保品買賣、信用交易、非交易委托、

新股申購業(yè)務(wù) ；針對股票期權(quán)賬戶，提供買入開

倉、賣出平倉、賣出開倉、買入平倉、備兌開倉、

備兌平倉等業(yè)務(wù)。

機構(gòu)交易統(tǒng)一協(xié)議主要包括接口清單、接口

出入?yún)⒆侄?、字典字段取值三部分?nèi)容。機構(gòu)交

易統(tǒng)一協(xié)議接口 73 個，其中同時支持普通賬戶、

信用賬戶、期權(quán)賬戶的接口 27 個 ；同時支持普

通賬戶、信用賬戶的接口 37 個 ；接口出入?yún)⒆?/p>

段 413 個，其中浮點型字段 170 個，字符類型

114 個，整型字段 76 個，長整型字段 53 個，入

參字段 131 個 ；字典字段 41 個，包括委托狀態(tài)、

委托方式、委托屬性、市場代碼等。

4.2 全業(yè)務(wù)支持

由于快速交易系統(tǒng)主要支持競價交易業(yè)務(wù)如

普通買賣、ETF 申贖、國債逆回購、信用交易、

股票期權(quán)交易等，而對速度要求不高的業(yè)務(wù)如新

股申購、配股配債、轉(zhuǎn)股回售、港股通業(yè)務(wù)由普

通交易系統(tǒng)支持。統(tǒng)一協(xié)議中將委托接口主要拆

分為競價委托和普通交易系統(tǒng)委托。

關(guān)于競價委托，API 網(wǎng)關(guān)根據(jù)客戶競價交易

所在的交易系統(tǒng)，將請求轉(zhuǎn)發(fā)至對應(yīng)的交易系統(tǒng)

適配模塊。而針對有的交易系統(tǒng)的競價委托業(yè)務(wù)，

如市價委托、限價委托、ETF 申購、ETF 贖回，

由不同的接口支持，交易系統(tǒng)適配模塊根據(jù)統(tǒng)一

協(xié)議確定請求具體業(yè)務(wù)類型，完成接口字段和字

典字段的適配，調(diào)用交易系統(tǒng)對應(yīng)的 API。

關(guān)于普通交易系統(tǒng)委托，由于部分快速交易

系統(tǒng)也支持如新股申購、配股配債、轉(zhuǎn)股等業(yè)務(wù)，

API 網(wǎng)關(guān)根據(jù)統(tǒng)一協(xié)議中普通交易系統(tǒng)委托的委托

屬性判斷業(yè)務(wù)類型，并根據(jù)客戶該業(yè)務(wù)所在的交

易系統(tǒng)，將請求轉(zhuǎn)發(fā)至對應(yīng)的交易系統(tǒng)適配模塊。

4.3 雙節(jié)點客戶支持

對于滬市深市證券賬戶分別在上海和深圳快

速交易系統(tǒng)節(jié)點的客戶，稱為雙節(jié)點客戶。通常

為追求報盤極致速度，這類客戶通過托管系統(tǒng)進

行交易。部分交易型的機構(gòu)交易終端客戶也為雙

21

本期熱點

節(jié)點客戶。針對雙節(jié)點客戶交易、資金、持倉、

委托流水、成交流水在不同交易系統(tǒng)節(jié)點的情況，

傳統(tǒng)的方案是機構(gòu)交易終端系統(tǒng)連接兩個不同交

易系統(tǒng)地址，分別進行對應(yīng)市場的交易，客戶需

選擇對應(yīng)的地址或賬號進行登錄。

中臺通過 API 網(wǎng)關(guān)路由和對查詢結(jié)果進行合

并匯總，實現(xiàn)單點接入的方式支持雙節(jié)點客戶。

對于客戶的資金、持倉、委托流水、成交流水在

不同節(jié)點的情況，API 網(wǎng)關(guān)分別將請求轉(zhuǎn)發(fā)至對

應(yīng)交易系統(tǒng)節(jié)點，并將查詢結(jié)果進行合并匯總。

對于交易類請求，API 網(wǎng)關(guān)根據(jù)入?yún)⒅惺袌龃a，

將請求轉(zhuǎn)發(fā)該市場對應(yīng)交易系統(tǒng)節(jié)點。為兼容傳

統(tǒng)方案，API 網(wǎng)關(guān)通過偵聽不同的端口分別表示

對應(yīng)上海、深圳、全市場交易系統(tǒng)節(jié)點。如果終

端系統(tǒng)連接上?；蛏钲诮灰紫到y(tǒng)節(jié)點對應(yīng)的端

口，則 API 網(wǎng)關(guān)則將請求轉(zhuǎn)發(fā)至對應(yīng)交易系統(tǒng)節(jié)

點，不進行雙節(jié)點消息的合并匯總處理。

4.4 消息訂閱

為支持主推送模式接入，避免機構(gòu)交易終端

定時查詢的消息延遲，中臺支持消息訂閱，當(dāng)委

托狀態(tài)發(fā)生變化或有成交產(chǎn)生時，主動推送消息

到機構(gòu)交易終端。通常機構(gòu)交易終端系統(tǒng)啟動時

以“從本交易日開始重傳消息”的訂閱模式接收

全量消息，在發(fā)生網(wǎng)絡(luò)異常情況下以“從上次收

到點續(xù)傳消息”的訂閱模式接收后續(xù)消息，部分

不需要全量消息的機構(gòu)交易終端，以“只傳送訂

閱后的消息”的訂閱模式接收當(dāng)時間節(jié)點后產(chǎn)生

的消息。

交易系統(tǒng)適配模塊根據(jù)各自交易系統(tǒng)對于委

托狀態(tài)和成交回報推送的方案，獲取當(dāng)日推送消

息并轉(zhuǎn)換為機構(gòu)交易統(tǒng)一協(xié)議定義的委托狀態(tài)和

成交回報消息，存儲到 Kafka 消息中間件。對于

不支持消息推送的交易系統(tǒng)，交易系統(tǒng)適配模塊

定時增量查詢獲取并存儲數(shù)據(jù)。

API 網(wǎng)關(guān)從 Kafka 消息中間件訂閱數(shù)據(jù)進行必

要轉(zhuǎn)換后在內(nèi)存中按照客戶緩存消息隊列，并維

護會話中客戶消息訂閱請求和當(dāng)前推送序號等狀

態(tài)，在有后續(xù)消息達到內(nèi)存消息隊列時通過會話

的通訊通道主動推送消息到機構(gòu)交易終端系統(tǒng)。

4.5 基于訂閱消息提供查詢

由于快速交易系統(tǒng)通過基于內(nèi)存交易技術(shù)，

大量查詢請求可能影響快速交易系統(tǒng)交易性能。

中臺基于緩存的消息隊列，提供委托查詢和成交

查詢，避免委托查詢和成交查詢請求透傳至快速

交易系統(tǒng)。

對于成交查詢，成交回報消息即為成交明細(xì)

消息。API 網(wǎng)關(guān)維護客戶、消息定位串到成交回報

消息的映射關(guān)系，其中消息定位串以跳表的數(shù)據(jù)

結(jié)構(gòu)組織，支持基于消息定位串入?yún)⒌脑隽坎樵儭?/p>

對于委托查詢，每筆委托的最新委托狀態(tài)消

息即為該筆委托的查詢結(jié)果。API 網(wǎng)關(guān)維護客戶、

消息定位串到委托狀態(tài)消息的映射關(guān)系，并在委

托的最新消息到達時，更新映射關(guān)系。

基于緩存消息提供的查詢接口，在查詢性能

和并發(fā)支持方面有數(shù)量級提升。

4.6 委托引用

機構(gòu)交易終端收到委托狀態(tài)消息時，通常使

用委托狀態(tài)消息的委托引用關(guān)聯(lián)原委托。由于部

分交易系統(tǒng)對委托引用取值規(guī)則進行限定或者定

義類型不一致，不能返回機構(gòu)交易終端委托的委

托引用。中臺將委托引用定義為長整型字段，對

于支持長整型委托引用的交易系統(tǒng)，中臺采取透

傳方式；對于不支持長整型委托引用的交易系統(tǒng)，

中臺維護委托引用和委托的關(guān)系，并在委托查詢

結(jié)果和委托狀態(tài)消息推送中補充委托引用字段。

中臺在向交易系統(tǒng)轉(zhuǎn)發(fā)委托請求前，在內(nèi)存

維護委托引用和委托的關(guān)系，并通過 Kafka 消息

中間件存儲和共享全量映射關(guān)系。在查詢委托消

息或收到交易系統(tǒng)委托狀態(tài)消息推送時，中臺根

據(jù)映射關(guān)系填充委托引用字段。由于部分映射關(guān)

系是通過 Kafka 共享，極端情況可能發(fā)生存在先

22

交易技術(shù)前沿

收到委托狀態(tài)消息而后獲取映射關(guān)系的情況，為

保障推送客戶消息的順序性以及委托引用原值返

回，中臺采用更新委托引用和回填委托引用兩部

分。在更新委托引用階段，如果未獲取委托引用，

則等待若干毫秒后重試，直至超過允許處理的時

間，在該階段該委托所屬客戶的其他消息也均暫

時阻塞，以保證消息的順序性?；靥铍A段是指在

允許處理的時間內(nèi)，未更新委托引用的消息，被

會記錄并定時檢查根據(jù)獲取的映射關(guān)系進行回填。

4.7 算法交易

中臺提供算法交易接口支持機構(gòu)交易終端算

法交易，機構(gòu)交易終端系統(tǒng)登錄中臺后其算法單的

母單子單處理流程如圖，機構(gòu)交易終端系統(tǒng)通過子

單的委托引用與母單委托編號一致匹配母單字單。

5、總結(jié)與展望

目前機構(gòu)交易接入中臺已投入生產(chǎn)使用，已

支持一套 PC 交易終端直接從互聯(lián)網(wǎng)訪問和一套

PB 交易終端 , 日均交易量約數(shù)千萬。中臺在測試

環(huán)境已支持 3 套交易系統(tǒng)的滬深 A 股普通交易、

滬深 A 股兩融交易、港股通、ETF 申贖、期權(quán)業(yè)

務(wù)接入，并完成多家 PB 交易終端接入的聯(lián)調(diào)測

試工作，隨著聯(lián)調(diào)測試?yán)^續(xù)推進，機構(gòu)交易接入

中臺將進一步完善。預(yù)計在東方證券完成新一代

核心業(yè)務(wù)系統(tǒng)切換時，機構(gòu)交易終端系統(tǒng)均通過

中臺接入交易系統(tǒng)，日均交易量約為數(shù)十億。

由于快速交易系統(tǒng)通過基于內(nèi)存交易技術(shù)，大量查詢請求可能影響快速交易系統(tǒng)交易性能。中臺基

于緩存的消息隊列，提供委托查詢和成交查詢，避免委托查詢和成交查詢請求透傳至快速交易系統(tǒng)。

對于成交查詢，成交回報消息即為成交明細(xì)消息。API 網(wǎng)關(guān)維護客戶、消息定位串到成交回報消息

的映射關(guān)系，其中消息定位串以跳表的數(shù)據(jù)結(jié)構(gòu)組織，支持基于消息定位串入?yún)⒌脑隽坎樵儭?/p>

對于委托查詢，每筆委托的最新委托狀態(tài)消息即為該筆委托的查詢結(jié)果。API 網(wǎng)關(guān)維護客戶、消息

定位串到委托狀態(tài)消息的映射關(guān)系，并在委托的最新消息到達時，更新映射關(guān)系。

基于緩存消息提供的查詢接口，在查詢性能和并發(fā)支持方面有數(shù)量級提升。

表 2 單筆查詢平均耗時比較

記錄條數(shù)

查詢方式 1 100 1w 10w 100w

透傳至交易系統(tǒng) 7.52ms 43.21ms 1.58s 12.08s 不支持

基于緩存消息查詢 1.29ms 4.46ms 110ms 737ms 6.94s

4.6 fg0h

機構(gòu)交易終端收到委托狀態(tài)消息時，通常使用委托狀態(tài)消息的委托引用關(guān)聯(lián)原委托。由于部分交易

系統(tǒng)對委托引用取值規(guī)則進行限定或者定義類型不一致，不能返回機構(gòu)交易終端委托的委托引用。中臺將

委托引用定義為長整型字段，對于支持長整型委托引用的交易系統(tǒng)，中臺采取透傳方式；對于不支持長整

型委托引用的交易系統(tǒng)，中臺維護委托引用和委托的關(guān)系，并在委托查詢結(jié)果和委托狀態(tài)消息推送中補充

委托引用字段。

中臺在向交易系統(tǒng)轉(zhuǎn)發(fā)委托請求前，在內(nèi)存維護委托引用和委托的關(guān)系，并通過 Kafka 消息中間件

存儲和共享全量映射關(guān)系。在查詢委托消息或收到交易系統(tǒng)委托狀態(tài)消息推送時，中臺根據(jù)映射關(guān)系填充

委托引用字段。由于部分映射關(guān)系是通過 Kafka 共享，極端情況可能發(fā)生存在先收到委托狀態(tài)消息而后獲

表 2 ：單筆查詢平均耗時比較

23

取映射關(guān)系的情況，為保障推送客戶消息的順序性以及委托引用原值返回，中臺采用更新委托引用和回填

委托引用兩部分。在更新委托引用階段，如果未獲取委托引用，則等待若干毫秒后重試，直至超過允許處

理的時間，在該階段該委托所屬客戶的其他消息也均暫時阻塞，以保證消息的順序性?；靥铍A段是指在允

許處理的時間內(nèi)，未更新委托引用的消息，被會記錄并定時檢查根據(jù)獲取的映射關(guān)系進行回填。

4.7 ij#$

中臺提供算法交易接口支持機構(gòu)交易終端算法交易，機構(gòu)交易終端系統(tǒng)登錄中臺后其算法單的母單

子單處理流程如圖，機構(gòu)交易終端系統(tǒng)通過子單的委托引用與母單委托編號一致匹配母單字單。

圖 3 算法交易處理流程

k/ >l@mn目前機構(gòu)交易接入中臺已投入生產(chǎn)使用，已支持一套 PC 交易終端直接從互聯(lián)網(wǎng)訪問和一套 PB 交易

終端,日均交易量約數(shù)千萬。中臺在測試環(huán)境已支持 3 套交易系統(tǒng)的滬深 A 股普通交易、滬深 A 股兩融交

易、港股通、ETF 申贖、期權(quán)業(yè)務(wù)接入，并完成多家 PB 交易終端接入的聯(lián)調(diào)測試工作，隨著聯(lián)調(diào)測試?yán)^續(xù)

推進，機構(gòu)交易接入中臺將進一步完善。預(yù)計在東方證券完成新一代核心業(yè)務(wù)系統(tǒng)切換時，機構(gòu)交易終端

系統(tǒng)均通過中臺接入交易系統(tǒng)，日均交易量約為數(shù)十億。

opqr-

[1] 微服務(wù)框架 gRPC 交易接入網(wǎng)關(guān)實踐 https://mp.weixin.qq.com/s/-PK26QNJy2t9p4TCTf2dEw

[2] 東方證券服務(wù)治理建設(shè)實踐 https://mp.weixin.qq.com/s/igX11UL_cbLh-UrpjK-BQg

[3] 新一代證券交易系統(tǒng)應(yīng)用架構(gòu)的研究 https://mp.weixin.qq.com/s/SAvXEkaF0ck7XXApGYgk2A

企業(yè)級證券業(yè)務(wù)中臺探索與實踐圖 3 ：算法交易處理流程

參考文獻 ：

[1] 微服務(wù)框架 gRPC 交易接入網(wǎng)關(guān)實踐 https://mp.weixin.qq.com/s/-PK26QNJy2t9p4TCTf2dEw

[2] 東方證券服務(wù)治理建設(shè)實踐 https://mp.weixin.qq.com/s/igX11UL_cbLh-UrpjK-BQg

[3] 新一代證券交易系統(tǒng)應(yīng)用架構(gòu)的研究 https://mp.weixin.qq.com/s/SAvXEkaF0ck7XXApGYgk2A

[4] 企業(yè)級證券業(yè)務(wù)中臺探索與實踐 https://mp.weixin.qq.com/s/1RL6iSHU7t8R-COk1i7kJQ

本期熱點

24

隨著上交所批處理系統(tǒng)承接的業(yè)務(wù)越來越多，為了應(yīng)對業(yè)務(wù)響應(yīng)及時性、數(shù)據(jù)維護

質(zhì)量和系統(tǒng)運行效率等方面的挑戰(zhàn)，上交所技術(shù)在借鑒主流數(shù)據(jù)處理框架優(yōu)秀設(shè)計的基礎(chǔ)

上，結(jié)合自身系統(tǒng)特性，以提高代碼復(fù)用度為目標(biāo)，開發(fā)了一套輕量級的 C++ 數(shù)據(jù)處理

框架，并且結(jié)合元數(shù)據(jù)管理，在提高數(shù)據(jù)維護質(zhì)量的同時降低了數(shù)據(jù)血緣關(guān)系維護難度。

本文從批處理系統(tǒng)面臨的實際挑戰(zhàn)出發(fā)，通過分析 Spark 等系統(tǒng)的優(yōu)勢以及自身需求，

設(shè)計和開發(fā)了批處理系統(tǒng)的數(shù)據(jù)處理框架和元數(shù)據(jù)管理模式。目前，新開發(fā)模式已投入在

創(chuàng)新業(yè)務(wù)及交易系統(tǒng)升級建設(shè)的研發(fā)工作中。

可復(fù)用數(shù)據(jù)處理框架

在證券數(shù)據(jù)處理中的探索和實踐

蔡文博、張舒、鮑倩倩、杜小靜、胡紅星 / 上交所技術(shù)有限責(zé)任公司 技術(shù)開發(fā)總部 上海 200120

E-mail ：wbcai@sse.com.cn

1、背景和挑戰(zhàn)

上交所批處理系統(tǒng)作為核心交易系統(tǒng)數(shù)據(jù)加

工及處理的重要模塊，主要承擔(dān)著交易后清結(jié)算

處理和基礎(chǔ)數(shù)據(jù)維護兩大功能。隨著創(chuàng)新業(yè)務(wù)不

斷發(fā)展及交易系統(tǒng)技術(shù)持續(xù)升級，對批處理系統(tǒng)

在業(yè)務(wù)響應(yīng)及時性、數(shù)據(jù)維護質(zhì)量、系統(tǒng)運行高

效等方面提出了更高的要求?，F(xiàn)有的批處理系統(tǒng)

已表現(xiàn)出諸多不足，主要問題有 ：一是研發(fā)效率

不高，雖然使用了相對高效易用的基礎(chǔ)庫，但業(yè)

務(wù)應(yīng)用抽象程度低，代碼復(fù)用程度低，進而導(dǎo)致

創(chuàng)新業(yè)務(wù)需求響應(yīng)能力差 ；二是缺乏統(tǒng)一的數(shù)據(jù)

標(biāo)準(zhǔn)，目前各接口獨立定義字段，導(dǎo)致定義工作

重復(fù)、同一字段在不同接口命名不一致，增加系

統(tǒng)維護成本，降低數(shù)據(jù)整體質(zhì)量 ；三是數(shù)據(jù)血緣

關(guān)系維護難度大，隨著批處理系統(tǒng)承載的業(yè)務(wù)越

交易技術(shù)前沿

25

來越多，數(shù)據(jù)處理流程越來越復(fù)雜，準(zhǔn)確全面維

護血緣關(guān)系的難度也越來越大。

近年來，上交所持續(xù)推進數(shù)字化轉(zhuǎn)型，積極

助力科技賦能，批處理系統(tǒng)技術(shù)服務(wù)能力和數(shù)據(jù)

管理水平亟待升級。為解決以上問題，批處理系

統(tǒng)啟動研發(fā)輕量級數(shù)據(jù)處理框架，既易于與現(xiàn)有

技術(shù)體系融合，又便于數(shù)據(jù)血緣關(guān)系的提取。首

先考察主流的數(shù)據(jù)處理框架，如 Spark，F(xiàn)link 等，

在借鑒其關(guān)于數(shù)據(jù)算子抽象的基礎(chǔ)上，設(shè)計開發(fā)

C++ 語言的數(shù)據(jù)處理框架。通過對業(yè)務(wù)邏輯的抽

象與封裝，形成可復(fù)用的功能組件，沉淀技術(shù)共

享能力，進一步提高研發(fā)效率。此外，結(jié)合數(shù)據(jù)

標(biāo)準(zhǔn)及元數(shù)據(jù)管理，設(shè)計了包含數(shù)據(jù)元、字段、

模型、物理表 / 文件等四層結(jié)構(gòu)的維護模式，確

保字段在所有模型中均有一致的定義，有助于提

高數(shù)據(jù)質(zhì)量。

2、數(shù)據(jù)處理框架

2.1 整體架構(gòu)

上交所批處理系統(tǒng)的數(shù)據(jù)處理框架整體可分

為組件層和存儲抽象層。組件層包含基礎(chǔ)組件層

和功能組件層，其中基礎(chǔ)組件提供原始的數(shù)據(jù)處

理語義，如過濾、聯(lián)合、映射、分組等 ；功能組

件是對基礎(chǔ)組件的組合，實現(xiàn)一個完整的數(shù)據(jù)轉(zhuǎn)

換功能，如表 A 數(shù)據(jù)關(guān)聯(lián)更新表 B 數(shù)據(jù)、表數(shù)

據(jù)格式轉(zhuǎn)換后導(dǎo)入文件等。存儲抽象層則定義了

統(tǒng)一的數(shù)據(jù)訪問接口，如讀取、寫入、查找、更

新等，使組件層可以無差別的處理文件、數(shù)據(jù)庫

表、共享內(nèi)存庫、Map 等多種存儲形式中的數(shù)據(jù)。

應(yīng)用層的業(yè)務(wù)邏輯通常使用預(yù)定義的功能組

件實現(xiàn)，特殊情況下可直接組合基礎(chǔ)組件實現(xiàn)。

存儲抽象層屏蔽了存儲介質(zhì)的差異，使框架易于

加強代碼可復(fù)用能力，降低開發(fā)及測試成本?？蚣艿恼w層次如圖 2.1 所示。

圖 2.1 數(shù)據(jù)處理框架整體架構(gòu)圖

2.2 ;<=>?

存儲抽象層為不同存儲介質(zhì)（如文件、數(shù)據(jù)表、Map 容器等）中的數(shù)據(jù)提供統(tǒng)一的訪問接口。對數(shù)據(jù)

圖 2.1 ：數(shù)據(jù)處理框架整體架構(gòu)圖

本期熱點

26

融入現(xiàn)有的技術(shù)體系 ；組件層則主要體現(xiàn)了業(yè)務(wù)

邏輯的抽象與復(fù)用，加強代碼可復(fù)用能力，降低

開發(fā)及測試成本?？蚣艿恼w層次如圖 2.1 所示。

2.2 存儲抽象層

存儲抽象層為不同存儲介質(zhì)（如文件、數(shù)據(jù)

表、Map 容器等）中的數(shù)據(jù)提供統(tǒng)一的訪問接口。

對數(shù)據(jù)處理框架而言，一方面屏蔽了存儲介質(zhì)特

性，使組件層可以無差別地處理各種存儲形式的

數(shù)據(jù) ；另一方面應(yīng)用層無需關(guān)心存儲特性，提高

了應(yīng)用批業(yè)務(wù)表達的清晰度。

技術(shù)實現(xiàn)上，不同的存儲類均實現(xiàn) Storage

接口，類層級關(guān)系如圖 2.2 所示。根據(jù)存儲介質(zhì)

的特性，并非所有接口都要實現(xiàn)，比如文件存儲

類（CBatFileStorage）無需實現(xiàn)查找和更新接口。

2.3 組件層

2.3.1 基礎(chǔ)組件

基礎(chǔ)組件是對常見批量數(shù)據(jù)處理動作的提

煉，描述了一次數(shù)據(jù)集的轉(zhuǎn)換?；A(chǔ)組件類似

Spark 和數(shù)據(jù)庫中的算子（Operator）概念。

主要基礎(chǔ)組件及其功能如下表 2.1 所示。

圖 2.1 數(shù)據(jù)處理框架整體架構(gòu)圖

2.2 ;<=>?

存儲抽象層為不同存儲介質(zhì)（如文件、數(shù)據(jù)表、Map 容器等）中的數(shù)據(jù)提供統(tǒng)一的訪問接口。對數(shù)據(jù)

處理框架而言，一方面屏蔽了存儲介質(zhì)特性，使組件層可以無差別地處理各種存儲形式的數(shù)據(jù)；另一方面

應(yīng)用層無需關(guān)心存儲特性，提高了應(yīng)用批業(yè)務(wù)表達的清晰度。

技術(shù)實現(xiàn)上，不同的存儲類均實現(xiàn) Storage 接口，類層級關(guān)系如圖 2.2 所示。根據(jù)存儲介質(zhì)的特性，并

非所有接口都要實現(xiàn)，比如文件存儲類（CBatFileStorage）無需實現(xiàn)查找和更新接口。

圖 2.2 ： 類層級關(guān)系

圖 2.2 類層級關(guān)系

2.3 @A?

2.3.1基礎(chǔ)組件

基礎(chǔ)組件是對常見批量數(shù)據(jù)處理動作的提煉，描述了一次數(shù)據(jù)集的轉(zhuǎn)換?；A(chǔ)組件類似 Spark 和數(shù)據(jù)

庫中的算子（Operator）概念。

主要基礎(chǔ)組件及其功能如下表 2.1 所示。

表 2.1 基礎(chǔ)組件及其功能

基礎(chǔ)組件 功能簡介

Aggregate 支持?jǐn)?shù)據(jù)聚合操作

DataSource 用于指定源數(shù)據(jù)集

CreateView 創(chuàng)建數(shù)據(jù)庫視圖

Expand 支持?jǐn)?shù)據(jù)擴展操作

Filter 根據(jù)某一條件過濾數(shù)據(jù)集

Groupby 將數(shù)據(jù)集按某一條件分組，并執(zhí)行后續(xù)操作

Import 支持批量導(dǎo)入數(shù)據(jù)

Insert 支持?jǐn)?shù)據(jù)插入

Join 支持?jǐn)?shù)據(jù)集聯(lián)合

Orderby 支持?jǐn)?shù)據(jù)集排序

Update 用于數(shù)據(jù)更新

Upsert 存在即更新，不存在即插入

Validate 支持?jǐn)?shù)據(jù)校驗

基礎(chǔ)組件具備以下三個特征：

·可組合性?；A(chǔ)組件輸入輸出接口的一致性保證了其可組合性，基礎(chǔ)組件的可組合性是實現(xiàn)復(fù)雜數(shù)

據(jù)處理邏輯的基礎(chǔ)。

·可復(fù)用性。單個基礎(chǔ)組件是對一類數(shù)據(jù)操作的抽象和提煉，實際使用時根據(jù)具體場景對其實例化。

表 2.1 ：基礎(chǔ)組件及其功能

交易技術(shù)前沿

27

基礎(chǔ)組件具備以下三個特征 ：

? 可組合性?；A(chǔ)組件輸入輸出接口的一致

性保證了其可組合性，基礎(chǔ)組件的可組合性是實

現(xiàn)復(fù)雜數(shù)據(jù)處理邏輯的基礎(chǔ)。

? 可復(fù)用性。單個基礎(chǔ)組件是對一類數(shù)據(jù)操

作的抽象和提煉，實際使用時根據(jù)具體場景對其

實例化。

? 可擴展性。新的數(shù)據(jù)處理模式可以通過開

發(fā)新的基礎(chǔ)組件來支持，且由于組件的可組合性，

新組件可獲得更廣的應(yīng)用范圍。

2.3.2 功能組件

功能組件以具體的數(shù)據(jù)轉(zhuǎn)換模式為基礎(chǔ)，統(tǒng)

一代碼模式，內(nèi)化實現(xiàn)細(xì)節(jié)，僅表達數(shù)據(jù)轉(zhuǎn)換關(guān)

鍵信息，清晰地表達數(shù)據(jù)的變更方向和變更方式，

使代碼的業(yè)務(wù)表達能力更精練。組件的標(biāo)準(zhǔn)化和

可復(fù)用性有效提高了代碼的利用率，減少了應(yīng)用

代碼的冗余度，對提高開發(fā)效率具有積極意義。

功能組件一般描述了數(shù)據(jù)從一個載體到另一

個載體的轉(zhuǎn)換過程。組件并不關(guān)心載體具體是什

么，重點是轉(zhuǎn)換過程。比如同一個組件既可以處

理文件數(shù)據(jù)經(jīng)過過濾后導(dǎo)入 Map 的過程，又可以

處理表數(shù)據(jù)經(jīng)過過濾后導(dǎo)入文件的過程。如前所

述，功能組件都是由一系列基礎(chǔ)組件組合而成。

圖 2.3 展例了兩個功能組件實現(xiàn)。

? 功能組件 1 ：適用于需要過濾源頭數(shù)據(jù)集

圖 2.3 功能組件示例

·功能組件 1：適用于需要過濾源頭數(shù)據(jù)集的場景。如篩選出輸入產(chǎn)品全量數(shù)據(jù)中的所有股票產(chǎn)品并

插入數(shù)據(jù)庫表。

·功能組件 2：適用于目標(biāo)數(shù)據(jù)集為源數(shù)據(jù)集和中間數(shù)據(jù)集聯(lián)合的場景。如在展開賬戶對所有產(chǎn)品子

類型的權(quán)限并插入到進程 map 的需求中，使用 cross join 操作。

根據(jù)實際業(yè)務(wù)場景，選擇合適的功能組件是實現(xiàn)應(yīng)用業(yè)務(wù)處理的關(guān)鍵點。當(dāng)功能組件不滿足業(yè)務(wù)場景

時，可通過組合基礎(chǔ)組件開發(fā)新的功能組件。以具體業(yè)務(wù)場景為示例，圖 2.4 展示了具體的業(yè)務(wù)場景衍生

出的功能組件和基礎(chǔ)組件的關(guān)系。

圖 2.4 業(yè)務(wù)場景與組件關(guān)系

功能組件根據(jù)執(zhí)行模式可分為兩種。一種是在內(nèi)存中迭代執(zhí)行，另一種是轉(zhuǎn)換成 SQL 后在數(shù)據(jù)庫內(nèi)執(zhí)

行。下面分別介紹兩種執(zhí)行模式的執(zhí)行步驟。

迭代執(zhí)行模式圖 2.3 功能組件示例

·功能組件 1：適用于需要過濾源頭數(shù)據(jù)集的場景。如篩選出輸入產(chǎn)品全量數(shù)據(jù)中的所有股票產(chǎn)品并

插入數(shù)據(jù)庫表。

·功能組件 2：適用于目標(biāo)數(shù)據(jù)集為源數(shù)據(jù)集和中間數(shù)據(jù)集聯(lián)合的場景。如在展開賬戶對所有產(chǎn)品子

類型的權(quán)限并插入到進程 map 的需求中，使用 cross join 操作。

根據(jù)實際業(yè)務(wù)場景，選擇合適的功能組件是實現(xiàn)應(yīng)用業(yè)務(wù)處理的關(guān)鍵點。當(dāng)功能組件不滿足業(yè)務(wù)場景

時，可通過組合基礎(chǔ)組件開發(fā)新的功能組件。以具體業(yè)務(wù)場景為示例，圖 2.4 展示了具體的業(yè)務(wù)場景衍生

出的功能組件和基礎(chǔ)組件的關(guān)系。

圖 2.3 ：功能組件示例

圖 2.4 ：業(yè)務(wù)場景與組件關(guān)系

本期熱點

28

的場景。如篩選出輸入產(chǎn)品全量數(shù)據(jù)中的所有股

票產(chǎn)品并插入數(shù)據(jù)庫表。

? 功能組件 2 ：適用于目標(biāo)數(shù)據(jù)集為源數(shù)據(jù)

集和中間數(shù)據(jù)集聯(lián)合的場景。如在展開賬戶對所

有產(chǎn)品子類型的權(quán)限并插入到進程 map 的需求

中，使用 cross join 操作。

根據(jù)實際業(yè)務(wù)場景，選擇合適的功能組件是

實現(xiàn)應(yīng)用業(yè)務(wù)處理的關(guān)鍵點。當(dāng)功能組件不滿足

業(yè)務(wù)場景時，可通過組合基礎(chǔ)組件開發(fā)新的功能

組件。以具體業(yè)務(wù)場景為示例，圖 2.4 展示了具體

的業(yè)務(wù)場景衍生出的功能組件和基礎(chǔ)組件的關(guān)系。

功能組件根據(jù)執(zhí)行模式可分為兩種。一種是

在內(nèi)存中迭代執(zhí)行，另一種是轉(zhuǎn)換成 SQL 后在數(shù)

據(jù)庫內(nèi)執(zhí)行。下面分別介紹兩種執(zhí)行模式的執(zhí)行

步驟。

一、迭代執(zhí)行模式

下面以圖 2.3 中的功能組件 2 為例展示迭代

執(zhí)行的機制。

圖 2.5 迭代執(zhí)行模式

引用關(guān)系，箭頭表示下游節(jié)點對上游節(jié)點的引用；藍線是函數(shù)調(diào)用執(zhí)行的順序

載IterateExecute 函數(shù)（如圖 2.3），且都由 save() 接口觸發(fā)。執(zhí)行規(guī)則是下游節(jié)

數(shù)據(jù)（query），直到最上游的算子節(jié)點直接從源數(shù)據(jù)集中取到數(shù)據(jù)，然后數(shù)據(jù)經(jīng)

turn）最下游的算子節(jié)點。為避免對內(nèi)存過多的占用，數(shù)據(jù)以分批的形式在各節(jié)圖 2.5 ：迭代執(zhí)行模式

紅線表示節(jié)點引用關(guān)系，箭頭表示下游節(jié)點

對上游節(jié)點的引用 ；藍線是函數(shù)調(diào)用執(zhí)行的順序

迭代執(zhí)行的組件都重載 IterateExecute 函數(shù)

（如圖 2.3），且都由 save() 接口觸發(fā)。執(zhí)行規(guī)則

是下游節(jié)點遞歸的向上游節(jié)點請求數(shù)據(jù)（query），

直到最上游的算子節(jié)點直接從源數(shù)據(jù)集中取到數(shù)

據(jù)，然后數(shù)據(jù)經(jīng)過各級節(jié)點處理后返回（return）

最下游的算子節(jié)點。為避免對內(nèi)存過多的占用，

數(shù)據(jù)以分批的形式在各節(jié)點間傳遞。同時，為避

免數(shù)據(jù)在各節(jié)點間過多拷貝，節(jié)點間傳遞的是數(shù)

據(jù)指針，且多數(shù)節(jié)點不緩存數(shù)據(jù)。例外的是映射

節(jié)點（project），因為涉及到數(shù)據(jù)結(jié)構(gòu)的變動，映

射節(jié)點將緩存新結(jié)構(gòu)的數(shù)據(jù)，并向下游傳遞新數(shù)

據(jù)的指針。

二、數(shù)據(jù)庫執(zhí)行模式

與迭代執(zhí)行不同，數(shù)據(jù)庫執(zhí)行的組件都重載

DbExecute，且都由 doDbExecute 觸發(fā)，如組件 3

所示（圖 2.6）。

圖 2.7 展示數(shù)據(jù)庫執(zhí)行的機制。

數(shù)據(jù)庫執(zhí)行組件先將數(shù)據(jù)處理流程編譯成

SQL 語句，然后在數(shù)據(jù)庫中執(zhí)行對應(yīng) SQL。SQL

的編譯過程借鑒 SQLAchemy 項目的思路，主

要應(yīng)用了 Visitor 設(shè)計模式。每個算子節(jié)點可接

收一個 Visitor 對象，并把其參數(shù)傳給 Visitor 對

象。在上圖的例子中，Insert 算子通過 visit_insert

接口把目的表信息傳遞給 SqlVisitor ；Project 算

子把字段映射關(guān)系通過 visit_project 接口傳遞給

SqlVisitor ；Join 算子把關(guān)聯(lián)的左表和右表以及關(guān)

聯(lián)條件傳遞給 SqlVisitor。通過遍歷整個數(shù)據(jù)流中

的節(jié)點，SqlVisitor 收集到所有的表操作要素并放

在其內(nèi)部的 SqlBuilder 中，最后由 SqlBuilder 將

表操作要素編譯成 SQL 語句。

2.4 應(yīng)用示例

對于實際的盤后批處理應(yīng)用，可將一個批

（Job）的業(yè)務(wù)功能拆分成多個步驟的數(shù)據(jù)集轉(zhuǎn)換

（Stage），每個 Stage 由單個功能組件實現(xiàn)，完成

一次數(shù)據(jù)集的轉(zhuǎn)換。多個 Stage 順序執(zhí)行最終完

成目的數(shù)據(jù)集的生成。

Step1 ：為 DatasetContext 對 象 提 供 上 下 文

參數(shù)，構(gòu)造初始數(shù)據(jù)集對象（Dataset）。構(gòu)造

Dataset 時需指定其存儲類型、存儲資源 ID、數(shù)

據(jù)結(jié)構(gòu)（C-Struct）等信息。這些數(shù)據(jù)集既包含

交易技術(shù)前沿

29

二、數(shù)據(jù)庫執(zhí)行模式

與迭代執(zhí)行不同，數(shù)據(jù)庫執(zhí)行的組件都重載 DbExecute，且都由 doDbExecute 觸發(fā)，如組件 3 所示（圖

2.6）。

圖 2.6 數(shù)據(jù)庫功能組件

下圖 2.7 展示數(shù)據(jù)庫執(zhí)行的機制。

例外的是映射節(jié)點（project），因為涉及到數(shù)據(jù)結(jié)構(gòu)的變動，映射節(jié)點將緩存新結(jié)構(gòu)的數(shù)據(jù)，并向下游傳遞

新數(shù)據(jù)的指針。

二、數(shù)據(jù)庫執(zhí)行模式

與迭代執(zhí)行不同，數(shù)據(jù)庫執(zhí)行的組件都重載 DbExecute，且都由 doDbExecute 觸發(fā)，如組件 3 所示（圖

2.6）。

圖 2.6 數(shù)據(jù)庫功能組件

下圖 2.7 展示數(shù)據(jù)庫執(zhí)行的機制。

圖 2.6 ：數(shù)據(jù)庫功能組件

圖 2.7 ：數(shù)據(jù)庫執(zhí)行模式

紅線表示節(jié)點引用關(guān)系，箭頭表示下游節(jié)點對上游節(jié)點的引用；藍線是函數(shù)調(diào)用

執(zhí)行的順序

圖 2.7 數(shù)據(jù)庫執(zhí)行模式

紅線表示節(jié)點引用關(guān)系，箭頭表示下游節(jié)點對上游節(jié)點的引用；藍線是函數(shù)調(diào)用執(zhí)行的順序

數(shù)據(jù)庫執(zhí)行組件先將數(shù)據(jù)處理流程編譯成 SQL 語句，然后在數(shù)據(jù)庫中執(zhí)行對應(yīng) SQL。SQL 的編譯過

程借鑒 SQLAchemy 項目的思路，主要應(yīng)用了 Visitor 設(shè)計模式。每個算子節(jié)點可接收一個 Visitor 對象，并

把其參數(shù)傳給 Visitor 對象。在上圖的例子中，Insert 算子通過 visit_insert 接口把目的表信息傳遞給 SqlVisitor；

Project 算子把字段映射關(guān)系通過 visit_project 接口傳遞給 SqlVisitor；Join 算子把關(guān)聯(lián)的左表和右表以及關(guān)

聯(lián)條件傳遞給 SqlVisitor。通過遍歷整個數(shù)據(jù)流中的節(jié)點，SqlVisitor 收集到所有的表操作要素并放在其內(nèi)部

的 SqlBuilder 中，最后由 SqlBuilder 將表操作要素編譯成 SQL 語句。

2.4 B#CD

對于實際的盤后批處理應(yīng)用，可將一個批（Job）的業(yè)務(wù)功能拆分成多個步驟的數(shù)據(jù)集轉(zhuǎn)換（Stage），

每個 Stage 由單個功能組件實現(xiàn)，完成一次數(shù)據(jù)集的轉(zhuǎn)換。多個 Stage 順序執(zhí)行最終完成目的數(shù)據(jù)集的生成。

圖 2.8 應(yīng)用示例解析

Step1：為 DatasetContext 對象提供上下文參數(shù)，構(gòu)造初始數(shù)據(jù)集對象（Dataset）。構(gòu)造 Dataset 時需指

定其存儲類型、存儲資源 ID、數(shù)據(jù)結(jié)構(gòu)（C-Struct）等信息。這些數(shù)據(jù)集既包含輸入數(shù)據(jù)集也包含輸出數(shù)

據(jù)集圖 2.8 ：應(yīng)用示例解析

本期熱點

30

輸入數(shù)據(jù)集也包含輸出數(shù)據(jù)集。

Step2 ：按順序執(zhí)行每個 Stage 的功能組件。

每個功能組件完成一個目標(biāo)數(shù)據(jù)集數(shù)據(jù)的生成。

前面 Stage 的目標(biāo)數(shù)據(jù)集可作為后續(xù) Stage 的源數(shù)

據(jù)集。數(shù)據(jù)集的讀寫均通過Storage接口統(tǒng)一完成。

2.5 代碼生成

由于批任務(wù)代碼基于預(yù)定義的組件，且代碼

結(jié)構(gòu)有較強的規(guī)律性，我們在此基礎(chǔ)上設(shè)計了一

套 Yaml 配置規(guī)則，并開發(fā)了配套的代碼生成程

序，支持將 Yaml 配置翻譯成批任務(wù)代碼。其收

益包括 ：一方面進一步提高了業(yè)務(wù)開發(fā)人員的編

碼效率 ；另一方面在于將業(yè)務(wù)邏輯結(jié)構(gòu)化處理，

支持后續(xù)對業(yè)務(wù)邏輯的進一步解析與應(yīng)用，生成

數(shù)據(jù)的血緣關(guān)系。如圖 2.9 所示，左邊為 Yaml

配置，右邊為生成的批任務(wù)代碼。

3、元數(shù)據(jù)管理

3.1 數(shù)據(jù)模型構(gòu)建

批處理系統(tǒng)承載交易系統(tǒng)文件聚合、轉(zhuǎn)發(fā)等

業(yè)務(wù)功能，具有數(shù)據(jù)量大、數(shù)據(jù)結(jié)構(gòu)復(fù)雜等特點。

批處理系統(tǒng)強化數(shù)據(jù)標(biāo)準(zhǔn)體系建設(shè)工作，在業(yè)務(wù)

層面，有助于明確業(yè)務(wù)含義，明確業(yè)務(wù)與業(yè)務(wù)間、

業(yè)務(wù)與技術(shù)間統(tǒng)一口徑與認(rèn)識 ；在技術(shù)層面，有

助于構(gòu)建規(guī)范的物理數(shù)據(jù)模型，提供對數(shù)據(jù)元的

格式規(guī)范，進而提高數(shù)據(jù)質(zhì)量水平 ；此外，有助

于配合與對接所級別數(shù)據(jù)標(biāo)準(zhǔn)的建設(shè)。

目前，批處理中心使用數(shù)據(jù)元定義、字段定

義、模型定義、文件 / 數(shù)據(jù)表定義的遞進引用結(jié)

構(gòu)（如圖 3.1），對系統(tǒng)所使用的元數(shù)據(jù)進行管理

與維護。

圖 2.9 業(yè)務(wù)配置與代碼生成

3 I$%J'

3.1 $%KL:M

批處理系統(tǒng)承載交易系統(tǒng)文件聚合、轉(zhuǎn)發(fā)等業(yè)務(wù)功能，具有數(shù)據(jù)量大、數(shù)據(jù)結(jié)構(gòu)復(fù)雜等特點。批系統(tǒng)強化數(shù)據(jù)標(biāo)準(zhǔn)體系建設(shè)工作，在業(yè)務(wù)層面，有助于明確業(yè)務(wù)含義，明確業(yè)務(wù)與業(yè)務(wù)間、業(yè)務(wù)與技統(tǒng)一口徑與認(rèn)識；在技術(shù)層面，有助于構(gòu)建規(guī)范的物理數(shù)據(jù)模型，提供對數(shù)據(jù)元的格式規(guī)范，進而提據(jù)質(zhì)量水平；此外，有助于配合與對接所級別數(shù)據(jù)標(biāo)準(zhǔn)的建設(shè)。

目前，批處理中心使用數(shù)據(jù)元定義、字段定義、模型定義、文件/數(shù)據(jù)表定義的遞進引用結(jié)構(gòu)（如圖 對系統(tǒng)所使用的元數(shù)據(jù)進行管理與維護。

圖 3.1 遞進引用結(jié)構(gòu)

其中，數(shù)據(jù)元是數(shù)據(jù)標(biāo)準(zhǔn)定義的基本單位。以標(biāo)準(zhǔn)數(shù)據(jù)類型為基準(zhǔn)，建立數(shù)據(jù)標(biāo)準(zhǔn)體系。數(shù)據(jù)元主題大類、主題子類劃分類別（詳見表 3.1）。

字段在數(shù)據(jù)元基礎(chǔ)上進行定義，同一個數(shù)據(jù)元可擁有多個字段，多個字段可指向同一數(shù)據(jù)元。同圖 3.1 ：遞進引用結(jié)構(gòu)

圖 2.9 業(yè)務(wù)配置與代碼生成

3 I$%J'

圖 2.9 ：業(yè)務(wù)配置與代碼生成

交易技術(shù)前沿

31

其中，數(shù)據(jù)元是數(shù)據(jù)標(biāo)準(zhǔn)定義的基本單位。

以標(biāo)準(zhǔn)數(shù)據(jù)類型為基準(zhǔn)，建立數(shù)據(jù)標(biāo)準(zhǔn)體系。數(shù)

據(jù)元按照主題大類、主題子類劃分類別（詳見表

3.1）。

字段在數(shù)據(jù)元基礎(chǔ)上進行定義，同一個數(shù)據(jù)

元可擁有多個字段，多個字段可指向同一數(shù)據(jù)元。

同一數(shù)據(jù)元僅有一個標(biāo)準(zhǔn)格式字段 ；可擁有多個

擴展格式字段 ；其中，在模型設(shè)計規(guī)范中定義 ：

批處理系統(tǒng)內(nèi)部維護的字段均為標(biāo)準(zhǔn)格式字段。

若輸入接口中的字段非標(biāo)準(zhǔn)格式，其進入系統(tǒng)內(nèi)

部模型前需轉(zhuǎn)換為標(biāo)準(zhǔn)格式 ；若輸出接口中的字

段為非標(biāo)準(zhǔn)格式，需將內(nèi)部模型中的標(biāo)準(zhǔn)格式字

段轉(zhuǎn)換為輸出接口要求的格式。

模型是由字段組合形成的邏輯概念 ；文件、

數(shù)據(jù)表在邏輯模型的基礎(chǔ)上定義，增加落地的物

理屬性。同一個模型可被定義為多個文件 / 數(shù)據(jù)

表實體。

3.2 配置自動生成

數(shù)據(jù)元配置可自動化生成文件 / 數(shù)據(jù)表等

模型的接口文件。目前支持生成文件結(jié)構(gòu)接口、

數(shù)據(jù)表結(jié)構(gòu)接口、SQL 建表語句等。既減輕了

開發(fā)人員的工作量，另一方面保證了元數(shù)據(jù)與

代碼結(jié)構(gòu)的同源性，提升研發(fā)效率的同時有效

提高數(shù)據(jù)維護質(zhì)量。配置自動生成說明如表 3.2

所示。

在后續(xù)工作中，批處理系統(tǒng)將持續(xù)加強對元

數(shù)據(jù)組織方式、標(biāo)準(zhǔn)及規(guī)范定義、評審流程等工

作的完善，形成高效可控的管理機制。

4、血緣關(guān)系提取

上交所批處理系統(tǒng)涉及的證券數(shù)據(jù)，主要有

以下特征 ：一、業(yè)務(wù)繁多，幾乎所有業(yè)務(wù)均包含

盤后處理；二、相關(guān)方多，上下游交互系統(tǒng)較多，

主要包含外部對等機構(gòu)、所內(nèi)業(yè)務(wù)系統(tǒng)、市場這

三大類 ；三、業(yè)務(wù)規(guī)則變更、所內(nèi)外接口變更較

頻繁，影響評估工作量大 ；四、盤后批處理應(yīng)急

場景多，亟需高效的影響評估手段。

基于以上交易系統(tǒng)盤后批處理數(shù)據(jù)及業(yè)務(wù)特

征，通過維護數(shù)據(jù)血緣關(guān)系，可有效提高數(shù)據(jù)變

更影響評估的效率和準(zhǔn)確度 ；生產(chǎn)應(yīng)急情況下，

應(yīng)急時間窗口緊張，短時間內(nèi)人工評估數(shù)據(jù)影響

容易錯漏，提供自動化手段可提高運維效率 ；方

據(jù)元僅有一個標(biāo)準(zhǔn)格式字段；可擁有多個擴展格式字段；其中，在模型設(shè)計規(guī)范中定義：批處理系統(tǒng)內(nèi)部

維護的字段均為標(biāo)準(zhǔn)格式字段。若輸入接口中的字段非標(biāo)準(zhǔn)格式，其進入系統(tǒng)內(nèi)部模型前需轉(zhuǎn)換為標(biāo)準(zhǔn)格

式；若輸出接口中的字段為非標(biāo)準(zhǔn)格式，需將內(nèi)部模型中的標(biāo)準(zhǔn)格式字段轉(zhuǎn)換為輸出接口要求的格式。

模型是由字段組合形成的邏輯概念；文件、數(shù)據(jù)表在邏輯模型的基礎(chǔ)上定義，增加落地的物理屬性。

同一個模型可被定義為多個文件/數(shù)據(jù)表實體。

表 3.1 數(shù)據(jù)模型分級試圖

邏輯主題 主題大類 主題子類

市場參與者

賬戶信息

賬戶基礎(chǔ)信息

賬戶指定關(guān)系

賬戶權(quán)限

持有 賬戶持倉

機構(gòu)

機構(gòu)信息 機構(gòu)基礎(chǔ)信息

PBU 信息

PBU 基礎(chǔ)信息

PBU 產(chǎn)品業(yè)務(wù)權(quán)限

產(chǎn)品

產(chǎn)品信息 基礎(chǔ)信息

產(chǎn)品業(yè)務(wù)信息

產(chǎn)品業(yè)務(wù)交易參數(shù)

產(chǎn)品業(yè)務(wù)平臺對應(yīng)關(guān)系

業(yè)務(wù) 業(yè)務(wù)信息

業(yè)務(wù)基礎(chǔ)信息

業(yè)務(wù)時間表

市場 市場信息

交易日歷

全局交易時間表

3.2 NOPQGH

數(shù)據(jù)元配置可自動化生成文件/數(shù)據(jù)表等模型的接口文件目前支持生成文件結(jié)構(gòu)接口數(shù)據(jù)表結(jié)構(gòu)接表 3.1 ：數(shù)據(jù)模型分級試圖

本期熱點

32

便業(yè)務(wù)理解，提高需求分析、運維工作效率和工

作質(zhì)量。

4.1 提取方式

常見的數(shù)據(jù)血緣關(guān)系提取主要以解析 SQL

為主。通過遍歷 SQL 的抽象語法樹（AST）分析

數(shù)據(jù)血緣關(guān)系。但是批處理系統(tǒng)除了有基于數(shù)據(jù)

庫的數(shù)據(jù)處理，還有基于文件和內(nèi)存的處理過程，

這些處理過程無法用 SQL 體現(xiàn)。因此通過解析體

現(xiàn)業(yè)務(wù)邏輯的 Yaml 配置可以獲得更為完整的數(shù)

據(jù)血緣關(guān)系。

與代碼生成邏輯類似，通過解析每個數(shù)據(jù)

處理流程的 From、Join、Insert、Update 等節(jié)點

的數(shù)據(jù)集信息可以獲取文件和表級別的血緣關(guān)

系（粗粒度）。進一步解析 Insert 和 Update 等節(jié)

點的字段賦值關(guān)系可以收集字段級別的血緣關(guān)

系（細(xì)粒度）。

一、文件 / 表級別

任務(wù)包含多個輸入和輸出，通過建立文件 /

數(shù)據(jù)表的血緣關(guān)系，便于分析數(shù)據(jù)流向，了解數(shù)

據(jù)的重要程度，為相關(guān)業(yè)務(wù)決策提供參考基礎(chǔ)。

特別對于上下游系統(tǒng)交互較多的多任務(wù)處理系

統(tǒng)，當(dāng)生產(chǎn)環(huán)境上游文件未及時到達，能迅速進

行影響分析，為應(yīng)急處置提供幫助。目前我們已

經(jīng)完成粗粒度血緣關(guān)系提取工具的開發(fā)，并將血

緣關(guān)系導(dǎo)入到了 Apache Atlas 平臺。下圖 4.1 展

示了港股通限制產(chǎn)品導(dǎo)出功能的文件、表與批任

務(wù)的血緣關(guān)系。

二、字段級別

交易系統(tǒng)基于數(shù)據(jù)處理，海量交易數(shù)據(jù)分散

在多個系統(tǒng)，實際場景中經(jīng)常會遇到分析字段變

更的影響范圍、字段來源于哪里等問題。因此，

分析字段間的血緣關(guān)系變得尤為重要。通過分析

批業(yè)務(wù)配置中文件或表字段賦值的關(guān)系，可以生

成細(xì)粒度 column 級別的字段流向樹。圖 4.2 為

mem_code（會員代碼）字段的血緣圖譜分析結(jié)果。

后續(xù)將開發(fā)字段級別血緣關(guān)系的自動化的提取工

具，完善細(xì)粒度血緣關(guān)系的展示。

血緣關(guān)系的維護對后續(xù)構(gòu)建交易系統(tǒng)業(yè)務(wù)畫

像、優(yōu)化系統(tǒng)業(yè)務(wù)架構(gòu)和性能、分析數(shù)據(jù)變更對

系統(tǒng)造成的影響評估等方面起到更大應(yīng)用。

5、總結(jié)與展望

在借鑒主流數(shù)據(jù)處理框架優(yōu)秀設(shè)計的基礎(chǔ)

上，結(jié)合上交所批處理系統(tǒng)特性自研了一套數(shù)據(jù)

處理框架。一方面可以與批處理系統(tǒng)現(xiàn)有的技術(shù)

更好的融合 ；另一方面無需獨立的運行時環(huán)境，

避免額外的運維負(fù)擔(dān) ；數(shù)據(jù)處理框架同時支持內(nèi)

存迭代執(zhí)行和數(shù)據(jù)庫 SQL 執(zhí)行兩種模式，統(tǒng)一了

數(shù)據(jù)庫外和數(shù)據(jù)庫內(nèi)兩種數(shù)據(jù)處理模式的表達方

式。最后，元數(shù)據(jù)管理不但統(tǒng)一了字段的業(yè)務(wù)含

表 3.2 ：配置自動生成說明

3.2 NOPQGH

數(shù)據(jù)元配置可自動化生成文件/數(shù)據(jù)表等模型的接口文件。目前支持生成文件結(jié)構(gòu)接口、數(shù)據(jù)表結(jié)構(gòu)接

口、SQL 建表語句等。既減輕了開發(fā)人員的工作量，另一方面保證了元數(shù)據(jù)與代碼結(jié)構(gòu)的同源性，提升研

發(fā)效率的同時有效提高數(shù)據(jù)維護質(zhì)量。配置自動生成說明如表 3.2 所示。

在后續(xù)工作中，批處理系統(tǒng)將持續(xù)加強對元數(shù)據(jù)組織方式、標(biāo)準(zhǔn)及規(guī)范定義、評審流程等工作的完善，

形成高效可控的管理機制。

表 3.2 配置自動生成說明

使用場景 生成物名稱 生成物用途

數(shù)據(jù)庫表注冊信息

table_info_list.cpp 數(shù)據(jù)表與結(jié)構(gòu)體對應(yīng)關(guān)系

refdata_table_list.cpp 數(shù)據(jù)表分類情況

table_id_enum.hpp 數(shù)據(jù)表 ID 注冊

table_flag_index.h 數(shù)據(jù)表 flag 文件注冊

數(shù)據(jù)庫表、視圖接口 db_interface_<tablename>.hpp 數(shù)據(jù)庫表結(jié)構(gòu)&建表語句定義

<tablename>.h 數(shù)據(jù)庫表就緒通知文件

文件接口 ifm_<filename>.h 文件結(jié)構(gòu)定義

from/to_<filename>.h 文件路徑等屬性定義

模型文檔

tables.xls 數(shù)據(jù)表接口文檔

files.xls 文件接口文檔

4 RSTUVW

上交所批處理系統(tǒng)涉及的證券數(shù)據(jù)，主要有以下特征：一、業(yè)務(wù)繁多，幾乎所有業(yè)務(wù)均包含盤后處理；

交易技術(shù)前沿

33

義和技術(shù)定義，也使接口代碼可自動化生成，提

高了開發(fā)效率和準(zhǔn)確度。

目前批處理系統(tǒng)已經(jīng)使用新的開發(fā)模式投入

創(chuàng)新業(yè)務(wù)及交易系統(tǒng)升級建設(shè)的研發(fā)工作中，基

本實現(xiàn)代碼復(fù)用、自動化的血緣關(guān)系提取以及提

高數(shù)據(jù)維護質(zhì)量的目標(biāo)。將在后續(xù)業(yè)務(wù)支持過程

中持續(xù)完善數(shù)據(jù)處理功能，并探索把數(shù)據(jù)處理框

架的應(yīng)用范圍擴展到其他處理場景。

集字段級別的血緣關(guān)系（細(xì)粒度）。

一、文件/表級別

任務(wù)包含多個輸入和輸出，通過建立文件/數(shù)據(jù)表的血緣關(guān)系，便于分析數(shù)據(jù)流向，了解數(shù)據(jù)的重要程

度，為相關(guān)業(yè)務(wù)決策提供參考基礎(chǔ)。特別對于上下游系統(tǒng)交互較多的多任務(wù)處理系統(tǒng)，當(dāng)生產(chǎn)環(huán)境上游文

件未及時到達，能迅速進行影響分析，為應(yīng)急處置提供幫助。目前我們已經(jīng)完成粗粒度血緣關(guān)系提取工具

的開發(fā)，并將血緣關(guān)系導(dǎo)入到了 Apache Atlas 平臺。下圖 4.1 展示了港股通限制產(chǎn)品導(dǎo)出功能的文件、表與

批任務(wù)的血緣關(guān)系。

圖 4.1 文件級別血緣關(guān)系提取

二、字段級別

圖 4.1 ：文件級別血緣關(guān)系提取

交易系統(tǒng)基于數(shù)據(jù)處理，海量交易數(shù)據(jù)分散在多個系統(tǒng)，實際場景中經(jīng)常會遇到分析字段變更的影響

范圍、字段來源于哪里等問題。因此，分析字段間的血緣關(guān)系變得尤為重要。通過分析批業(yè)務(wù)配置中文件

或表字段賦值的關(guān)系，可以生成細(xì)粒度 column 級別的字段流向樹。圖 4.2 為 mem_code（會員代碼）字段

的血緣圖譜分析結(jié)果。后續(xù)將開發(fā)字段級別血緣關(guān)系的自動化的提取工具，完善細(xì)粒度血緣關(guān)系的展示。

圖 4.2 字段級別血緣關(guān)系提取

血緣關(guān)系的維護對后續(xù)構(gòu)建交易系統(tǒng)業(yè)務(wù)畫像、優(yōu)化系統(tǒng)業(yè)務(wù)架構(gòu)和性能、分析數(shù)據(jù)變更對系統(tǒng)造成

的影響評估等方面起到更大應(yīng)用。

5 Z[\\]^

在借鑒主流數(shù)據(jù)處理框架優(yōu)秀設(shè)計的基礎(chǔ)上，結(jié)合上交所批處理系統(tǒng)特性自研了一套數(shù)據(jù)處理框架。

一方面可以與批處理系統(tǒng)現(xiàn)有的技術(shù)更好的融合；另一方面無需獨立的運行時環(huán)境，避免額外的運維負(fù)擔(dān)；

數(shù)據(jù)處理框架同時支持內(nèi)存迭代執(zhí)行和數(shù)據(jù)庫 SQL 執(zhí)行兩種模式，統(tǒng)一了數(shù)據(jù)庫外和數(shù)據(jù)庫內(nèi)兩種數(shù)據(jù)處

理模式的表達方式。最后，元數(shù)據(jù)管理不但統(tǒng)一了字段的業(yè)務(wù)含義和技術(shù)定義，也使接口代碼可自動化生

成，提高了開發(fā)效率和準(zhǔn)確度。

前批系統(tǒng)經(jīng)使新的發(fā)模式投創(chuàng)新務(wù)交易系統(tǒng)升級建的發(fā)作中基本實代圖 4.2 ：字段級別血緣關(guān)系提取

本期熱點

34

目前，滬深市場上的普通期權(quán)產(chǎn)品以及國泰君安的場外期權(quán)產(chǎn)品的定價方式均是采用

基于蒙特卡羅模擬，通過軟件計算來實現(xiàn)。由于蒙特卡羅模擬往往需要模擬十萬條以上的路

徑，傳統(tǒng)的期權(quán)定價方法面臨著處理時間過長，計算效率過低等問題。本文基于此類問題，

提出并通過 oneAPI 實現(xiàn)了一種基于 FPGA 的并行流水線期權(quán)價格計算方案，能夠完成對

歐式香草期權(quán)與雪球期權(quán)的定價。經(jīng)過對比與測試，相比于 CPU 通過 C++ 軟件實現(xiàn)的方式，

通過 oneAPI 設(shè)計，并通過 FPGA 來實現(xiàn)的定價方式在性能上有顯著的提升。

基于oneAPI的金融衍生品定價加速

馬輝1

、鄒經(jīng)緯1

、白君潔1

、鐘浪輝2

、韓大偉2

、黃琦3

、余洋洋3

、李彪3 / 1 國泰君安證券股份有限公

司 上海 2 上交所技術(shù)有限責(zé)任公司 上海 3 英特爾移動通信技術(shù) ( 上海 ) 有限公司 上海

E-mail :baijunjie026611@gtjas.com

引言

期權(quán)作為最基礎(chǔ)的金融衍生產(chǎn)品之一，為其定

價一直是金融工程的重要研究領(lǐng)域，主要使用的定

價方法有偏微分方程法、鞅方法和數(shù)值方法。而數(shù)

值方法又包括了二叉樹方法、有限差分法和蒙特卡

羅模擬方法。蒙特卡羅模擬方法的理論基礎(chǔ)是概率

論和數(shù)理統(tǒng)計，其實質(zhì)是通過模擬標(biāo)的資產(chǎn)價格路

徑預(yù)測期權(quán)的平均回報并得到期權(quán)價格估計值。

蒙特卡羅方法的最大優(yōu)勢是誤差收斂率不依

賴于問題的維數(shù)，從而非常適宜為高維期權(quán)定價。

當(dāng)期權(quán)定價模型維數(shù)增大時，如多資產(chǎn)的期權(quán)模

型，無論是理論還是實際中，不會采用確定性方

法。因此，業(yè)內(nèi)最普遍采用的方法還是蒙特卡羅

方法，特別是對 Path-Dependent（路徑依賴）的

各類奇異期權(quán)以及 Multi-Asset（多資產(chǎn)）期權(quán)模

型，蒙特卡羅方法直觀有效。理論上，隨機模擬

方法效率和精度很低，但蒙特卡羅算法的模擬路

徑部分相互獨立，可以并行計算。但是，蒙特卡

羅模擬的缺點就是速率很慢，數(shù)值解誤差與隨機

次數(shù)開根號分之一同階，也就是說，若數(shù)值解要

精確到小數(shù)點后面 1 位，需要試驗 100 次 ；要精

確到小數(shù)點后面 2 位，則需要試驗 10000 次 ；要

精確到小數(shù)點后面 3 位，需要試驗 10 的 6 次方次。

使用 CPU 通過軟件計算的傳統(tǒng)期權(quán)定價

會相當(dāng)耗時，相比，F(xiàn)PGA（Field Programmable

Gate Array，現(xiàn)場可編程門陣列）具有良好的并

行計算特性，使用 FPGA 通過蒙特卡羅模擬進

行期權(quán)定價能獲得很好的性能提升。本文使用

Intel 公司的 oneAPI 開發(fā)工具，通過 DPC++(Data

Parallel C++ , 數(shù)據(jù)并行 C++) 語言設(shè)計了各類型

期權(quán)定價算法，并完成綜合實現(xiàn)，在 FPGA 加速

交易技術(shù)前沿

35

板卡上進行了功能驗證與性能對比。

1、期權(quán)定價原理

歐式和美式看漲看跌期權(quán)等衍生品被稱為普

通期權(quán)（也稱為香草期權(quán)），其具有定義良好的

標(biāo)準(zhǔn)屬性與廣大的交易占比。國內(nèi)市場上常見的

50ETF 期權(quán)、滬市 300ETF 期權(quán)、深市 300ETF

期權(quán)、滬深 300 股指期權(quán)均為歐式期權(quán)。

場外衍生品屬于非標(biāo)準(zhǔn)產(chǎn)品，場外期權(quán)也被

稱為奇異期權(quán)，盡管它們通常只占投資組合中相

對較小的一部分，但對于衍生品交易商來說，外

來產(chǎn)品是非常重要的，因此它們通常比普通衍生

品的利潤更高。

國泰君安在普通期權(quán)與場外奇異期權(quán)的定價

都有深入的研究，本文以歐式香草期權(quán)與場外期

權(quán)中的雪球期權(quán)為例進行分析。

1.1 歐式期權(quán)定價

歐式期權(quán)可分為看漲和看跌期權(quán)，是指在

將來的某個特定的時間（到期日），期權(quán)的持有

者有權(quán)力以事先約定的匯率（敲定價）向期權(quán)

出售者購買 / 出賣約定數(shù)量的貨幣，并支付購買

該項權(quán)力的權(quán)力金。歐式期權(quán)風(fēng)險中性定價通

過 Black-Scholes(BS) 模型實現(xiàn)，其隨機微分方程

（SDE）由下面公式給出 ：

/0

權(quán)可分為看漲和看跌期權(quán)，是指在將來的某個特定的時間（到期日），期權(quán)的持有者有權(quán)力以

匯率（敲定價）向期權(quán)出售者購買/出賣約定數(shù)量的貨幣，并支付購買該項權(quán)力的權(quán)力金。歐式

性定價通過 Black-Scholes(BS)模型實現(xiàn)，其隨機微分方程（SDE）由下面公式給出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 1

為資產(chǎn)價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行（維

為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作為最終現(xiàn)貨

收益的貼現(xiàn)期望，到期時間為??：

??,-.?? ?? ?? ?? 2

望是在適當(dāng)?shù)娘L(fēng)險中性度量下得到的，該度量使漂移量??等于無風(fēng)險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 4

個常系數(shù)隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 5

于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0,1)。

(1)

其中，S 為資產(chǎn)價格，μ 為股票的漂移量（瞬

時期望收益率），σ 為股票的波動率，B 為布朗

運行（維納過程）。

可以認(rèn)為 dB 是一個均值為 0，方差為 dt 的

正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作

為最終現(xiàn)貨價格的期權(quán)收益的貼現(xiàn)期望，到期時

間為 T ：

為看漲和看跌期權(quán)，是指在將來的某個特定的時間（到期日），期權(quán)的持有者有權(quán)力以

敲定價）向期權(quán)出售者購買/出賣約定數(shù)量的貨幣，并支付購買該項權(quán)力的權(quán)力金。歐式

通過 Black-Scholes(BS)模型實現(xiàn)，其隨機微分方程（SDE）由下面公式給出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 1

產(chǎn)價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行（維

一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作為最終現(xiàn)貨

貼現(xiàn)期望，到期時間為??：

??,-.?? ?? ?? ?? 2

適當(dāng)?shù)娘L(fēng)險中性度量下得到的，該度量使漂移量??等于無風(fēng)險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 4

數(shù)機微分由式解 (2)

這個期望是在適當(dāng)?shù)娘L(fēng)險中性度量下得到

的，該度量使漂移量μ等于無風(fēng)險利率r，可得到:

納過程）。

可以認(rèn)為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作為最終現(xiàn)價格的期權(quán)收益的貼現(xiàn)期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當(dāng)?shù)娘L(fēng)險中性度量下得到的，該度量使漂移量??等于無風(fēng)險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數(shù)隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0,1)將上式使用??(??)的指數(shù)形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風(fēng)險中性定價方法可以得到期權(quán)價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權(quán)或看跌期權(quán)的收益。通過對這些收益的總和取平均值，然后取無風(fēng)險折現(xiàn)，我們得到了期權(quán)的近似價格。

2.2 <=67/0

雪球期權(quán)屬于路徑依賴型奇異期權(quán)，其結(jié)構(gòu)相對復(fù)雜，本質(zhì)是一種帶障礙的看跌期權(quán)，自 2019 年開

始，雪球這種非保本型收益憑證受到市場上越來越多的關(guān)注，各類金融機構(gòu)紛紛以不同角色參與其中。表 1 所示案例為例：

表 1 雪球期權(quán)相關(guān)要素

雪球期權(quán)

掛鉤標(biāo)的 股票/指數(shù)

標(biāo)的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(3)

通過伊藤引理得到 ：

納過程）。

可以認(rèn)為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作為最終價格的期權(quán)收益的貼現(xiàn)期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當(dāng)?shù)娘L(fēng)險中性度量下得到的，該度量使漂移量??等于無風(fēng)險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數(shù)隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0將上式使用??(??)的指數(shù)形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風(fēng)險中性定價方法可以得到期權(quán)價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權(quán)或看跌期權(quán)的收益。通過對這些收益的總和取平均值，然后取險折現(xiàn)，我們得到了期權(quán)的近似價格。

2.2 <=67/0

雪球期權(quán)屬于路徑依賴型奇異期權(quán)，其結(jié)構(gòu)相對復(fù)雜，本質(zhì)是一種帶障礙的看跌期權(quán)，自 2019 始，雪球這種非保本型收益憑證受到市場上越來越多的關(guān)注，各類金融機構(gòu)紛紛以不同角色參與其中表 1 所示案例為例：

表 1 雪球期權(quán)相關(guān)要素

雪球期權(quán)

掛鉤標(biāo)的 股票/指數(shù)

標(biāo)的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(4)

這是一個常系數(shù)隨機微分方程，可由下式解

出 ：

其中，??為資產(chǎn)價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運納過程）。

可以認(rèn)為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作為最價格的期權(quán)收益的貼現(xiàn)期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當(dāng)?shù)娘L(fēng)險中性度量下得到的，該度量使漂移量??等于無風(fēng)險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數(shù)隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ??將上式使用??(??)的指數(shù)形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風(fēng)險中性定價方法可以得到期權(quán)價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權(quán)或看跌期權(quán)的收益。通過對這些收益的總和取平均值，然后險折現(xiàn)，我們得到了期權(quán)的近似價格。

2.2 <=67/0

雪球期權(quán)屬于路徑依賴型奇異期權(quán)，其結(jié)構(gòu)相對復(fù)雜，本質(zhì)是一種帶障礙的看跌期權(quán)，自 20始，雪球這種非保本型收益憑證受到市場上越來越多的關(guān)注，各類金融機構(gòu)紛紛以不同角色參與其表 1 所示案例為例：

表 1 雪球期權(quán)相關(guān)要素

雪球期權(quán)

掛鉤標(biāo)的 股票/指數(shù)

標(biāo)的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(5)

這里由于 B(t) 為布朗運動，因此滿足均值為

0， 方 差 為 T 的 正 態(tài) 分 布， 可 以 改 寫 為 ：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 1

其中，??為資產(chǎn)價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行（維

程）。

可以認(rèn)為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作為最終現(xiàn)貨

的期權(quán)收益的貼現(xiàn)期望，到期時間為??：

??,-.?? ?? ?? ?? 2

這個期望是在適當(dāng)?shù)娘L(fēng)險中性度量下得到的，該度量使漂移量??等于無風(fēng)險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 4

這是一個常系數(shù)隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 5

這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0,1)。

將上式使用??(??)的指數(shù)形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 6

使用風(fēng)險中性定價方法可以得到期權(quán)價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 7

在這種情況下，??的值是看漲期權(quán)或看跌期權(quán)的收益。通過對這些收益的總和取平均值，然后取無風(fēng)

現(xiàn)，我們得到了期權(quán)的近似價格。

=67/0

雪球期權(quán)屬于路徑依賴型奇異期權(quán)，其結(jié)構(gòu)相對復(fù)雜，本質(zhì)是一種帶障礙的看跌期權(quán)，自 2019 年開

雪球這種非保本型收益憑證受到市場上越來越多的關(guān)注，各類金融機構(gòu)紛紛以不同角色參與其中。以

所示案例為例：

表 1 雪球期權(quán)相關(guān)要素

雪球期權(quán)

掛鉤標(biāo)的 股票/指數(shù)

標(biāo)的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

。

將上式使用 S(t) 的指數(shù)形式改寫為 ：

期權(quán)風(fēng)險中性定價通過 Black-Scholes(BS)模型實現(xiàn)，其隨機微分方程（SDE）由下面公式給出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 其中，??為資產(chǎn)價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行（維

納過程）。

可以認(rèn)為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作為最終現(xiàn)價格的期權(quán)收益的貼現(xiàn)期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當(dāng)?shù)娘L(fēng)險中性度量下得到的，該度量使漂移量??等于無風(fēng)險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數(shù)隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0,1)將上式使用??(??)的指數(shù)形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風(fēng)險中性定價方法可以得到期權(quán)價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權(quán)或看跌期權(quán)的收益。通過對這些收益的總和取平均值，然后取無險折現(xiàn)，我們得到了期權(quán)的近似價格。

2.2 <=67/0

雪球期權(quán)屬于路徑依賴型奇異期權(quán)，其結(jié)構(gòu)相對復(fù)雜，本質(zhì)是一種帶障礙的看跌期權(quán)，自 2019 年開

始，雪球這種非保本型收益憑證受到市場上越來越多的關(guān)注，各類金融機構(gòu)紛紛以不同角色參與其中。表 1 所示案例為例：

表 1 雪球期權(quán)相關(guān)要素

雪球期權(quán)

掛鉤標(biāo)的 股票/指數(shù)

標(biāo)的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(6)

使用風(fēng)險中性定價方法可以得到期權(quán)價格的

表達式如下 ：

事先約定的匯率（敲定價）向期權(quán)出售者購買/出賣約定數(shù)量的貨幣，并支付購買該項權(quán)力的權(quán)力金期權(quán)風(fēng)險中性定價通過 Black-Scholes(BS)模型實現(xiàn)，其隨機微分方程（SDE）由下面公式給出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 其中，??為資產(chǎn)價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行納過程）。

可以認(rèn)為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權(quán)的價格作為最終價格的期權(quán)收益的貼現(xiàn)期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當(dāng)?shù)娘L(fēng)險中性度量下得到的，該度量使漂移量??等于無風(fēng)險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數(shù)隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(將上式使用??(??)的指數(shù)形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風(fēng)險中性定價方法可以得到期權(quán)價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權(quán)或看跌期權(quán)的收益。通過對這些收益的總和取平均值，然后取險折現(xiàn)，我們得到了期權(quán)的近似價格。

2.2 <=67/0

雪球期權(quán)屬于路徑依賴型奇異期權(quán)，其結(jié)構(gòu)相對復(fù)雜，本質(zhì)是一種帶障礙的看跌期權(quán)，自 2019 始，雪球這種非保本型收益憑證受到市場上越來越多的關(guān)注，各類金融機構(gòu)紛紛以不同角色參與其中表 1 所示案例為例：

表 1 雪球期權(quán)相關(guān)要素

雪球期權(quán)

掛鉤標(biāo)的 股票/指數(shù)

標(biāo)的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(7)

在這種情況下，f 的值是看漲期權(quán)或看跌期

權(quán)的收益。通過對這些收益的總和取平均值，然

后取無風(fēng)險折現(xiàn)，我們得到了期權(quán)的近似價格。

2.2 雪球期權(quán)定價

雪球期權(quán)屬于路徑依賴型奇異期權(quán)，其結(jié)

構(gòu)相對復(fù)雜，本質(zhì)是一種帶障礙的看跌期權(quán)，自

2019 年開始，雪球這種非保本型收益憑證受到市

場上越來越多的關(guān)注，各類金融機構(gòu)紛紛以不同

角色參與其中。以表 1 所示案例為例。

其年化收益率與掛鉤標(biāo)的價格變化的關(guān)系如

其年化收益率與掛鉤圖 1 所示。 標(biāo)的價格變化的關(guān)系如圖 1 所示。

圖 1 雪球期權(quán)與標(biāo)的價格關(guān)系

雪球期權(quán)最主要的特點是具有敲出水平和與敲入水平兩個門限，敲出水平每月觀測一次，敲入水平每

日觀測一次，如果發(fā)生敲出事件，產(chǎn)品終止并兌付收益；如果發(fā)生敲入事件，保護失效，若期末未敲出，

則相當(dāng)于持有該股票。因此截止期末可分為三種情況：第一種情況為敲出，可獲得票息為：年化票息×名義

本金×存續(xù)月數(shù)/12，如圖 2 所示，第二個月雖然發(fā)生了敲入事件，但第三個月底敲出觀察日時發(fā)生了敲出

事件，因此可本金無損外加 3 個月的票息收益。

圖 1 ：雪球期權(quán)與標(biāo)的價格關(guān)系

雪球期權(quán)最主要的特點是具有敲出水平和與

本期熱點

36

敲入水平兩個門限，敲出水平每月觀測一次，敲

入水平每日觀測一次，如果發(fā)生敲出事件，產(chǎn)品

終止并兌付收益；如果發(fā)生敲入事件，保護失效，

若期末未敲出，則相當(dāng)于持有該股票。因此截

止期末可分為三種情況 ：第一種情況為敲出，可

獲得票息為 ：年化票息 × 名義本金 × 存續(xù)月數(shù)

/12，如圖 2 所示，第二個月雖然發(fā)生了敲入事件，

但第三個月底敲出觀察日時發(fā)生了敲出事件，因

此可本金無損外加 3 個月的票息收益。

其年化收益率與掛鉤標(biāo)的價格變化的關(guān)系如圖 1 所示。

圖 1 雪球期權(quán)與標(biāo)的價格關(guān)系

雪球期權(quán)最主要的特點是具有敲出水平和與敲入水平兩個門限，敲出水平每月觀測一次，敲入水平每

觀測一次，如果發(fā)生敲出事件，產(chǎn)品終止并兌付收益；如果發(fā)生敲入事件，保護失效，若期末未敲出，

相當(dāng)于持有該股票。因此截止期末可分為三種情況：第一種情況為敲出，可獲得票息為：年化票息×名義

金×存續(xù)月數(shù)/12，如圖 2 所示，第二個月雖然發(fā)生了敲入事件，但第三個月底敲出觀察日時發(fā)生了敲出

件，因此可本金無損外加 3 個月的票息收益。

圖 2 敲出

第二種情況為敲入未敲出，結(jié)算金額為：名義本金×MAX（0，期初價格-期末價格）/期初價格，如圖

所示，在第三個月發(fā)生了敲入事件，產(chǎn)品存續(xù)期間未發(fā)生敲出事件，因此本金受損，無票息收益。

圖 3 敲入未敲出

第三種情況為未敲入未敲出，可獲得票息為：年化票息×名義本金×存續(xù)月數(shù)/12，如圖 4 所示，存續(xù)

圖 2 ：敲出

第二種情況為敲入未敲出，結(jié)算金額為 ：名

義本金 ×MAX（0，期初價格 - 期末價格）/ 期

初價格，如圖 3 所示，在第三個月發(fā)生了敲入事

件，產(chǎn)品存續(xù)期間未發(fā)生敲出事件，因此本金受

損，無票息收益。

其年化收益率與掛鉤標(biāo)的價格變化的關(guān)系如圖 1 所示。

圖 1 雪球期權(quán)與標(biāo)的價格關(guān)系

雪球期權(quán)最主要的特點是具有敲出水平和與敲入水平兩個門限，敲出水平每月觀測一次，敲入水平每

日觀測一次，如果發(fā)生敲出事件，產(chǎn)品終止并兌付收益；如果發(fā)生敲入事件，保護失效，若期末未敲出，

則相當(dāng)于持有該股票。因此截止期末可分為三種情況：第一種情況為敲出，可獲得票息為：年化票息×名義

本金×存續(xù)月數(shù)/12，如圖 2 所示，第二個月雖然發(fā)生了敲入事件，但第三個月底敲出觀察日時發(fā)生了敲出

事件，因此可本金無損外加 3 個月的票息收益。

圖 2 敲出

第二種情況為敲入未敲出，結(jié)算金額為：名義本金×MAX（0，期初價格-期末價格）/期初價格，如圖

所示，在第三個月發(fā)生了敲入事件，產(chǎn)品存續(xù)期間未發(fā)生敲出事件，因此本金受損，無票息收益。

圖 3 敲入未敲出

第三種情況為未敲入未敲出，可獲得票息為：年化票息×名義本金×存續(xù)月數(shù)/12，如圖 4 所示，存續(xù)

圖 3 ：敲入未敲出

第三種情況為未敲入未敲出，可獲得票息為：

年化票息 × 名義本金 × 存續(xù)月數(shù) /12，如圖 4

所示，存續(xù)期間期間未發(fā)生敲入事件與敲出事件，

期間期間未發(fā)生敲入事可獲得滿期 6 個月的票息收益。 件與敲出事件，可獲得滿期 6 個月的票息收益。

圖 4 未敲入未敲出

圖 4 ：未敲入未敲出

2、FPGA 與 oneAPI 的優(yōu)勢

CPU（Central Processing Unit， 中 央 處 理

器）的摩爾定律已入暮年，在高性能計算領(lǐng)域，

CPU 的表現(xiàn)已經(jīng)漸漸被 GPU（Graphics Processing

Unit，圖形處理器）、ASIC（Application Specific

Integrated Circuit，專用集成電路）和 FPGA 等硬

件超越。FPGA 常年來被用于 ASIC 的小批量替

代品，以同時提供強大的計算能力和足夠的靈活

性，如圖 5 所示。

CPU、GPU 都屬于馮·諾依曼結(jié)構(gòu)，指令

譯碼執(zhí)行、共享內(nèi)存。FPGA 之所以比 CPU 甚至

GPU 能效高，本質(zhì)上是無指令、無需共享內(nèi)存的

體系結(jié)構(gòu)帶來的福利。馮氏結(jié)構(gòu)中，由于執(zhí)行單

元（如 CPU 核）可能執(zhí)行任意指令，就需要有指

令存儲器、譯碼器、各種指令的運算器、分支跳

轉(zhuǎn)處理邏輯。由于指令流的控制邏輯復(fù)雜，不可

能有太多條獨立的指令流，因此 GPU 使用 SIMD

（Single Instruction Multiple Data)，單指令流多數(shù)據(jù)

流）來讓多個執(zhí)行單元以同樣的步調(diào)處理不同的

數(shù)據(jù)，CPU 也支持 SIMD 指令。而 FPGA 每個邏

輯單元的功能在重編程（燒寫）時就已經(jīng)確定，

不需要指令。馮氏結(jié)構(gòu)中使用內(nèi)存有兩種作用。

一是保存狀態(tài)，二是在執(zhí)行單元間通信。由于內(nèi)

存是共享的，就需要做訪問仲裁 ；為了利用訪問

局部性，每個執(zhí)行單元有一個私有的緩存，這就

要維持執(zhí)行部件間緩存的一致性。對于保存狀態(tài)

的需求，F(xiàn)PGA 中的寄存器和 BRAM（Block RAM，

片上內(nèi)存）是屬于各自的控制邏輯的，無需不必

險折現(xiàn)，我們得到了期權(quán)的近似價格。

2.2 <=67/0

雪球期權(quán)屬于路徑依賴型奇異期權(quán)，其結(jié)構(gòu)相對復(fù)雜，本質(zhì)是一種帶障礙的看跌期權(quán)，自 2019 年開

始，雪球這種非保本型收益憑證受到市場上越來越多的關(guān)注，各類金融機構(gòu)紛紛以不同角色參與其中。以

表 1 所示案例為例：

表 1 雪球期權(quán)相關(guān)要素

雪球期權(quán)

掛鉤標(biāo)的 股票/指數(shù)

標(biāo)的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

表 1 ：雪球期權(quán)相關(guān)要素

交易技術(shù)前沿

37

要的仲裁和緩存。對于通信的需求，F(xiàn)PGA 每個

邏輯單元與周圍邏輯單元的連接在重編程（燒寫）

時就已經(jīng)確定，并不需要通過共享內(nèi)存來通信。

FPGA 同時擁有流水線并行和數(shù)據(jù)并行，而

GPU 幾乎只有數(shù)據(jù)并行（流水線深度受限）。

例如處理一個數(shù)據(jù)包有 10 個步驟，F(xiàn)PGA

可以搭建一個 10 級流水線，流水線的不同級在

處理不同的數(shù)據(jù)包，每個數(shù)據(jù)包流經(jīng) 10 級之后

處理完成，每處理完成一個數(shù)據(jù)包，就能馬上輸

出 ；而 GPU 的數(shù)據(jù)并行方法是做 10 個計算單元，

每個計算單元也在處理不同的數(shù)據(jù)包，然而所有

的計算單元必須按照統(tǒng)一的步調(diào)，做相同的事情，

這就要求 10 個數(shù)據(jù)包必須一起輸入、一起輸出，

輸入輸出的延遲增加了。

當(dāng)任務(wù)是逐個而非成批到達的時候，流水線

并行比數(shù)據(jù)并行可實現(xiàn)更低的延遲。因此對流式

計算的任務(wù)，F(xiàn)PGA 比 GPU 天生有延遲方面的優(yōu)

勢，如圖 6 所示。

執(zhí)行單元有一個私有的緩存，這就要維持執(zhí)行部件間緩存的一致性。對于保存狀態(tài)的需求，F(xiàn)PGA 中的寄

存器和 BRAM（Block RAM，片上內(nèi)存）是屬于各自的控制邏輯的，無需不必要的仲裁和緩存。對于通信

的需求，F(xiàn)PGA 每個邏輯單元與周圍邏輯單元的連接在重編程（燒寫）時就已經(jīng)確定，并不需要通過共享

內(nèi)存來通信。

FPGA 同時擁有流水線并行和數(shù)據(jù)并行，而 GPU 幾乎只有數(shù)據(jù)并行（流水線深度受限）。

例如處理一個數(shù)據(jù)包有 10 個步驟，F(xiàn)PGA 可以搭建一個 10 級流水線，流水線的不同級在處理不同的

數(shù)據(jù)包，每個數(shù)據(jù)包流經(jīng) 10 級之后處理完成，每處理完成一個數(shù)據(jù)包，就能馬上輸出；而 GPU 的數(shù)據(jù)并

行方法是做 10 個計算單元，每個計算單元也在處理不同的數(shù)據(jù)包，然而所有的計算單元必須按照統(tǒng)一的步

調(diào)，做相同的事情，這就要求 10 個數(shù)據(jù)包必須一起輸入、一起輸出，輸入輸出的延遲增加了。

當(dāng)任務(wù)是逐個而非成批到達的時候，流水線并行比數(shù)據(jù)并行可實現(xiàn)更低的延遲。因此對流式計算的任

務(wù)，F(xiàn)PGA 比 GPU 天生有延遲方面的優(yōu)勢，如圖 6 所示。

圖 6 并行流水線

各體系架構(gòu)性能數(shù)量級比較（以 16 位整數(shù)乘法為例）如表 2 所示。

表 2 各體系架構(gòu)性能數(shù)量級比較

體系架構(gòu) 吞吐量 延遲 功耗 靈活性

CPU ~1T N/A ~100W 很高

GPU ~10T ~1ms ~300W 高

FPGA(Stratix 10) ~10T ~1us ~30W 高

ASIC ~10T ~1us ~30W 低

期權(quán)計算不可能有閉合形式的解，而是通過用蒙特卡羅方法模擬了許多可能的路徑，最終得到了一個

預(yù)期的收益值。使用蒙特卡羅模擬需要生成高質(zhì)量的隨機數(shù)，并進行上千萬點的模擬，傳統(tǒng)的使用 CPU 來

進行計算，耗時非常巨大，而 FPGA 通過使用通道以及循環(huán)流水線的排布，能夠有效提升性能，減小計算

延遲。

而傳統(tǒng)的 FPGA 開發(fā)一般選擇硬件描述語言（如 VHDL/Verilog HDL），開發(fā)周期長、難度大，對于

使用高級語言進行開發(fā)的軟件工程師而言，進入的門檻非常高。在開發(fā) FPGA 時，需要硬件理解深刻，重

點是需要非常詳細(xì)的設(shè)計工作，合理規(guī)劃硬件資源進行任務(wù)并行和數(shù)據(jù)并行的處理業(yè)務(wù)，包括處理的時序、

RAM 的分配,還要經(jīng)過一系列的仿真、綜合等。

Intel FPGA SDK 提供了高效的使用高級語言開發(fā) FPGA 的方式，通過 OpenCL 或 oneAPI 工具來進行

FPGA 開發(fā)。相比于 OpenCL，作為升級版，oneAPI 真正意義上實現(xiàn)了天下大同。oneAPI 編程模型簡化了

CPU 和加速器的編程，基于 C++特性與 SYCL 并行性的標(biāo)準(zhǔn)跨體系結(jié)構(gòu)語言 DPC++。DPC++支持主機和

加速器的代碼復(fù)用，使用單一的源語言，執(zhí)行和內(nèi)存依賴清晰地溝通。DPC++代碼內(nèi)的映射可用于將應(yīng)用

圖 6 ：并行流水線

各體系架構(gòu)性能數(shù)量級比較（以 16 位整數(shù)

乘法為例）如表 2 所示。

期權(quán)計算不可能有閉合形式的解，而是通過

用蒙特卡羅方法模擬了許多可能的路徑，最終得

到了一個預(yù)期的收益值。使用蒙特卡羅模擬需要

生成高質(zhì)量的隨機數(shù)，并進行上千萬點的模擬，

傳統(tǒng)的使用 CPU 來進行計算，耗時非常巨大，

2 FPGA > oneAPI )?@

CPU（Central Processing Unit，中央處理器）的摩爾定律已入暮年，在高性能計算領(lǐng)域，CPU 的表現(xiàn)

已經(jīng)漸漸被 GPU（Graphics Processing Unit，圖形處理器）、ASIC（Application Specific Integrated Circuit，

專用集成電路）和 FPGA 等硬件超越。FPGA 常年來被用于 ASIC 的小批量替代品，以同時提供強大的計算

能力和足夠的靈活性，如圖 5 所示。

圖 5 不同體系結(jié)構(gòu)性能和靈活性的比較

CPU、GPU 都屬于馮·諾依曼結(jié)構(gòu)，指令譯碼執(zhí)行、共享內(nèi)存。FPGA 之所以比 CPU 甚至 GPU 能效

高，本質(zhì)上是無指令、無需共享內(nèi)存的體系結(jié)構(gòu)帶來的福利。馮氏結(jié)構(gòu)中，由于執(zhí)行單元（如 CPU 核）可

能執(zhí)行任意指令，就需要有指令存儲器、譯碼器、各種指令的運算器、分支跳轉(zhuǎn)處理邏輯。由于指令流的

控制邏輯復(fù)雜，不可能有太多條獨立的指令流，因此 GPU 使用 SIMD（Single Instruction Multiple Data)，單

指令流多數(shù)據(jù)流）來讓多個執(zhí)行單元以同樣的步調(diào)處理不同的數(shù)據(jù)，CPU 也支持 SIMD 指令。而 FPGA 每

個邏輯單元的功能在重編程（燒寫）時就已經(jīng)確定，不需要指令。馮氏結(jié)構(gòu)中使用內(nèi)存有兩種作用。一是

保存狀態(tài)，二是在執(zhí)行單元間通信。由于內(nèi)存是共享的，就需要做訪問仲裁；為了利用訪問局部性，每個

圖 5 ：不同體系結(jié)構(gòu)性能和靈活性的比較

執(zhí)行單元有一個私有的緩存，這就要維持執(zhí)行部件間緩存的一致性。對于保存狀態(tài)的需求，F(xiàn)PGA 中的寄

存器和 BRAM（Block RAM，片上內(nèi)存）是屬于各自的控制邏輯的，無需不必要的仲裁和緩存。對于通信

的需求，F(xiàn)PGA 每個邏輯單元與周圍邏輯單元的連接在重編程（燒寫）時就已經(jīng)確定，并不需要通過共享

內(nèi)存來通信。

FPGA 同時擁有流水線并行和數(shù)據(jù)并行，而 GPU 幾乎只有數(shù)據(jù)并行（流水線深度受限）。

例如處理一個數(shù)據(jù)包有 10 個步驟，F(xiàn)PGA 可以搭建一個 10 級流水線，流水線的不同級在處理不同的

數(shù)據(jù)包，每個數(shù)據(jù)包流經(jīng) 10 級之后處理完成，每處理完成一個數(shù)據(jù)包，就能馬上輸出；而 GPU 的數(shù)據(jù)并

行方法是做 10 個計算單元，每個計算單元也在處理不同的數(shù)據(jù)包，然而所有的計算單元必須按照統(tǒng)一的步

調(diào)，做相同的事情，這就要求 10 個數(shù)據(jù)包必須一起輸入、一起輸出，輸入輸出的延遲增加了。

當(dāng)任務(wù)是逐個而非成批到達的時候，流水線并行比數(shù)據(jù)并行可實現(xiàn)更低的延遲。因此對流式計算的任

務(wù)，F(xiàn)PGA 比 GPU 天生有延遲方面的優(yōu)勢，如圖 6 所示。

圖 6 并行流水線

各體系架構(gòu)性能數(shù)量級比較（以 16 位整數(shù)乘法為例）如表 2 所示。

表 2 各體系架構(gòu)性能數(shù)量級比較

體系架構(gòu) 吞吐量 延遲 功耗 靈活性

CPU ~1T N/A ~100W 很高

GPU ~10T ~1ms ~300W 高

FPGA(Stratix 10) ~10T ~1us ~30W 高

ASIC ~10T ~1us ~30W 低

期權(quán)計算不可能有閉合形式的解，而是通過用蒙特卡羅方法模擬了許多可能的路徑，最終得到了一個

預(yù)期的收益值。使用蒙特卡羅模擬需要生成高質(zhì)量的隨機數(shù)，并進行上千萬點的模擬，傳統(tǒng)的使用 CPU 來

進行計算，耗時非常巨大，而 FPGA 通過使用通道以及循環(huán)流水線的排布，能夠有效提升性能，減小計算

延遲。

表 2 ：各體系架構(gòu)性能數(shù)量級比較

本期熱點

38

而 FPGA 通過使用通道以及循環(huán)流水線的排布，

能夠有效提升性能，減小計算延遲。

而傳統(tǒng)的 FPGA 開發(fā)一般選擇硬件描述語言

（如 VHDL/Verilog HDL），開發(fā)周期長、難度大，

對于使用高級語言進行開發(fā)的軟件工程師而言，

進入的門檻非常高。在開發(fā) FPGA 時，需要硬件

理解深刻，重點是需要非常詳細(xì)的設(shè)計工作，合

理規(guī)劃硬件資源進行任務(wù)并行和數(shù)據(jù)并行的處理

業(yè)務(wù)，包括處理的時序、RAM 的分配 , 還要經(jīng)過

一系列的仿真、綜合等。

Intel FPGA SDK 提供了高效的使用高級語言

開發(fā) FPGA 的方式，通過 OpenCL 或 oneAPI 工具

來進行 FPGA 開發(fā)。相比于 OpenCL，作為升級

版，oneAPI 真正意義上實現(xiàn)了天下大同。oneAPI

編程模型簡化了 CPU 和加速器的編程，基于

C++ 特性與 SYCL 并行性的標(biāo)準(zhǔn)跨體系結(jié)構(gòu)語言

DPC++。DPC++ 支持主機和加速器的代碼復(fù)用，

使用單一的源語言，執(zhí)行和內(nèi)存依賴清晰地溝通。

DPC++ 代碼內(nèi)的映射可用于將應(yīng)用程序轉(zhuǎn)換為在

硬件 ( 或一組硬件 ) 上運行，從而最大程度地加

速工作負(fù)載。主機可以簡化設(shè)備代碼的開發(fā)和調(diào)

試，甚至在沒有加速器的平臺上也是如此。

圖 7 所示為一個通過 DPC++ 語言開發(fā)的

oneAPI 簡單應(yīng)用，用來將數(shù)組的每個元素設(shè)置

為其下標(biāo)的值?？梢钥闯?，主機代碼和加速器代

碼都組合在一個源文件中，使用的語法是標(biāo)準(zhǔn)的

C++，并通過 C++ 類來實現(xiàn)并行性。該示例的邏

輯為 ：第 8 行和第 9 行創(chuàng)建了一個包含 16 個 int

元素的 buffer，第 11 行構(gòu)造一個隊列來表示主機

到加速器之間的連接。創(chuàng)建隊列后，調(diào)用形參為

lambda 函數(shù)的 submit() 成員函數(shù)向加速器提交工

作，它在第 12 行創(chuàng)建一個訪問器，使得可以在

buffer 中寫入元素，在第 13 行調(diào)用 parallel_for()

函數(shù)來執(zhí)行加速器上的代碼。調(diào)用的 parallel_

for() 函數(shù)有兩個參數(shù)，一個參數(shù)是 lambda 函數(shù)，

另一個是表示 buffer 中元素數(shù)量的范圍對象“r”，

lambda 在加速器上被該范圍內(nèi)的每個索引調(diào)用一

次，通過使用在第 12 行創(chuàng)建的 out 訪問器將一

個值賦給 buffer。在調(diào)用 parallel_for() 之后，代碼

的主機部分將繼續(xù)運行，而無需等待加速器上的

工作完成，并在第 18 行創(chuàng)建一個構(gòu)造函數(shù) host_

accessor 來讀取 buffer 中的元素，這里 buffer 中的

元素是由加速器寫入的，所以在 parallel_for() 的

數(shù)據(jù)傳遞完成之前，host_accessor 將被阻塞，加

速器工作完成后，主機開始執(zhí)行第 18 行之后的

代碼。

程序轉(zhuǎn)換為在硬件(或一組硬件)上運行，從而最大程度地加速工作負(fù)載。主機可以簡化設(shè)備代碼的開發(fā)和調(diào)試，甚至在沒有加速器的平臺上也是如此。

圖7所示為一個通過DPC++語言開發(fā)的oneAPI簡單應(yīng)用，用來將數(shù)組的每個元素設(shè)置為其下標(biāo)的值可以看出，主機代碼和加速器代碼都組合在一個源文件中，使用的語法是標(biāo)準(zhǔn)的 C++，并通過 C++類來現(xiàn)并行性。該示例的邏輯為：第 8 行和第 9 行創(chuàng)建了一個包含 16 個 int 元素的 buffer，第 11 行構(gòu)造一個列來表示主機到加速器之間的連接。創(chuàng)建隊列后，調(diào)用形參為 lambda 函數(shù)的 submit()成員函數(shù)向加速器交工作，它在第 12 行創(chuàng)建一個訪問器，使得可以在 buffer 中寫入元素，在第 13 行調(diào)用 parallel_for()函數(shù)執(zhí)行加速器上的代碼。調(diào)用的 parallel_for()函數(shù)有兩個參數(shù)，一個參數(shù)是 lambda 函數(shù)，另一個是表示 bu中元素數(shù)量的范圍對象“r”，lambda 在加速器上被該范圍內(nèi)的每個索引調(diào)用一次，通過使用在第 12 行建的 out 訪問器將一個值賦給 buffer。在調(diào)用 parallel_for()之后，代碼的主機部分將繼續(xù)運行，而無需等加速器上的工作完成，并在第 18 行創(chuàng)建一個構(gòu)造函數(shù) host_accessor 來讀取 buffer 中的元素，這里 buffer 的元素是由加速器寫入的，所以在 parallel_for()的數(shù)據(jù)傳遞完成之前，host_accessor 將被阻塞，加速器工完成后，主機開始執(zhí)行第 18 行之后的代碼。

圖 7 oneAPI 開發(fā)示例

此外，oneAPI 編程模型提供了可以跨硬件目標(biāo)使用的全面統(tǒng)一的開發(fā)人員工具組合，包括跨越多個作負(fù)載域的一系列性能庫。這些庫包括為每個目標(biāo)體系結(jié)構(gòu)定制編碼的函數(shù)，因此相同的函數(shù)調(diào)用可以受支持的體系結(jié)構(gòu)之間提供優(yōu)化的性能，如圖 8 所示，利用 oneAPI 編程模型的應(yīng)用程序可以在從 CPU FPGA 的多個目標(biāo)硬件平臺上運行。

圖 7 ：oneAPI 開發(fā)示例

此外，oneAPI 編程模型提供了可以跨硬件

目標(biāo)使用的全面統(tǒng)一的開發(fā)人員工具組合，包括

跨越多個工作負(fù)載域的一系列性能庫。這些庫包

括為每個目標(biāo)體系結(jié)構(gòu)定制編碼的函數(shù)，因此相

同的函數(shù)調(diào)用可以在受支持的體系結(jié)構(gòu)之間提供

優(yōu)化的性能，如圖 8 所示，利用 oneAPI 編程模

型的應(yīng)用程序可以在從 CPU 到 FPGA 的多個目

標(biāo)硬件平臺上運行。

與此同時，Intel 也在大力投入對 oneAPI 的

研發(fā)，使其開發(fā)效率，編譯性能，以及運算性能

都在不斷提高，oneAPI 的某些運算引擎甚至超過

了硬件語言描述 DPS 的性能。使用 oneAPI 來通

交易技術(shù)前沿

39

過 FPGA 進行期權(quán)定價加速，無論從效率還是性

能上講都是不二之選。

3、基于 oneAPI 期權(quán)定價設(shè)計

期權(quán)計算的流程主要可分為隨機數(shù)生成與

期權(quán)數(shù)值計算兩部分，隨機數(shù)部分又可分解為隨

機數(shù)初始化和隨機數(shù)生成，數(shù)值計算部分可分解

為定價和求和。使用 oneAPI 進行設(shè)計，每部分

都可通過 Channel 利用 FIFO 隊列將各 kernel 模

塊連接起來，達到流水線并行的效果，流程如圖

9 所示。MT Initial 選擇一個隨機數(shù)種子，計算

出梅森旋轉(zhuǎn)鏈，放入 Channel 0 ；MT Generation

從 Channel 0 中取出梅森旋轉(zhuǎn)鏈數(shù)據(jù)，計算出

偽 隨 機 數(shù)， 輸 入 Channel 1 ；Stock price Motion

從 Channel 1 中取出生成的隨機數(shù)，利用定價模

型計算出的結(jié)果輸入 Channel 2 ；累加器 Partial

Accumulate 從 Channel 2 中取出計算結(jié)果，累加

求和，輸出結(jié)果。

Mersenne Twister 初始化時，需要一個初始

化種子，然后生成長度為 624 的梅森旋轉(zhuǎn)鏈。因

為旋轉(zhuǎn)鏈上的后一個數(shù)據(jù)需要對前一個數(shù)據(jù)進行

計算才能得到，所以旋轉(zhuǎn)鏈的生成無法數(shù)據(jù)并行，

可以選擇流水線的方式進行優(yōu)化。MT Initial 和

MT Generation 之間通過 Channel 0 傳輸梅森旋轉(zhuǎn)

鏈數(shù)據(jù)。一般在選擇 Channel 數(shù)據(jù)大小和深度時，

選擇 2 的整數(shù)次冪。MT Initial 生成的旋轉(zhuǎn)鏈長

度為 624，可以選擇每次傳輸旋轉(zhuǎn)鏈中的 64 個或

128 個數(shù)據(jù)給 MT Generation。

MT Generation 的計算邏輯是 ：取出初始化

的 624 長度的初始化旋轉(zhuǎn)鏈，然后執(zhí)行旋轉(zhuǎn)算

法（針對整個鏈），以后以 624 為周期，用梅森

狀態(tài)鏈每生成 624 個隨機數(shù)，旋轉(zhuǎn)一次，隨后生

成下一組 624 個隨機數(shù)。同樣，將生成的隨機數(shù)

通過大小為 64 或 128 的 Channel 1 傳入到下一個

kernel 進行計算。歐式期權(quán)和雪球期權(quán)隨機數(shù)生

圖 8 oneAPI 跨工作域

與此同時，Intel 也在大力投入對 oneAPI 的研發(fā)，使其開發(fā)效率，編譯性能，以及運算性能都在不斷

提高，oneAPI 的某些運算引擎甚至超過了硬件語言描述 DPS 的性能。使用 oneAPI 來通過 FPGA 進行期權(quán)

定價加速，無論從效率還是性能上講都是不二之選。

3 !\" oneAPI 67/0AB

期權(quán)計算的流程主要可分為隨機數(shù)生成與期權(quán)數(shù)值計算兩部分，隨機數(shù)部分又可分解為隨機數(shù)初始化

和隨機數(shù)生成，數(shù)值計算部分可分解為定價和求和。使用 oneAPI 進行設(shè)計，每部分都可通過 Channel 利用

FIFO 隊列將各 kernel 模塊連接起來，達到流水線并行的效果，流程如圖 9 所示。MT Initial 選擇一個隨機

數(shù)種子，計算出梅森旋轉(zhuǎn)鏈，放入 Channel 0；MT Generation 從 Channel 0 中取出梅森旋轉(zhuǎn)鏈數(shù)據(jù)，計算出

偽隨機數(shù)，輸入 Channel 1；Stock price Motion 從 Channel 1 中取出生成的隨機數(shù)，利用定價模型計算出的

結(jié)果輸入 Channel 2；累加器 Partial Accumulate 從 Channel 2 中取出計算結(jié)果，累加求和，輸出結(jié)果。

圖 9 期權(quán)定價流水線并行

Mersenne Twister 初始化時，需要一個初始化種子，然后生成長度為 624 的梅森旋轉(zhuǎn)鏈。因為旋轉(zhuǎn)鏈

上的后一個數(shù)據(jù)需要對前一個數(shù)據(jù)進行計算才能得到，所以旋轉(zhuǎn)鏈的生成無法數(shù)據(jù)并行，可以選擇流水線

的方式進行優(yōu)化。MT Initial 和 MT Generation 之間通過 Channel 0 傳輸梅森旋轉(zhuǎn)鏈數(shù)據(jù)。一般在選擇 Channel

數(shù)據(jù)大小和深度時選擇2的整數(shù)次冪MTIitil生成的旋轉(zhuǎn)鏈長度為624可以選擇每次傳輸旋轉(zhuǎn)鏈中Mersenne

Twister Initial

Mersenne

Twister

Generation

Stock Price

Motion

Partial

Accumulation

Channel 0 Channel 1 Channel 2

圖 8 oneAPI 跨工作域

與此同時，Intel 也在大力投入對 oneAPI 的研發(fā)，使其開發(fā)效率，編譯性能，以及運算性能都在不斷

提高，oneAPI 的某些運算引擎甚至超過了硬件語言描述 DPS 的性能。使用 oneAPI 來通過 FPGA 進行期權(quán)

定價加速，無論從效率還是性能上講都是不二之選。

3 !\" oneAPI 67/0AB

期權(quán)計算的流程主要可分為隨機數(shù)生成與期權(quán)數(shù)值計算兩部分，隨機數(shù)部分又可分解為隨機數(shù)初始化

和隨機數(shù)生成，數(shù)值計算部分可分解為定價和求和。使用 oneAPI 進行設(shè)計，每部分都可通過 Channel 利用

FIFO 隊列將各 kernel 模塊連接起來，達到流水線并行的效果，流程如圖 9 所示。MT Initial 選擇一個隨機

數(shù)種子，計算出梅森旋轉(zhuǎn)鏈，放入 Channel 0；MT Generation 從 Channel 0 中取出梅森旋轉(zhuǎn)鏈數(shù)據(jù)，計算出

偽隨機數(shù)，輸入 Channel 1；Stock price Motion 從 Channel 1 中取出生成的隨機數(shù)，利用定價模型計算出的

結(jié)果輸入 Channel 2；累加器 Partial Accumulate 從 Channel 2 中取出計算結(jié)果，累加求和，輸出結(jié)果。

圖 9 期權(quán)定價流水線并行

Mersenne Twister 初始化時，需要一個初始化種子，然后生成長度為 624 的梅森旋轉(zhuǎn)鏈。因為旋轉(zhuǎn)鏈

上的后一個數(shù)據(jù)需要對前一個數(shù)據(jù)進行計算才能得到，所以旋轉(zhuǎn)鏈的生成無法數(shù)據(jù)并行，可以選擇流水線

的方式進行優(yōu)化。MT Initial 和 MT Generation 之間通過 Channel 0 傳輸梅森旋轉(zhuǎn)鏈數(shù)據(jù)。一般在選擇 Channel

數(shù)據(jù)大小和深度時，選擇 2 的整數(shù)次冪。MT Initial 生成的旋轉(zhuǎn)鏈長度為 624，可以選擇每次傳輸旋轉(zhuǎn)鏈中

的 64 個或 128 個數(shù)據(jù)給 MT Generation。

MT Generation 的計算邏輯是：取出初始化的 624 長度的初始化旋轉(zhuǎn)鏈，然后執(zhí)行旋轉(zhuǎn)算法（針對整

個鏈），以后以 624 為周期，用梅森狀態(tài)鏈每生成 624 個隨機數(shù)，旋轉(zhuǎn)一次，隨后生成下一組 624 個隨機

數(shù)。同樣，將生成的隨機數(shù)通過大小為 64 或 128 的 Channel 1 傳入到下一個 kernel 進行計算。歐式期權(quán)和

雪球期權(quán)隨機數(shù)生成的方法是一樣的。

Stock Price Motion 部分為最主要的計算部分。與上面邏輯相同，通過 Channel 進行數(shù)據(jù)讀寫，首先將

Mersenne

Twister Initial

Mersenne

Twister

Generation

Stock Price

Motion

Partial

Accumulation

Channel 0 Channel 1 Channel 2

圖 8 ：oneAPI 跨工作域

圖 9 ：期權(quán)定價流水線并行

本期熱點

成的方法是一樣的。

Stock Price Motion部分為最主要的計算部分。

與上面邏輯相同，通過 Channel 進行數(shù)據(jù)讀寫，

首先將 MT Generation 傳入的隨機數(shù)值域限定在

0~1 之間，此時滿足（0，1）上的均勻分布，隨

后通過 Box-Muller 算法將（0，1）上的均勻分布

轉(zhuǎn)化為標(biāo)準(zhǔn)正態(tài)分布，進行下面的計算。對于歐

式期權(quán)，可直接使用 BS 公式進行定價，將結(jié)果

寫入 Channel 2 中，由于運算邏輯簡單，可使用

NDRange 提升計算性能，每次下發(fā) 8192 個計算

任務(wù)，充分使用流水線計算。對于雪球期權(quán)，在

BS 公式的基礎(chǔ)上，還需要進行復(fù)雜的向量運算，

來模擬三種不同的情景，所以每次展開一條蒙特

卡羅路徑進行模擬，將每條路徑的模擬價格寫入

Channel 2 中，每條路徑內(nèi)部的 for 循環(huán)可以使用

數(shù)據(jù)并行來提高計算性能。

最 后 Partial Accumulation 部 分 為 累 加 求

和 , 從 Channel ２中讀取出期權(quán)價格之和，寫回

Buffer 中。對于歐式期權(quán)，每次發(fā)送 8192 個線

程，所以需要讀取完 8192 個數(shù)據(jù)；對于雪球期權(quán)，

進行了 mc 條蒙特卡羅路徑的模擬，所以需要讀

取完 mc 個數(shù)據(jù)。將和寫回主機的 Result Buffer

中求取平均值完成最終的期權(quán)定價。

4、結(jié)果驗證與分析

CPU 和 FPGA 在期權(quán)定價流程中有各自擅長

的模塊，本次驗證對歐式期權(quán)和雪球期權(quán)定價最

終性能在 CPU 和 FPGA 上進行綜合對比。

測試驗證對比環(huán)境 ：

CPU: Intel core i7 10700 @2.9GHz 8 cores

FPGA: Intel PAC D5005 with Stratix 10 GX

FPGA

4.1 歐式期權(quán)性能分析

在相同參數(shù)與相同蒙特卡羅模擬次數(shù)情況下

CPU 與 FPGA 的對歐式期權(quán)的定價結(jié)果如圖 10

與圖 11 所示。

改變蒙特卡羅模擬次數(shù)，對定價性能進行

比較，如圖 12 所示，可以看到，模擬次數(shù)越多，

FPGA 能夠更大程度地釋放性能。

FPGA 資源使用情況如圖 13 所示。

4.2 雪球期權(quán)性能分析

同樣，在相同參數(shù)與相同蒙特卡羅模擬次數(shù)

情況下 CPU 與 FPGA 對雪球期權(quán)的定價結(jié)果如

圖 14 與圖 15 所示。

改變蒙特卡羅模擬次數(shù)，對定價性能進行比

較，如圖 16 所示，同樣，隨著模擬次數(shù)的增加，

FPGA 性能提升更加明顯。

FPGA 資源使用情況如圖 17 所示。

圖 18 與圖 19 分別為雪球期權(quán)價格與波動率

sigma 以及票息 coupon 關(guān)系的線性回歸，計算符

合預(yù)期效果。

MT Generation 傳入的隨機數(shù)值域限定在 0~1 之間，此時滿足（0，1）上的均勻分布，隨后通過 Box-Muller

算法將（0，1）上的均勻分布轉(zhuǎn)化為標(biāo)準(zhǔn)正態(tài)分布，進行下面的計算。對于歐式期權(quán)，可直接使用 BS 公

式進行定價，將結(jié)果寫入 Channel 2 中，由于運算邏輯簡單，可使用 NDRange 提升計算性能，每次下發(fā) 8192

個計算任務(wù)，充分使用流水線計算。對于雪球期權(quán)，在 BS 公式的基礎(chǔ)上，還需要進行復(fù)雜的向量運算，

來模擬三種不同的情景，所以每次展開一條蒙特卡羅路徑進行模擬，將每條路徑的模擬價格寫入 Channel 2

中，每條路徑內(nèi)部的 for 循環(huán)可以使用數(shù)據(jù)并行來提高計算性能。

最后 Partial Accumulation 部分為累加求和,從 Channel ２中讀取出期權(quán)價格之和，寫回 Buffer 中。對

于歐式期權(quán)，每次發(fā)送 8192 個線程，所以需要讀取完 8192 個數(shù)據(jù)；對于雪球期權(quán)，進行了 mc 條蒙特卡

羅路徑的模擬，所以需要讀取完 mc 個數(shù)據(jù)。將和寫回主機的 Result Buffer 中求取平均值完成最終的期權(quán)定

價。

4 CDEF>GH

CPU 和 FPGA 在期權(quán)定價流程中有各自擅長的模塊，本次驗證對歐式期權(quán)和雪球期權(quán)定價最終性能在

CPU 和 FPGA 上進行綜合對比。

測試驗證對比環(huán)境：

CPU: Intel core i7 10700 @2.9GHz 8 cores

FPGA: Intel PAC D5005 with Stratix 10 GX FPGA

4.1 :;67IJGH

在相同參數(shù)與相同蒙特卡羅模擬次數(shù)情況下 CPU 與 FPGA 的對歐式期權(quán)的定價結(jié)果如圖 10 與圖 11

所示。

圖 10 歐式期權(quán) CPU 定價結(jié)果

圖 11 歐式期權(quán) FPGA 定價結(jié)果

改變蒙特卡羅模擬次數(shù)，對定價性能進行比較，如圖 12 所示，可以看到，模擬次數(shù)越多，F(xiàn)PGA 能夠

更大程度地釋放性能。

MT Generation 傳入的隨機數(shù)值域限定在 0~1 之間，此時滿足（0，1）上的均勻分布，隨后通過 Box-Muller

算法將（0，1）上的均勻分布轉(zhuǎn)化為標(biāo)準(zhǔn)正態(tài)分布，進行下面的計算。對于歐式期權(quán)，可直接使用 BS 公

式進行定價，將結(jié)果寫入 Channel 2 中，由于運算邏輯簡單，可使用 NDRange 提升計算性能，每次下發(fā) 8192

個計算任務(wù)，充分使用流水線計算。對于雪球期權(quán)，在 BS 公式的基礎(chǔ)上，還需要進行復(fù)雜的向量運算，

來模擬三種不同的情景，所以每次展開一條蒙特卡羅路徑進行模擬，將每條路徑的模擬價格寫入 Channel 2

中，每條路徑內(nèi)部的 for 循環(huán)可以使用數(shù)據(jù)并行來提高計算性能。

最后 Partial Accumulation 部分為累加求和,從 Channel ２中讀取出期權(quán)價格之和，寫回 Buffer 中。對

于歐式期權(quán)，每次發(fā)送 8192 個線程，所以需要讀取完 8192 個數(shù)據(jù)；對于雪球期權(quán)，進行了 mc 條蒙特卡

羅路徑的模擬，所以需要讀取完 mc 個數(shù)據(jù)。將和寫回主機的 Result Buffer 中求取平均值完成最終的期權(quán)定

價。

4 CDEF>GH

CPU 和 FPGA 在期權(quán)定價流程中有各自擅長的模塊，本次驗證對歐式期權(quán)和雪球期權(quán)定價最終性能在

CPU 和 FPGA 上進行綜合對比。

測試驗證對比環(huán)境：

CPU: Intel core i7 10700 @2.9GHz 8 cores

FPGA: Intel PAC D5005 with Stratix 10 GX FPGA

4.1 :;67IJGH

在相同參數(shù)與相同蒙特卡羅模擬次數(shù)情況下 CPU 與 FPGA 的對歐式期權(quán)的定價結(jié)果如圖 10 與圖 11

所示。

圖 10 歐式期權(quán) CPU 定價結(jié)果

圖 11 歐式期權(quán) FPGA 定價結(jié)果

改變蒙特卡羅模擬次數(shù)，對定價性能進行比較，如圖 12 所示，可以看到，模擬次數(shù)越多，F(xiàn)PGA 能夠

更大程度地釋放性能。

圖 10 ：歐式期權(quán) CPU 定價結(jié)果

圖 11 ：歐式期權(quán) FPGA 定價結(jié)果

40

交易技術(shù)前沿

圖圖 12 ：歐式期權(quán)性能對比 12 歐式期權(quán)性能對比

FPGA 資源使用情況如圖 13 所示。

圖 13 歐式期權(quán) FPGA 資源使用情況

4.2 <=67IJGH

同樣，在相同參數(shù)與相同蒙特卡羅模擬次數(shù)情況下 CPU 與 FPGA 對雪球期權(quán)的定價結(jié)果如圖 14 與圖

15 所示。

圖 14 雪球期權(quán) CPU 定價結(jié)果

圖 12 歐式期權(quán)性能對比

FPGA 資源使用情況如圖 13 所示。

圖 13 歐式期權(quán) FPGA 資源使用情況

4.2 <=67IJGH

同樣，在相同參數(shù)與相同蒙特卡羅模擬次數(shù)情況下 CPU 與 FPGA 對雪球期權(quán)的定價結(jié)果如圖 14 與圖

15 所示。

圖 14 雪球期權(quán) CPU 定價結(jié)果

圖 13 ：歐式期權(quán) FPGA 資源使用情況

圖 12 歐式期權(quán)性能對比

FPGA 資源使用情況如圖 13 所示。

圖 13 歐式期權(quán) FPGA 資源使用情況

4.2 <=67IJGH

同樣，在相同參數(shù)與相同蒙特卡羅模擬次數(shù)情況下 CPU 與 FPGA 對雪球期權(quán)的定價結(jié)果如圖 14 與圖

15 所示。

圖 14 雪球期權(quán) CPU 定價結(jié)果

圖 12 歐式期權(quán)性能對比

FPGA 資源使用情況如圖 13 所示。

圖 13 歐式期權(quán) FPGA 資源使用情況

4.2 <=67IJGH

同樣，在相同參數(shù)與相同蒙特卡羅模擬次數(shù)情況下 CPU 與 FPGA 對雪球期權(quán)的定價結(jié)果如圖 14 與圖

15 所示。

圖 14 雪球期權(quán) CPU 定價結(jié)果

圖 14 ：雪球期權(quán) CPU 定價結(jié)果

圖 15 ：雪球期權(quán) FPGA 定價結(jié)果

41

本期熱點

圖 15 雪球期權(quán) FPGA 定價結(jié)果

改變蒙特卡羅模擬次數(shù)，對定價性能進行比較，如圖 16 所示，同樣，隨著模擬次數(shù)的增加，F(xiàn)PGA

性能提升更加明顯。

圖 16 雪球期權(quán)性能對比

FPGA 資源使用情況如圖 17 所示。

圖 17 雪球期權(quán) FPGA 資源使用情況

圖 18 與圖 19 分別為雪球期權(quán)價格與波動率 sigma 以及票息 coupon 關(guān)系的線性回歸，計算符合預(yù)期

效果。

圖 15 雪球期權(quán) FPGA 定價結(jié)果

改變蒙特卡羅模擬次數(shù)，對定價性能進行比較，如圖 16 所示，同樣，隨著模擬次數(shù)的增加，F(xiàn)PGA

性能提升更加明顯。

圖 16 雪球期權(quán)性能對比

FPGA 資源使用情況如圖 17 所示。

圖 17 雪球期權(quán) FPGA 資源使用情況

圖 18 與圖 19 分別為雪球期權(quán)價格與波動率 sigma 以及票息 coupon 關(guān)系的線性回歸，計算符合預(yù)期

效果。

圖 16 ：雪球期權(quán)性能對比

圖 17 ：雪球期權(quán) FPGA 資源使用情況

圖 18 雪球期權(quán)價格與 sigma 的線性回歸

圖 19 雪球期權(quán)價格與 coupon 的線性回歸

CK圖 18 雪球期權(quán)價格與 sigma 的線性回歸

圖 18 ：雪球期權(quán)價格與 sigma 的線性回歸 圖 19 ：雪球期權(quán)價格與 coupon 的線性回歸

42

交易技術(shù)前沿

結(jié)論

本研究作為使用 oneAPI 在金融領(lǐng)域進行加

速的初步探索，使用 DPC++ 語言，采用流水線

并行與數(shù)據(jù)并行方式，設(shè)計出多種期權(quán)定價模

型，并分別通過對歐式期權(quán)定價與雪球期權(quán)定價

的對比分析，相比于傳統(tǒng)軟件處理方式，使用

FPGA 處理的綜合性能均可獲得較大的提升，并

且隨著模擬次數(shù)的增加，獲得更加精確的期權(quán)定

價結(jié)果的同時，F(xiàn)PGA 能夠更大程度地釋放性能，

在模擬 2M（2*1024*1024）條蒙特卡羅路徑時，

分別可獲得 20 倍左右與 30 倍左右的性能提升。

國泰君安在金融硬件加速領(lǐng)域深耕多年，后續(xù)將

繼續(xù)精進，使用 oneAPI 與 FPGA 在金融硬件加

速領(lǐng)域進行更多的研究與探索，為業(yè)內(nèi)持續(xù)輸出

經(jīng)驗。

43

探索與應(yīng)用

6 證券運維系統(tǒng)自動化代理平臺建設(shè)實踐

7 基于上證云的數(shù)據(jù)跨境流動管理方案研究與實現(xiàn)

8 安信證券網(wǎng)絡(luò)系統(tǒng)自動化運維平臺建設(shè)實踐

9 興業(yè)證券應(yīng)用性能監(jiān)控系統(tǒng)建設(shè)思路、方法和實踐

10 一種可擴展的多因素訪問控制方法及實踐

11 證券公司智慧營銷與服務(wù)平臺建設(shè)

12 證券行業(yè)網(wǎng)站智能數(shù)據(jù)搜索服務(wù)的研究與實踐

13 關(guān)于 ION GROUP 遭遇勒索病毒攻擊事件的分析

思考報告

交易技術(shù)前沿

45

證券運維系統(tǒng)自動化代理平臺

建設(shè)實踐

肖鋼、徐志彬、柴晨、王軍、喻文強、張皓凌 / 中信建投證券股份有限公司

E-mail ：chaichen@csc.com.cn

1、概述

在智能運維時代，自動化代理平臺是必不可

少的網(wǎng)絡(luò)運維系統(tǒng)。面對眾多運維子系統(tǒng)，系統(tǒng)

基本是“相互孤立、獨自運行”的，并沒有統(tǒng)一

的代理平臺對接龐雜的服務(wù)器，各個運維子系統(tǒng)

在執(zhí)行業(yè)務(wù)操作的時候，往往自研一套服務(wù)器交

互系統(tǒng)獨自進行， 既造成了公司內(nèi)部研發(fā)資源的

浪費，同時這些交互系統(tǒng)無論是系統(tǒng)架構(gòu)可用性

還是穩(wěn)定性，可擴展性上都差強人意。甚至有些

在全球數(shù)字化經(jīng)濟的大浪潮下，人工智能、區(qū)塊鏈、云計算和大數(shù)據(jù)等技術(shù)的發(fā)展

不斷沖擊著證券行業(yè)的運維模式。隨著運維體系的復(fù)雜化和服務(wù)器的差異化加劇，運維成

本不斷增長，運維人員的技術(shù)要求更加苛刻，因此，智能化、高可靠、統(tǒng)一的自動化代理

平臺成為證券運維體系的一項重點工作。

中信建投證券自動化代理平臺通過構(gòu)建統(tǒng)一的運維服務(wù)入口，將運維系統(tǒng)有機結(jié)合

在一起。近年來，微服務(wù)架構(gòu)與異步通信技術(shù)快速發(fā)展，并逐漸成為系統(tǒng)建設(shè)的主流技術(shù)，

微服務(wù)架構(gòu)與異步通信技術(shù)能夠有效提高系統(tǒng)穩(wěn)定性與可擴展性，為自動化代理平臺建設(shè)

提供了成熟的解決方案。本文通過介紹自動化代理平臺的探索和實踐，針對運維體系數(shù)字

化轉(zhuǎn)型中遇到的外部數(shù)據(jù)規(guī)范不統(tǒng)一、服務(wù)器差異化、運維系統(tǒng)復(fù)雜化等問題，分享解決

方案和實踐經(jīng)驗，助力證券行業(yè)數(shù)字化發(fā)展。

探索與應(yīng)用

46

業(yè)務(wù)場景下，還需要運維人員人為干預(yù)，手動的

在服務(wù)器上執(zhí)行運維指令，無形增加了運維人員

的工作難度，加大了運維成本。

自動化代理平臺將運維子系統(tǒng)和服務(wù)器有機

的連接在一起，通過自動化代理平臺統(tǒng)一對服務(wù)

器進行動態(tài)管理，同時使用高效的異步接口為運

維子系統(tǒng)提供服務(wù)。自動化代理平臺作為外部系

統(tǒng)和內(nèi)部服務(wù)器之間通信的橋梁，我們設(shè)計了文

件傳輸、命令調(diào)用等基礎(chǔ)功能，在此基礎(chǔ)上，又

將擴展出信息采集、數(shù)據(jù)備份、應(yīng)用部署和代理

節(jié)點狀態(tài)監(jiān)控等一系列功能。為了系統(tǒng)的穩(wěn)定運

行，需要對代理的穩(wěn)定性、安全性進行有效地把

握，所以對代理的性能的并發(fā)量、吞吐量、安全

性又有一定的要求。此外，還需要對代理的各個

客戶端進行統(tǒng)一管理，實現(xiàn)代理狀態(tài)監(jiān)控和自動

修復(fù)。

目前，運維系統(tǒng)逐漸走向智能化、標(biāo)準(zhǔn)化，

自動化代理平臺可節(jié)省大量人力運維成本，并且

可提供高效、穩(wěn)定的運維服務(wù)。如何利用云計算

技術(shù)與微服務(wù)架構(gòu)，構(gòu)建高可用、可擴展的自動

化代理平臺，成為證券公司亟需解決的問題。本

文將介紹中信建投證券對于自動化代理平臺的架

構(gòu)探索，并闡述架構(gòu)探索中的實踐與經(jīng)驗。

2、自動化代理平臺架構(gòu)

2.1 總體設(shè)計

自動化代理平臺采用微服務(wù)架構(gòu)，系統(tǒng)中的

各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松

耦合的。每個微服務(wù)僅關(guān)注某項獨立的功能模塊。

整體架構(gòu)具有快速部署、高擴展性、高容錯性和

去集中化等特點，主要由六個層級構(gòu)成 ：

（1）用戶層

用戶層是自動化代理平臺的操作入口，用戶

可以通過將運維管理系統(tǒng)與自動化代理平臺對接

來處理自身業(yè)務(wù)訴求，也可以通過訪問自動化代

理平臺的 Web 頁面進行人機交互。為了便于用

戶系統(tǒng)對接用戶層，我們提供了可直接集成的自

動化代理平臺工具包，用戶通過 API 指令調(diào)用自

動化代理平臺工具包，并由自動化代理平臺工具

包來完成與自動化代理平臺系統(tǒng)的交互。

（2）網(wǎng)關(guān)層

網(wǎng)關(guān)層可以對外暴露聚合 API，屏蔽內(nèi)部微

服務(wù)的微小變動，保持整個系統(tǒng)的穩(wěn)定性。

在運維體系中，通常會有眾多終端服務(wù)器，

他們提供不同類型的服務(wù)，且通常分布在不同的

物理機房中。想要從用戶層精準(zhǔn)的操作某一個機

圖 1 ：自動化代理平臺層級結(jié)構(gòu)圖 圖 1 自動化代理平臺層級結(jié)構(gòu)圖

（1）用戶層

用戶層是自動化代理平臺的操作入口，用戶可以通過將運維管理系統(tǒng)與自動化代理平臺對接來處理自

身業(yè)務(wù)訴求，也可以通過訪問自動化代理平臺的 Web 頁面進行人機交互。為了便于用戶系統(tǒng)對接用戶層，

我們提供了可直接集成的自動化代理平臺工具包，用戶通過 API 指令調(diào)用自動化代理平臺工具包，并由自

交易技術(shù)前沿

47

房的某一臺服務(wù)器通常是很困難和繁瑣的。自動

化代理平臺采用了二級代理和動態(tài)路由的方案解

決了這個痛點問題，通過在物理機房部署二級代

理，將機房內(nèi)的服務(wù)器使用 Netty 連接在一起，再

通過動態(tài)路由的方式將用戶請求路由到各二級代

理，最終通過 Netty 完成指定服務(wù)器的業(yè)務(wù)操作。

當(dāng)然這只是網(wǎng)關(guān)層眾多功能中的一部分，它

還可以做負(fù)載均衡，統(tǒng)一鑒權(quán)，協(xié)議轉(zhuǎn)換，監(jiān)控

監(jiān)測等一系列功能。

（3）熔斷層

分布式系統(tǒng)環(huán)境下，服務(wù)間依賴非常常見，

一個業(yè)務(wù)調(diào)用通常依賴多個基礎(chǔ)服務(wù)。對于同步

調(diào)用，當(dāng)某服務(wù)不可用時，會導(dǎo)致上級服務(wù)的請

求線程被阻塞，當(dāng)有大批量上級服務(wù)請求時，最

終可能導(dǎo)致整個系統(tǒng)資源耗盡，無法繼續(xù)對外提

供服務(wù)。并且這種不可用可能沿請求調(diào)用鏈向上

傳遞，導(dǎo)致雪崩效應(yīng)。因此，為了構(gòu)建穩(wěn)定、可

靠的分布式系統(tǒng)，熔斷層必不可少，熔斷層能夠

對對來自依賴的故障進行隔離，當(dāng)依賴服務(wù)不可

用時，當(dāng)前服務(wù)啟動自我保護功能，從而避免發(fā)

生雪崩效應(yīng)。

（4）服務(wù)層

服務(wù)層負(fù)責(zé)提供可復(fù)用的服務(wù)，通過集群

方式實現(xiàn)高可用，用戶層通過分布式服務(wù)調(diào)用框

架訪問到服務(wù)層，分布式服務(wù)調(diào)用框架會在網(wǎng)關(guān)

層實現(xiàn)軟件負(fù)載均衡，并通過服務(wù)注冊中心服務(wù)

EurekaServer 對提供服務(wù)的服務(wù)器進行心跳檢測，

發(fā)現(xiàn)有服務(wù)不可用，立即通知客戶端程序修改服

務(wù)訪問列表，剔除不可用的服務(wù)器。

AgentServer 在架構(gòu)上充當(dāng)了二級代理的角

色，通過 AgentServer 將用戶層和邏輯層連接在

一起，AgentServer 在功能上是自動化代理平臺的

核心服務(wù)，通過 Netty 服務(wù)端的形式與邏輯層的

服務(wù)器中的 Netty 客戶端進行連接，將用戶層請

求處理過后交由邏輯層進行執(zhí)行。

AgentRegister 主要有兩個作用，一是作為

Netty 客戶端的注冊中心，對 Netty 連接狀態(tài)進行

監(jiān)控管理，二是為網(wǎng)關(guān)層提供動態(tài)的 Netty 連接

信息，是實現(xiàn)動態(tài)路由的關(guān)鍵。

（5）邏輯層

邏輯層包含特定于業(yè)務(wù)領(lǐng)域的邏輯，是最終

進行業(yè)務(wù)操作的環(huán)節(jié)。各服務(wù)器通過 Netty 客戶

端與服務(wù)層建立連接，接收服務(wù)層請求并完成相

應(yīng)業(yè)務(wù)邏輯，對于耗費資源類操作部分通過服務(wù)

層運算完成后再交由邏輯層進一步處理，避免服

務(wù)器負(fù)載過高影響其他交易系統(tǒng)的操作。

（6）數(shù)據(jù)層

數(shù)據(jù)層是操作數(shù)據(jù)（數(shù)據(jù)庫或者文本文件等）

的操作層，為業(yè)務(wù)邏輯層或控制層提供數(shù)據(jù)服務(wù)。

對于使用頻率較低，數(shù)據(jù)量龐大的數(shù)據(jù)，例如審

計信息、歷史數(shù)據(jù)等，使用關(guān)系型數(shù)據(jù)庫 MySQL

進行管理，對于使用頻率較高，同時對使用場景

的響應(yīng)時間要求較為嚴(yán)格的關(guān)鍵數(shù)據(jù)，在存儲

MySQL 的同時還運用到了緩存數(shù)據(jù)庫 Redis，一

來提升數(shù)據(jù)查詢的響應(yīng)速度，二來對 MySQL 進

一步保護，避免出現(xiàn)緩存擊穿和雪崩，三來提供

分布式鎖，避免集群場景下的服務(wù)間狀態(tài)不感知

導(dǎo)致的業(yè)務(wù)故障。

2.2 技術(shù)框架

自動化代理平臺技術(shù)選型為 Spring Cloud 微

服務(wù)架構(gòu)和 Netty 框架。

Spring Cloud 是一系列框架的有序集合。它

利用 Spring Boot 的開發(fā)便利性巧妙地簡化了分

布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)，如服務(wù)發(fā)現(xiàn)注冊、配

置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)

控等。Spring Cloud 作為一套成熟的分布式服務(wù)

治理的框架，已得到了廣泛的應(yīng)用。

Netty 是一款用于開發(fā)高性能網(wǎng)絡(luò)系統(tǒng)的

Java 框架，它封裝了網(wǎng)絡(luò)編程的復(fù)雜性，使得網(wǎng)

絡(luò)編程更容易的實現(xiàn)，同時 Netty 作為高度可伸

縮的、異步的、事件驅(qū)動的網(wǎng)絡(luò)編程框架，完美

契合了自動化代理平臺對多服務(wù)器管理、快速響

應(yīng)、異步調(diào)用的場景需要。

探索與應(yīng)用

48

自動化代理平臺采用網(wǎng)關(guān)加二級代理的通信

方式，用戶側(cè)請求進入網(wǎng)關(guān)后動態(tài)路由到對應(yīng)物

理機房的二級代理，再通過二級代理與服務(wù)器之

間的 Netty 連接進行進一步業(yè)務(wù)操作。同時 Netty

的連接信息通過注冊中心進行管理，并動態(tài)刷新

到網(wǎng)關(guān)，使得網(wǎng)關(guān)能將用戶請求正確路由到對應(yīng)

二級代理。如圖 2 所示。

二級代理的方式解決不同物理機房間服務(wù)

器網(wǎng)絡(luò)不互通的安全需求，機房中使用 Netty 架

構(gòu)構(gòu)建二級代理和服務(wù)器的連接?；?Netty 無

連接數(shù)據(jù)報套接字支持和相較 Java 核心 API 更

高的吞吐量以及更低的延遲，使得二級代理能同

時處理成千上萬的并發(fā)客戶端。客戶端創(chuàng)建消息

處理的入站處理器流和出站處理器流，并向服

務(wù)端發(fā)起建聯(lián)請求。二級代理作為服務(wù)端創(chuàng)建

消息處理的入站處理器流和出站處理器流，并

通過 Channel 完成與客戶端的對接。在業(yè)務(wù)處理

時，二級代理通過目標(biāo)索引獲取到對應(yīng)服務(wù)器的

Channel，使用事件對服務(wù)器進行業(yè)務(wù)指令下發(fā)。

注冊中心用于統(tǒng)籌全局的服務(wù)器信息，作為

特殊的 Netty 客戶端與各物理機房的二級代理服

務(wù)端建連，實時同步服務(wù)器信息并將數(shù)據(jù)寫入本

地數(shù)據(jù)庫中。同時將二級代理與服務(wù)器之間的基

本信息存入緩存數(shù)據(jù)庫，并將該緩存數(shù)據(jù)與網(wǎng)關(guān)

實時共享。

自動化代理平臺為用戶提供 Restful 和 API

兩種類型的調(diào)用接口，Restful 接口主要用于操作

指令，如服務(wù)升級、信息采集等，API 接口提供

文件的上傳下載。Restful 接口進入網(wǎng)關(guān)后，網(wǎng)關(guān)

根據(jù)指令的服務(wù)器信息從緩存中匹配對應(yīng)的二級

代理，并負(fù)載均衡的將請求路由到指定二級代理。

API 接口需要用戶系統(tǒng)導(dǎo)入自動化代理平臺為用

AgentRegister 主要有兩個作用，一是作為 Netty 客戶端的注冊中心，對 Netty 連接狀態(tài)進行監(jiān)控管理，

二是為網(wǎng)關(guān)層提供動態(tài)的 Netty 連接信息，是實現(xiàn)動態(tài)路由的關(guān)鍵。

（5）邏輯層

邏輯層包含特定于業(yè)務(wù)領(lǐng)域的邏輯，是最終進行業(yè)務(wù)操作的環(huán)節(jié)。各服務(wù)器通過 Netty 客戶端與服務(wù)

層建立連接，接收服務(wù)層請求并完成相應(yīng)業(yè)務(wù)邏輯，對于耗費資源類操作部分通過服務(wù)層運算完成后再交

由邏輯層進一步處理，避免服務(wù)器負(fù)載過高影響其他交易系統(tǒng)的操作。

（6）數(shù)據(jù)層

數(shù)據(jù)層是操作數(shù)據(jù)（數(shù)據(jù)庫或者文本文件等）的操作層，為業(yè)務(wù)邏輯層或控制層提供數(shù)據(jù)服務(wù)。對于

使用頻率較低，數(shù)據(jù)量龐大的數(shù)據(jù)，例如審計信息、歷史數(shù)據(jù)等，使用關(guān)系型數(shù)據(jù)庫 MySQL 進行管理，

對于使用頻率較高，同時對使用場景的響應(yīng)時間要求較為嚴(yán)格的關(guān)鍵數(shù)據(jù)，在存儲 MySQL 的同時還運用

到了緩存數(shù)據(jù)庫 Redis，一來提升數(shù)據(jù)查詢的響應(yīng)速度，二來對 MySQL 進一步保護，避免出現(xiàn)緩存擊穿和

雪崩，三來提供分布式鎖，避免集群場景下的服務(wù)間狀態(tài)不感知導(dǎo)致的業(yè)務(wù)故障。

2.2 <=>7

自動化代理平臺技術(shù)選型為 Spring Cloud 微服務(wù)架構(gòu)和 Netty 框架。

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)

基礎(chǔ)設(shè)施的開發(fā)，如服務(wù)發(fā)現(xiàn)注冊、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等。Spring Cloud

作為一套成熟的分布式服務(wù)治理的框架，已得到了廣泛的應(yīng)用。

Netty 是一款用于開發(fā)高性能網(wǎng)絡(luò)系統(tǒng)的 Java 框架，它封裝了網(wǎng)絡(luò)編程的復(fù)雜性，使得網(wǎng)絡(luò)編程更容

易的實現(xiàn)，同時 Netty 作為高度可伸縮的、異步的、事件驅(qū)動的網(wǎng)絡(luò)編程框架，完美契合了自動化代理平

臺對多服務(wù)器管理、快速響應(yīng)、異步調(diào)用的場景需要。

自動化代理平臺采用網(wǎng)關(guān)加二級代理的通信方式，用戶側(cè)請求進入網(wǎng)關(guān)后動態(tài)路由到對應(yīng)物理機房的

二級代理，再通過二級代理與服務(wù)器之間的 Netty 連接進行進一步業(yè)務(wù)操作。同時 Netty 的連接信息通過注

冊中心進行管理，并動態(tài)刷新到網(wǎng)關(guān)，使得網(wǎng)關(guān)能將用戶請求正確路由到對應(yīng)二級代理。如下圖所示：

圖 2 自動化代理平臺架構(gòu)圖

二級代理的方式解決不同物理機房間服務(wù)器網(wǎng)絡(luò)不互通的安全需求，機房中使用 Netty 架構(gòu)構(gòu)建二級

代理和服務(wù)器的連接?；?Netty 無連接數(shù)據(jù)報套接字支持和相較 Java 核心 API 更高的吞吐量以及更低的

延遲，使得二級代理能同時處理成千上萬的并發(fā)客戶端?？蛻舳藙?chuàng)建消息處理的入站處理器流和出站處理

器流，并向服務(wù)端發(fā)起建聯(lián)請求。二級代理作為服務(wù)端創(chuàng)建消息處理的入站處理器流和出站處理器流，并

通過 Channel 完成與客戶端的對接。在業(yè)務(wù)處理時，二級代理通過目標(biāo)索引獲取到對應(yīng)服務(wù)器的 Channel，

圖 2 ：自動化代理平臺架構(gòu)圖 使用事件對服務(wù)器進行業(yè)務(wù)指令下發(fā)。

圖 3 自動化代理平臺消息流轉(zhuǎn)圖

注冊中心用于統(tǒng)籌全局的服務(wù)器信息，作為特殊的 Netty 客戶端與各物理機房的二級代理服務(wù)端建連，

實時同步服務(wù)器信息并將數(shù)據(jù)寫入本地數(shù)據(jù)庫中。同時將二級代理與服務(wù)器之間的基本信息存入緩存數(shù)據(jù)

庫，并將該緩存數(shù)據(jù)與網(wǎng)關(guān)實時共享。

自動化代理平臺為用戶提供Restful和API兩種類型的調(diào)用接口Restful接口主要用于操作指令如圖 3 ：自動化代理平臺消息流轉(zhuǎn)圖