主管 ：上海證券交易所

主辦 ：上海證券交易所

總編 ：邱勇、蔡建春

副總編 ：王泊

執(zhí)行總編 ：唐憶

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

上海市楊高南路 388 號

郵編 ：200127

電話 ：021-68607129，021-68607131

傳真 ：021-68813188

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

內部資料 2022 年第四期（總第 51 期）

準印證號 ：滬（K）0671

NO.4

交易技術前沿THE FORELAND OF TRADING TECHNOLOGY

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《基于證通云的數據跨境流動管理方案的研究與實現》旨在通過綜合運用數據加密、權限控制、

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

《交易技術前沿》編輯部

2023 年 3 月 23 日

篇首語

本期熱點

探索與應用

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

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

陸頌華、王東、袁康

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

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

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

李彪

4

11

17

24

34

目錄

信息資訊采擷

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

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

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

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

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

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

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

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

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

45

51

57

71

79

85

91

94

本期熱點

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

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

管理平臺設計與實現

3 機構交易接入中臺建設實踐

4 可復用數據處理框架在證券數據處理中的探索和實踐

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

本期熱點

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

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

E-mail ：yinggl@cffex.com.cn

4

1、關鍵技術問題

如何提升軟件可靠性 ：軟件可靠性是軟件質

量體系中最重要的衡量指標之一，根據軟件可靠

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

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

應對軟件故障也有較豐富的應對手段，如圖 1 所

示，但面對其他軟件邏輯缺陷或架構級別嚴重缺

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

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

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

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

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

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

!\"#$%&'(

應國力 1

，仇沂 1

，李雯 1

，王維 1

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

E-mail ：yinggl@cffex.com.cn

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

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

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

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

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

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

1 )*+,-.

如何提升軟件可靠性：軟件可靠性是軟件質量體系中最重要的衡量指標之一，根據軟件可靠性理論，

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

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

運

維

類

事

故

基礎設施類

事故

軟件類事故

應用層

架構層

兩套實時

監(jiān)控軟件

應急并行

排障環(huán)境

每15分鐘

人工巡檢

現場應急

處理小組

突發(fā)事件

應急預案

IT 災難

恢復計劃

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

性計劃

硬件單點

故障

硬件大面

積故障

軟件單

指令故障

其他軟件

邏輯缺陷

軟件主備切換

硬件雙機冗余

同城災備切換

異地遠備切換

應用自動避障

跳過1條致命指令

?

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

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

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

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

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

交易技術前沿

5

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

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

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

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

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

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

極簡的前提下，如何實現高性能目標也是難點之

一。

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

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

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

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

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

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

數據一致性：異構系統(tǒng)與主系統(tǒng)架構不一致，

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

后仍能正確運行不出錯，也是關鍵之一。

“卡脖子”問題仍需攻關 ：面對嚴峻多變的

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

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

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

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

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

異構交易系統(tǒng)內部異構于主交易系統(tǒng)，采用

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

為中心、內置查詢業(yè)務和行情生成的架構，外部

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

體架構如圖 2 所示。

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

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

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

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

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

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

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

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

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

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

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

可降低異構系統(tǒng)運維的復雜度。

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

切換時省去反演恢復數據的時間，提高切換效率，

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

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

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

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

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

上行流 行情流

結果流

主交易系

統(tǒng)

會員柜臺系統(tǒng)

FibPro

xy

生產結果流

切換指令

初始化 上場

異構交易核心

行情生成

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

查詢

交易流水線

查詢請求

查詢應答

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

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

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

多播、高級容錯組件等。

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

本期熱點

6

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

從運行方式與數據流向上來看，異構交易系

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

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

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

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

3、系統(tǒng)關鍵技術

3.1 運行模式及流水復制恢復技術

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

和恢復模式。運行模式屬于架構層的概念，它決

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

紹如下 ：

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

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

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

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

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

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

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

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

的全量流。此模式下應用了流水復制恢復技術，

只處理結果消息，用來復制主中心的撮合結果，

恢復構建對應業(yè)務域狀態(tài)、內存表以及相關變量

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

保證異構一致性。收到切換指令后，異構交易系

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

模式的變化 ：取消訂閱主中心結果流，轉向訂閱

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

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

認為此模式。

3.2 基于聚合根的多層領域模型

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

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

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

的業(yè)務模型進行了完全的重構，通過異構避免嚴

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

全新的領域服務校驗模型內部通過業(yè)務功

能、領域模型、內存數據三層進行劃分，配合數

據聚合根，業(yè)務邏輯不再關心數據存取訪問，模

型抽象程度更高。同時，領域服務不依賴外部系

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

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

3.3 高性能多級流水線模型

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

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

立的若干部分，每個部分由一個線程驅動，線程

之間共享消息隊列。

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

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

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

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

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

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

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

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

以內。

從技術模型實現來看，異構交易系統(tǒng)的業(yè)務

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

認為此模式。

3.2 :;<=>?@ABC2D

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

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

軟件可靠性。

全新的領域服務校驗模型內部通過業(yè)務功能、領域模型、內存數據三層進行劃分，配合數據聚合根，

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

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

3.3 EFG@H56I2D

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

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

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

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

訂閱 撮合 發(fā)布 訂

閱

撮

合

前

撮

合

撮

合

后

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

發(fā)

布

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

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

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

表 1 異構交易性能比對表

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

交易技術前沿

7

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

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

中，訂閱消息加工線程將異構交易上行的消息包

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

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

列的關鍵，控制著線程對同一個消息的讀寫權限，

第零級消息通常是上行數據包的原始數據，也就

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

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

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

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

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

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

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

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

對應關系。

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

模型而設計的組件，它的生產消費模式與多級流

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

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

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

既是生產者又是消費者。

在動態(tài)消息隊列中，消息頭的結構至關重要，

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

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

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

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

實現大致如圖 5 所示。

3.4 架構極簡及業(yè)務極簡

在技術架構方面，異構交易系統(tǒng)主要用于應

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

群，僅保留訂單、行情關鍵路徑模塊，構成最小

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

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

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

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

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

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

心計算邏輯。以不同的實現方式重構之后，實現

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

少了開發(fā)成本。

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

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

7

訂閱 撮合 發(fā)布 訂

閱

撮

合

前

撮

合

撮

合

后

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

發(fā)

布

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

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

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

表 1 異構交易性能比對表

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

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

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

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

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

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

是多個線程訪問消息隊列的關鍵，控制著線程對同一個消息的讀寫權限，第零級消息通常是上行數據包的

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

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

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

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

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

認為此模式。

3.2 :;<=>?@ABC2D

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

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

軟件可靠性。

全新的領域服務校驗模型內部通過業(yè)務功能、領域模型、內存數據三層進行劃分，配合數據聚合根，

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

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

3.3 EFG@H56I2D

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

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

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

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

訂閱 撮合 發(fā)布 訂

閱

撮

合

前

撮

合

撮

合

后

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

發(fā)

布

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

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

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

表 1 異構交易性能比對表

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

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

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

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

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

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

是多個線程訪問消息隊列的關鍵，控制著線程對同一個消息的讀寫權限，第零級消息通常是上行數據包的

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

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

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

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

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

表 1 ：異構交易性能比對表

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

本期熱點

8

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

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

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

的輕量級和靈活性。

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

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

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

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

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

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

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

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

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

維指標視圖，所有指標均支持分鐘粒度告警和回

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

時段功能。

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

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

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

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

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

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

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

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

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

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

3.6 平滑切換

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

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

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

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

到會員端無感知。對內支持斷點續(xù)傳，保證了數

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

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

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

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

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

線程和撮合及撮合后處理線程既是生產者又是消費者。

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

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

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

圖 5 動態(tài)消息隊列實現結構

3.4 /\"JK4LMJK

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

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

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

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

了業(yè)務應用層的簡化，精簡了核心計算邏輯。以不同的實現方式重構之后，實現了相同的業(yè)務功能，業(yè)務

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

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

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

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

3.5 0NOP4QR>STU%&

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

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

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

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

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

圖 5 ：動態(tài)消息隊列實現結構

交易技術前沿

9

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

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

致。以主模式運行時，為了保證重構結果的一致

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

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

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

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

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

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

方案 ：

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

復模式下的撮合結果及行情流水，進行交易結果

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

復模式下主系統(tǒng)與異構系統(tǒng)的數據一致性 ；

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

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

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

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

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

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

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

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

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

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

3.7 國產化自主可控

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

行時的各項指標。

數據庫（事件庫，交易知識庫，推導規(guī)則庫，歷史事件庫）

EventMatch

事件匹配

事件

GenGraph

生成故障分析圖譜

交易知識 圖譜存儲

EventAnalysis

根因推導

推導規(guī)則

② ④

時間序列數據庫

③

LogParse

日志解析

EventShow

根因展示

⑤

智能運維交互終端

⑥

砸緯紉愿

LightCam ①

同步日志

告警

①

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

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

維成本。

3.6 VWXY

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

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

對內支持斷點續(xù)傳，保證了數據一致性與完整性。在業(yè)務層面保證了平滑切換，切換后的所支持的業(yè)務也

維持不變。

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

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

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

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

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

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

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

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

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

正確性，不參與應急切換。

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

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

3.7 Z[\\]^_`

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

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

本期熱點

最為核心的交易基礎設施。異構交易系統(tǒng)上線后，

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

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

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

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

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

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

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

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

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

要作用。

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

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

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

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

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

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

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

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

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

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

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

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

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

縮短研發(fā)周期。

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

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

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

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

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

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

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

落地，實現了軟件層硬件層雙異構，提升了核心

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

5、總結與展望

本文對異構交易系統(tǒng)的技術難點、架構、關

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

加變幻莫測，“交易不斷，數據不亂”的目標仍

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

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

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

定運行作出貢獻。

10

交易技術前沿

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

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

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

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

活性的特征。

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

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

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

E-mail ：hyl13866@haitong.com

1、引言

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

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

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

行機構都在使用分布式的平臺和架構用以提高交

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

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

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

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

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

控的鏈路技術也是保障數據安全與網絡安全的關

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

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

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

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

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

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

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

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

11

本期熱點

12

絡安全、數據安全。

2、多技術平臺兼容適配

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

于外部供應廠商，自主選擇余地較小。同時關鍵

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

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

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

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

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

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

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

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

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

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

UI 組件體系。研發(fā)平臺提供統(tǒng)一的技術標準與

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

和質量。

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

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

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

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

現不同功能的結合與分離，從而更加便捷高效地

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

“基座 + 插件”的架構模式，“基座”保證整體框

架的穩(wěn)定性、兼容性、連續(xù)性?！安寮庇糜跀U

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

以快速響應客戶需求。

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

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

源碼掌控能力。

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

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

理平臺采用 B/S 架構，開放兼容多個應用技術創(chuàng)

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

保障網絡安全、數據安全，搭建了穩(wěn)固的自有生

態(tài)。

如圖 2 所示，對于瀏覽器，其可兼容多種應

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

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

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

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

應用中間件、Nginx 及緩存服務，其兼容東方通

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

于數據庫，其適配 Oracle、達夢數據庫、巨杉數

據庫等數據獨立存儲的關系型數據庫，也適配

MYSQL、GOLDENDB GOLDENDB、TiDB 等 分 布 式 數 據 庫。 等 分 布 式 數 據 庫。

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

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

N I?6789*+CDOPN

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

模塊外，還擁有豐富的插件化架構體系，使得在平臺建設過程中可以自由組合各模塊，實現不同功能的結

圖 1 ：運營管理平臺技術框架圖

交易技術前沿

13

用服務器架構平臺。

3、統(tǒng)一路由應用層設計與實現

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

據庫變更內容實時采集同步至匯總數據庫，用于

匯總數據查詢。

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

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

!

T?5.UVRKW:;<=>?

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

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

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

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

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

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

XHI?6789*+5.UVYZ=>?

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

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

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

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

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

N X?6789*+[U

1）WEB 服務采用 Nginx 反向代理負載均衡

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

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

響應和更好的用戶體驗。

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

圖 3 ：運營管理平臺鏈路

1）WEB 服務采用 Nginx 反向代理負載均衡

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

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

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

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

理，以保證更快的響應和更好的用戶體驗。

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

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

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

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

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

能力。!

GHG?%&'QRKCDS-*+?

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

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

N G?%&'RKCDS-*+

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

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

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

德的 BES 等。對于數據庫，其適配 Oracle、達夢數據庫、巨杉數據庫等數據獨立存儲的關系型數據庫，也

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

本期熱點

14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

全性與路由準確性。

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

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

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

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

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

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

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

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

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

route 字段。

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

DataPower 作為公司級企業(yè)服務總線的關鍵

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

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

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

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

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

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

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

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

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

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

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

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

1）擴展可靠性

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

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

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

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

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

2）配置靈活性

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

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

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

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

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

3.2.2 路由策略控制

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

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

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

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

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

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

2）客戶級 ：根據客戶號獲取客戶所屬交易

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

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

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

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

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

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

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

統(tǒng)路由。

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

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

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

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

交易技術前沿

15

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

1）參數設置類 ：操作人員使用同一客戶端

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

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

的參數設置模式。

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

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

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

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

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

節(jié)點，對于此節(jié)點內的全部有權限數據進行查詢。

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

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

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

能。

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

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

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

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

驟。

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

流程

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

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

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

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

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

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

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

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

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

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

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

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

提高了運維升級效率。

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

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

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

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

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

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

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

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

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

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

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

N ^?_`UVab

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

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

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

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

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

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

XHX?5.UVcd\\]?

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

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

員使用需求：

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

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

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

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

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

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

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

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

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

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

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

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

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

圖 4 ：分級路由策略

本期熱點

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

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

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

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

性、全面性。

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

fgh]ijkl?

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

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

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

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

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

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

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

N m?klijn

]oijn,=pqr?

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

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

性。

數據庫不僅支持本地局域網數據同步，還支持跨廣域網數據同步。同時其還支持增量同步，數據

輸，減少網絡帶寬。

tgklij?

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

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

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

圖 5 ： 匯總數據庫

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

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

不影響主庫的正常使用，使用備數據庫進行數據

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

絡影響最小化，同時在秒級水平進行數據同步，

保證數據的實時性和一致性。

匯總數據庫不僅支持本地局域網數據同步，

還支持跨廣域網數據同步。同時其還支持增量同

步，數據壓縮傳輸，減少網絡帶寬。

4.2 視圖形式匯總數據

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

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

據庫對象集合匯總構建的視圖，根據不同數據表

結構和業(yè)務含義將不同的表進行去重排序。采用

視圖的形式使得基表中的數據安全性得以保障，

同時可以聚焦于特定的數據集合，增強邏輯數據

的獨立性。

4.3 匯總數據查詢服務、盯市服務

匯總數據查詢服務部署于匯總數據庫的服務

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

詢匯總庫中的數據。對于匯總類公共數據，操作

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

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

匯總數據查詢服務，對于此匯總數據庫內的全部

有權限數據進行查詢。

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

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

數據庫的數據實時同步至服務內的內存數據庫中

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

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

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

5、總結

本文首先介紹了基于分布式架構的海通證券

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

參考與借鑒。

16

交易技術前沿

17

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

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

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

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

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

機構交易接入中臺建設實踐

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

E-mail ：huchangchun@orientsec.com.cn

1、引言

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

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

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

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

期貨等持牌機構量化業(yè)務客戶通過類 CTP 的 API

接口對接進行證券交易，日均交易量百億規(guī)模。

隨著東方證券機構交易生態(tài)圈逐漸完善以及 OST

極速交易系統(tǒng)在量化客戶中口碑穩(wěn)步提升，除極

速量化客戶外，越來越多高凈值客戶及活躍交易

型客戶均希望通過原有機構交易終端在 OST 極速

交易系統(tǒng)中進行交易。其次為夯實財富管理業(yè)務

基石，快速響應公司財富管理業(yè)務轉型發(fā)展需要，

提升公司核心業(yè)務系統(tǒng)的連續(xù)服務能力，保障安

全穩(wěn)定，東方證券開始構建統(tǒng)一技術架構的新一

本期熱點

18

代核心業(yè)務系統(tǒng)逐步替換原有集中交易系統(tǒng)。另

外為進一步落實以量化交易為重點的機構經紀業(yè)

務的定位，為客戶提供從策略生成到交易執(zhí)行、

軟硬件配置等一系列優(yōu)化支持服務，在量化交易

領域中的保持領先優(yōu)勢，滿足特定客戶需求可能

會進一步引入 FPGA 極速交易系統(tǒng)。

為支持機構交易終端接入 OST 極速交易系

統(tǒng)、集中交易系統(tǒng)、新一代核心業(yè)務系統(tǒng)、以及

可能后續(xù)可能引入的 FPGA 極速交易系統(tǒng)等第三

方快速交易系統(tǒng)，機構交易接入中臺兼容不同交

易系統(tǒng)接口協(xié)議，為機構交易終端提供統(tǒng)一接入，

屏蔽后臺復雜性和差異性。機構交易終端對接中

臺后，客戶在不同交易系統(tǒng)切換，機構交易終端

系統(tǒng)無需重新對接開發(fā)，通過驗收測試后即可投

入生產，極大提高機構交易終端接入效率。

2、背景

2.1 交易系統(tǒng)

2.1.1 普通交易系統(tǒng)

普通交易系統(tǒng)即集中交易系統(tǒng)為證券公司的

核心業(yè)務系統(tǒng)，定位于面向所有普通客戶進行全

部場內和部分場外交易。系統(tǒng)實現的目標是穩(wěn)定、

容量大并支持全業(yè)務，技術上主要基于傳統(tǒng)的關

系型數據庫模式，交易延時較高，并發(fā)有一定限制。

2.1.2 快速交易系統(tǒng)

快速交易系統(tǒng)目標客戶為有快速交易需求的

量化客戶 ；系統(tǒng)通常追求高性能、高可靠性、容

量可擴展，并支持場內大部分業(yè)務 ；技術上主要

采用內存交易技術，部分采用硬件加速機制。為

滿足客戶上海深圳報盤極致速度的要求，通常支

持靈活的雙節(jié)點，在上海和深圳分別部署，支持

同一投資者的兩個證券賬戶兩地就近報盤。

2.2 客戶交易渠道

2.2.1 普通散戶

客戶通過互聯網使用手機 APP、網上交易

PC 終端如同花順、通達信等接入普通交易系統(tǒng)

進行場內和場外交易。客戶對交易速度不敏感，

由于通過純手工操作，對百毫秒級別的延遲感知

不明顯。

2.2.2 極速量化客戶

極速量化客戶通常托管系統(tǒng)對接快速交易系

統(tǒng)進行場內競價交易。托管系統(tǒng)主要指極速量化

客戶自建的一套系統(tǒng)，該系統(tǒng)通過 API 對接證券

公司快速交易系統(tǒng)，并由證券公司向客戶購買后

部署在證券公司機房，僅提供給該客戶使用?？?/p>

戶對交易速度非常敏感，毫秒級延遲可能影響程

序化交易的收益，通常追求微秒級延遲?？蛻舫?/p>

主要通過托管系統(tǒng)進行交易外，通常還需要一套

備用機構交易終端，滿足客戶除托管系統(tǒng)交易外

的全業(yè)務交易需求。

2.2.3 機構交易終端客戶

機構交易終端客戶指通過機構交易終端進行

交易的客戶，主要包括使用 PB 交易終端，如迅

投 PB、恒生 PB 客戶、卡方、宇量策略平臺，和

機構 PC 交易終端，如同花順機構版、通達信機

構版、日內快速交易終端等的客戶。機構交易終

端客戶中的交易型客戶通常對交易速度較敏感，

通常追求毫秒級延遲，將客戶從普通交易系統(tǒng)遷

移至快速交易系統(tǒng)，能提升客戶交易體驗。

3、方案

3.1 總體方案

機構交易接入中臺核心需求為提供成熟的、

符合競價交易速度、穩(wěn)定性、連續(xù)性要求的統(tǒng)一

入口，承載機構交易統(tǒng)一協(xié)議，實現路由控制、

負載均衡、安全控制、流量控制、訪問控制、運

維支持等功能。

中臺基于多套交易系統(tǒng)提供的接口協(xié)議定

義機構交易統(tǒng)一協(xié)議，實現 C++、Java、Python

語言的 API 封裝機構交易統(tǒng)一協(xié)議 ；基于開源

Netty 開發(fā)實現 API 網關支持機構交易終端系統(tǒng)

交易技術前沿

19

接入，通過會話管控保證安全和訪問控制并通過

gRPC 協(xié)議實現 API 網關與交易系統(tǒng)適配模塊之

間內部通訊 ；并基于微服務 gRPC 框架實現交易

系統(tǒng)適配模塊，負責將機構交易統(tǒng)一協(xié)議適配轉

換為各種交易系統(tǒng)的接口協(xié)議。另外為簡化系統(tǒng)

復雜度并提高系統(tǒng)可用性，引入開源 Nginx 服務

器提供具體路由控制、負載均衡、流量控制能力；

為支持主推送方式接入，引入開源 Kafka 消息中

間件存儲回報消息，由 API 網關通過訂閱 Kafka

獲取和緩存回報消息并通過 TCP 協(xié)議推送至機構

交易終端。

3.2 API 與 gRPC 選擇

關于機構交易終端系統(tǒng)接入方式，支持類

CTP API 方式還是采用公司業(yè)務中臺廣泛推廣的

gRPC 接口，在比較 API 方式和 gRPC 接口的特

點后，考慮到主流 PB 交易終端系統(tǒng)的對接習慣，

以及 gRPC 接口在支持互聯網接入情況下可能遭

遇非法終端接入的風險，最終選擇支持 API 方式。

3.3 API 網關請求處理過程

為減少中心節(jié)點 API 網關的復雜度，提高系

統(tǒng)穩(wěn)定性，API 網關采用基于機構交易統(tǒng)一協(xié)議

<=3.1 >?<=

機構交易接入中臺核心需求為提供成熟的、符合競價交易速度、穩(wěn)定性、連續(xù)性要求的統(tǒng)一入口，

承載機構交易統(tǒng)一協(xié)議，實現路由控制、負載均衡、安全控制、流量控制、訪問控制、運維支持等功能。

圖 1 機構交易接入中臺總體架構圖

中臺基于多套交易系統(tǒng)提供的接口協(xié)議定義機構交易統(tǒng)一協(xié)議，實現 C++、Java、Python 語言的 API

封裝機構交易統(tǒng)一協(xié)議；基于開源 Netty 開發(fā)實現 API 網關支持機構交易終端系統(tǒng)接入，通過會話管控保

證安全和訪問控制并通過 gRPC 協(xié)議實現 API 網關與交易系統(tǒng)適配模塊之間內部通訊；并基于微服務

gRPC 框架實現交易系統(tǒng)適配模塊，負責將機構交易統(tǒng)一協(xié)議適配轉換為各種交易系統(tǒng)的接口協(xié)議。另外

為簡化系統(tǒng)復雜度并提高系統(tǒng)可用性，引入開源 Nginx 服務器提供具體路由控制、負載均衡、流量控制能

力；為支持主推送方式接入，引入開源 Kafka 消息中間件存儲回報消息，由 API 網關通過訂閱 Kafka 獲取

和緩存回報消息并通過 TCP 協(xié)議推送至機構交易終端。

圖 1 ： 機構交易接入中臺總體架構圖

3.2 API @ gRPC AB

關于機構交易終端系統(tǒng)接入方式，支持類 CTP API 方式還是采用公司業(yè)務中臺廣泛推廣的 gRPC 接

口，在比較 API 方式和 gRPC 接口的特點后，考慮到主流 PB 交易終端系統(tǒng)的對接習慣，以及 gRPC 接口

在支持互聯網接入情況下可能遭遇非法終端接入的風險，最終選擇支持 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é)議復雜，委

托、回報時延相對較高

適用場景 符合主流 PB 交易終端系統(tǒng)對接習慣 微服務架構，無需維護連接，無會話狀態(tài)，容易橫向擴

展

3.3 API CDEFGHIJ

為減少中心節(jié)點 API 網關的復雜度，提高系統(tǒng)穩(wěn)定性，API 網關采用基于機構交易統(tǒng)一協(xié)議的 gRPC

接交系統(tǒng)模塊機構交統(tǒng)協(xié)交系統(tǒng)接協(xié)的轉換交系統(tǒng)模塊完表 1 ：API 方式與 gRPC 接口對比

本期熱點

的 gRPC 接口調用交易系統(tǒng)適配模塊，機構交易

統(tǒng)一協(xié)議和交易系統(tǒng)接口協(xié)議的適配轉換由交易

系統(tǒng)適配模塊完成，API 網關負責解析通訊報文、

校驗報文入參、校驗會話、并根據業(yè)務功能、客戶、

請求參數確定路由信息，轉發(fā)請求和處理響應。

3.4 API 網關設計

API 網關主要內容包括 API 消息協(xié)議、API

網關初始化、會話管理、路由管理、訂閱推送等

功能。

API 消息協(xié)議 TCP 報文內容結構包括消息

頭、消息體、校驗位三部分。消息頭包括請求類

型、請求編號、業(yè)務消息長度、壓縮標志、最后

報文標志、API版本等內容；消息體包括業(yè)務消息；

校驗位為檢查報文內容有效性。

API 網關啟動初始化過程中，從管理數據庫

獲取資金賬戶白名單、以及關聯的 IP、MAC 信息，

并通過調用交易系統(tǒng)適配模塊 gRPC 服務獲取各

交易系統(tǒng)節(jié)點支持的資金賬戶和市場。

機構交易終端在與 API 網關建立 TCP 連接

后，調用登錄接口認證建立會話。建立會話過程

主要包括資金賬戶白名單、終端 IP、MAC 信息

校驗，以及交易密碼校驗，校驗通過后建立會話。

API 網關管理會話相關的 TCP 連接、資金賬戶、

消息訂閱狀態(tài)、終端信息等信息。在 TCP 連接斷

開時，API 網關注銷會話并清理會話相關內容。

API 網關根據請求資金賬戶和市場代碼，確定

客戶競價交易相關請求對應的交易系統(tǒng)節(jié)點。針對

圖 2 API 網關請求處理過程

3.4 API CD*K

API 網關主要內容包括 API 消息協(xié)議、API 網關初始化、會話管理、路由管理、訂閱推送等功能。

API消息協(xié)議TCP報文內容結構包括消息頭消息體校驗位三部分消息頭包括請求類型請求圖 2 ：API 網關請求處理過程

20

交易技術前沿

快速交易系統(tǒng)不支持的業(yè)務，確定客戶對應的普通

交易系統(tǒng)。通過在發(fā)往 Nginx 服務器的 gRPC 請求

元數據中加入交易系統(tǒng)類型信息，由 Nginx 服務器

將請求轉發(fā)至對應交易系統(tǒng)適配模塊。

3.5 交易系統(tǒng)適配模塊

東方證券制定了企業(yè)技術架構向以微服務為

核心的現代化架構轉型并選擇了具有跨語言特性

的 gRPC 為核心框架，并在其基礎之上新增服務

治理特性和星辰服務治理平臺，優(yōu)化改進服務質

量。綜合考慮 gRPC 協(xié)議多路復用、高效編解碼

方式、框架成熟度以及復用公司服務治理平臺提

供的監(jiān)控和告警等功能，交易系統(tǒng)適配模塊采用

gRPC 接口方式實現機構交易統(tǒng)一協(xié)議，供 API

網關內部調用?；跈C構交易統(tǒng)一協(xié)議，快速交

易系統(tǒng)適配模塊提供給其支持的競價交易相關的

接口，普通交易系統(tǒng)適配模塊基本涵蓋機構交易

統(tǒng)一協(xié)議定義的全部接口。

在引入新交易系統(tǒng)的情況下，通過新增交易

系統(tǒng)適配模塊，并在 API 網關和 Nginx 調整路由

配置，即可支持原有機構交易終端接入新的交易

系統(tǒng)。

4、實踐

4.1 統(tǒng)一協(xié)議

不同系統(tǒng)對于新股申購、ETF 申贖等業(yè)務功

能接口提供方式，資金賬戶、市場代碼等業(yè)務字

段命名，委托市價、信用交易相關參數的組成，

市場代碼、委托狀態(tài)字段取值均可能不同。

機構交易統(tǒng)一協(xié)議主要以快速交易系統(tǒng)提供

的接口為基礎，補充機構交易終端支持客戶全業(yè)

務交易時所需證券交易接口。其中針對普通賬戶，

支持普通買賣、ETF 申贖、國債逆回購、新股申

購、配股配債、轉股回售、港股通業(yè)務 ；針對信

用賬戶，提供擔保品買賣、信用交易、非交易委托、

新股申購業(yè)務 ；針對股票期權賬戶，提供買入開

倉、賣出平倉、賣出開倉、買入平倉、備兌開倉、

備兌平倉等業(yè)務。

機構交易統(tǒng)一協(xié)議主要包括接口清單、接口

出入參字段、字典字段取值三部分內容。機構交

易統(tǒng)一協(xié)議接口 73 個，其中同時支持普通賬戶、

信用賬戶、期權賬戶的接口 27 個 ；同時支持普

通賬戶、信用賬戶的接口 37 個 ；接口出入參字

段 413 個，其中浮點型字段 170 個，字符類型

114 個，整型字段 76 個，長整型字段 53 個，入

參字段 131 個 ；字典字段 41 個，包括委托狀態(tài)、

委托方式、委托屬性、市場代碼等。

4.2 全業(yè)務支持

由于快速交易系統(tǒng)主要支持競價交易業(yè)務如

普通買賣、ETF 申贖、國債逆回購、信用交易、

股票期權交易等，而對速度要求不高的業(yè)務如新

股申購、配股配債、轉股回售、港股通業(yè)務由普

通交易系統(tǒng)支持。統(tǒng)一協(xié)議中將委托接口主要拆

分為競價委托和普通交易系統(tǒng)委托。

關于競價委托，API 網關根據客戶競價交易

所在的交易系統(tǒng)，將請求轉發(fā)至對應的交易系統(tǒng)

適配模塊。而針對有的交易系統(tǒng)的競價委托業(yè)務，

如市價委托、限價委托、ETF 申購、ETF 贖回，

由不同的接口支持，交易系統(tǒng)適配模塊根據統(tǒng)一

協(xié)議確定請求具體業(yè)務類型，完成接口字段和字

典字段的適配，調用交易系統(tǒng)對應的 API。

關于普通交易系統(tǒng)委托，由于部分快速交易

系統(tǒng)也支持如新股申購、配股配債、轉股等業(yè)務，

API 網關根據統(tǒng)一協(xié)議中普通交易系統(tǒng)委托的委托

屬性判斷業(yè)務類型，并根據客戶該業(yè)務所在的交

易系統(tǒng)，將請求轉發(fā)至對應的交易系統(tǒng)適配模塊。

4.3 雙節(jié)點客戶支持

對于滬市深市證券賬戶分別在上海和深圳快

速交易系統(tǒng)節(jié)點的客戶，稱為雙節(jié)點客戶。通常

為追求報盤極致速度，這類客戶通過托管系統(tǒng)進

行交易。部分交易型的機構交易終端客戶也為雙

21

本期熱點

節(jié)點客戶。針對雙節(jié)點客戶交易、資金、持倉、

委托流水、成交流水在不同交易系統(tǒng)節(jié)點的情況，

傳統(tǒng)的方案是機構交易終端系統(tǒng)連接兩個不同交

易系統(tǒng)地址，分別進行對應市場的交易，客戶需

選擇對應的地址或賬號進行登錄。

中臺通過 API 網關路由和對查詢結果進行合

并匯總，實現單點接入的方式支持雙節(jié)點客戶。

對于客戶的資金、持倉、委托流水、成交流水在

不同節(jié)點的情況，API 網關分別將請求轉發(fā)至對

應交易系統(tǒng)節(jié)點，并將查詢結果進行合并匯總。

對于交易類請求，API 網關根據入參中市場代碼，

將請求轉發(fā)該市場對應交易系統(tǒng)節(jié)點。為兼容傳

統(tǒng)方案，API 網關通過偵聽不同的端口分別表示

對應上海、深圳、全市場交易系統(tǒng)節(jié)點。如果終

端系統(tǒng)連接上海或深圳交易系統(tǒng)節(jié)點對應的端

口，則 API 網關則將請求轉發(fā)至對應交易系統(tǒng)節(jié)

點，不進行雙節(jié)點消息的合并匯總處理。

4.4 消息訂閱

為支持主推送模式接入，避免機構交易終端

定時查詢的消息延遲，中臺支持消息訂閱，當委

托狀態(tài)發(fā)生變化或有成交產生時，主動推送消息

到機構交易終端。通常機構交易終端系統(tǒng)啟動時

以“從本交易日開始重傳消息”的訂閱模式接收

全量消息，在發(fā)生網絡異常情況下以“從上次收

到點續(xù)傳消息”的訂閱模式接收后續(xù)消息，部分

不需要全量消息的機構交易終端，以“只傳送訂

閱后的消息”的訂閱模式接收當時間節(jié)點后產生

的消息。

交易系統(tǒng)適配模塊根據各自交易系統(tǒng)對于委

托狀態(tài)和成交回報推送的方案，獲取當日推送消

息并轉換為機構交易統(tǒng)一協(xié)議定義的委托狀態(tài)和

成交回報消息，存儲到 Kafka 消息中間件。對于

不支持消息推送的交易系統(tǒng)，交易系統(tǒng)適配模塊

定時增量查詢獲取并存儲數據。

API 網關從 Kafka 消息中間件訂閱數據進行必

要轉換后在內存中按照客戶緩存消息隊列，并維

護會話中客戶消息訂閱請求和當前推送序號等狀

態(tài)，在有后續(xù)消息達到內存消息隊列時通過會話

的通訊通道主動推送消息到機構交易終端系統(tǒng)。

4.5 基于訂閱消息提供查詢

由于快速交易系統(tǒng)通過基于內存交易技術，

大量查詢請求可能影響快速交易系統(tǒng)交易性能。

中臺基于緩存的消息隊列，提供委托查詢和成交

查詢，避免委托查詢和成交查詢請求透傳至快速

交易系統(tǒng)。

對于成交查詢，成交回報消息即為成交明細

消息。API 網關維護客戶、消息定位串到成交回報

消息的映射關系，其中消息定位串以跳表的數據

結構組織，支持基于消息定位串入參的增量查詢。

對于委托查詢，每筆委托的最新委托狀態(tài)消

息即為該筆委托的查詢結果。API 網關維護客戶、

消息定位串到委托狀態(tài)消息的映射關系，并在委

托的最新消息到達時，更新映射關系。

基于緩存消息提供的查詢接口，在查詢性能

和并發(fā)支持方面有數量級提升。

4.6 委托引用

機構交易終端收到委托狀態(tài)消息時，通常使

用委托狀態(tài)消息的委托引用關聯原委托。由于部

分交易系統(tǒng)對委托引用取值規(guī)則進行限定或者定

義類型不一致，不能返回機構交易終端委托的委

托引用。中臺將委托引用定義為長整型字段，對

于支持長整型委托引用的交易系統(tǒng)，中臺采取透

傳方式；對于不支持長整型委托引用的交易系統(tǒng)，

中臺維護委托引用和委托的關系，并在委托查詢

結果和委托狀態(tài)消息推送中補充委托引用字段。

中臺在向交易系統(tǒng)轉發(fā)委托請求前，在內存

維護委托引用和委托的關系，并通過 Kafka 消息

中間件存儲和共享全量映射關系。在查詢委托消

息或收到交易系統(tǒng)委托狀態(tài)消息推送時，中臺根

據映射關系填充委托引用字段。由于部分映射關

系是通過 Kafka 共享，極端情況可能發(fā)生存在先

22

交易技術前沿

收到委托狀態(tài)消息而后獲取映射關系的情況，為

保障推送客戶消息的順序性以及委托引用原值返

回，中臺采用更新委托引用和回填委托引用兩部

分。在更新委托引用階段，如果未獲取委托引用，

則等待若干毫秒后重試，直至超過允許處理的時

間，在該階段該委托所屬客戶的其他消息也均暫

時阻塞，以保證消息的順序性?；靥铍A段是指在

允許處理的時間內，未更新委托引用的消息，被

會記錄并定時檢查根據獲取的映射關系進行回填。

4.7 算法交易

中臺提供算法交易接口支持機構交易終端算

法交易，機構交易終端系統(tǒng)登錄中臺后其算法單的

母單子單處理流程如圖，機構交易終端系統(tǒng)通過子

單的委托引用與母單委托編號一致匹配母單字單。

5、總結與展望

目前機構交易接入中臺已投入生產使用，已

支持一套 PC 交易終端直接從互聯網訪問和一套

PB 交易終端 , 日均交易量約數千萬。中臺在測試

環(huán)境已支持 3 套交易系統(tǒng)的滬深 A 股普通交易、

滬深 A 股兩融交易、港股通、ETF 申贖、期權業(yè)

務接入，并完成多家 PB 交易終端接入的聯調測

試工作，隨著聯調測試繼續(xù)推進，機構交易接入

中臺將進一步完善。預計在東方證券完成新一代

核心業(yè)務系統(tǒng)切換時，機構交易終端系統(tǒng)均通過

中臺接入交易系統(tǒng)，日均交易量約為數十億。

由于快速交易系統(tǒng)通過基于內存交易技術，大量查詢請求可能影響快速交易系統(tǒng)交易性能。中臺基

于緩存的消息隊列，提供委托查詢和成交查詢，避免委托查詢和成交查詢請求透傳至快速交易系統(tǒng)。

對于成交查詢，成交回報消息即為成交明細消息。API 網關維護客戶、消息定位串到成交回報消息

的映射關系，其中消息定位串以跳表的數據結構組織，支持基于消息定位串入參的增量查詢。

對于委托查詢，每筆委托的最新委托狀態(tài)消息即為該筆委托的查詢結果。API 網關維護客戶、消息

定位串到委托狀態(tài)消息的映射關系，并在委托的最新消息到達時，更新映射關系。

基于緩存消息提供的查詢接口，在查詢性能和并發(fā)支持方面有數量級提升。

表 2 單筆查詢平均耗時比較

記錄條數

查詢方式 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

機構交易終端收到委托狀態(tài)消息時，通常使用委托狀態(tài)消息的委托引用關聯原委托。由于部分交易

系統(tǒng)對委托引用取值規(guī)則進行限定或者定義類型不一致，不能返回機構交易終端委托的委托引用。中臺將

委托引用定義為長整型字段，對于支持長整型委托引用的交易系統(tǒng)，中臺采取透傳方式；對于不支持長整

型委托引用的交易系統(tǒng)，中臺維護委托引用和委托的關系，并在委托查詢結果和委托狀態(tài)消息推送中補充

委托引用字段。

中臺在向交易系統(tǒng)轉發(fā)委托請求前，在內存維護委托引用和委托的關系，并通過 Kafka 消息中間件

存儲和共享全量映射關系。在查詢委托消息或收到交易系統(tǒng)委托狀態(tài)消息推送時，中臺根據映射關系填充

委托引用字段。由于部分映射關系是通過 Kafka 共享，極端情況可能發(fā)生存在先收到委托狀態(tài)消息而后獲

表 2 ：單筆查詢平均耗時比較

23

取映射關系的情況，為保障推送客戶消息的順序性以及委托引用原值返回，中臺采用更新委托引用和回填

委托引用兩部分。在更新委托引用階段，如果未獲取委托引用，則等待若干毫秒后重試，直至超過允許處

理的時間，在該階段該委托所屬客戶的其他消息也均暫時阻塞，以保證消息的順序性?；靥铍A段是指在允

許處理的時間內，未更新委托引用的消息，被會記錄并定時檢查根據獲取的映射關系進行回填。

4.7 ij#$

中臺提供算法交易接口支持機構交易終端算法交易，機構交易終端系統(tǒng)登錄中臺后其算法單的母單

子單處理流程如圖，機構交易終端系統(tǒng)通過子單的委托引用與母單委托編號一致匹配母單字單。

圖 3 算法交易處理流程

k/ >l@mn目前機構交易接入中臺已投入生產使用，已支持一套 PC 交易終端直接從互聯網訪問和一套 PB 交易

終端,日均交易量約數千萬。中臺在測試環(huán)境已支持 3 套交易系統(tǒng)的滬深 A 股普通交易、滬深 A 股兩融交

易、港股通、ETF 申贖、期權業(yè)務接入，并完成多家 PB 交易終端接入的聯調測試工作，隨著聯調測試繼續(xù)

推進，機構交易接入中臺將進一步完善。預計在東方證券完成新一代核心業(yè)務系統(tǒng)切換時，機構交易終端

系統(tǒng)均通過中臺接入交易系統(tǒng)，日均交易量約為數十億。

opqr-

[1] 微服務框架 gRPC 交易接入網關實踐 https://mp.weixin.qq.com/s/-PK26QNJy2t9p4TCTf2dEw

[2] 東方證券服務治理建設實踐 https://mp.weixin.qq.com/s/igX11UL_cbLh-UrpjK-BQg

[3] 新一代證券交易系統(tǒng)應用架構的研究 https://mp.weixin.qq.com/s/SAvXEkaF0ck7XXApGYgk2A

企業(yè)級證券業(yè)務中臺探索與實踐圖 3 ：算法交易處理流程

參考文獻 ：

[1] 微服務框架 gRPC 交易接入網關實踐 https://mp.weixin.qq.com/s/-PK26QNJy2t9p4TCTf2dEw

[2] 東方證券服務治理建設實踐 https://mp.weixin.qq.com/s/igX11UL_cbLh-UrpjK-BQg

[3] 新一代證券交易系統(tǒng)應用架構的研究 https://mp.weixin.qq.com/s/SAvXEkaF0ck7XXApGYgk2A

[4] 企業(yè)級證券業(yè)務中臺探索與實踐 https://mp.weixin.qq.com/s/1RL6iSHU7t8R-COk1i7kJQ

本期熱點

24

隨著上交所批處理系統(tǒng)承接的業(yè)務越來越多，為了應對業(yè)務響應及時性、數據維護

質量和系統(tǒng)運行效率等方面的挑戰(zhàn)，上交所技術在借鑒主流數據處理框架優(yōu)秀設計的基礎

上，結合自身系統(tǒng)特性，以提高代碼復用度為目標，開發(fā)了一套輕量級的 C++ 數據處理

框架，并且結合元數據管理，在提高數據維護質量的同時降低了數據血緣關系維護難度。

本文從批處理系統(tǒng)面臨的實際挑戰(zhàn)出發(fā)，通過分析 Spark 等系統(tǒng)的優(yōu)勢以及自身需求，

設計和開發(fā)了批處理系統(tǒng)的數據處理框架和元數據管理模式。目前，新開發(fā)模式已投入在

創(chuàng)新業(yè)務及交易系統(tǒng)升級建設的研發(fā)工作中。

可復用數據處理框架

在證券數據處理中的探索和實踐

蔡文博、張舒、鮑倩倩、杜小靜、胡紅星 / 上交所技術有限責任公司 技術開發(fā)總部 上海 200120

E-mail ：wbcai@sse.com.cn

1、背景和挑戰(zhàn)

上交所批處理系統(tǒng)作為核心交易系統(tǒng)數據加

工及處理的重要模塊，主要承擔著交易后清結算

處理和基礎數據維護兩大功能。隨著創(chuàng)新業(yè)務不

斷發(fā)展及交易系統(tǒng)技術持續(xù)升級，對批處理系統(tǒng)

在業(yè)務響應及時性、數據維護質量、系統(tǒng)運行高

效等方面提出了更高的要求?，F有的批處理系統(tǒng)

已表現出諸多不足，主要問題有 ：一是研發(fā)效率

不高，雖然使用了相對高效易用的基礎庫，但業(yè)

務應用抽象程度低，代碼復用程度低，進而導致

創(chuàng)新業(yè)務需求響應能力差 ；二是缺乏統(tǒng)一的數據

標準，目前各接口獨立定義字段，導致定義工作

重復、同一字段在不同接口命名不一致，增加系

統(tǒng)維護成本，降低數據整體質量 ；三是數據血緣

關系維護難度大，隨著批處理系統(tǒng)承載的業(yè)務越

交易技術前沿

25

來越多，數據處理流程越來越復雜，準確全面維

護血緣關系的難度也越來越大。

近年來，上交所持續(xù)推進數字化轉型，積極

助力科技賦能，批處理系統(tǒng)技術服務能力和數據

管理水平亟待升級。為解決以上問題，批處理系

統(tǒng)啟動研發(fā)輕量級數據處理框架，既易于與現有

技術體系融合，又便于數據血緣關系的提取。首

先考察主流的數據處理框架，如 Spark，Flink 等，

在借鑒其關于數據算子抽象的基礎上，設計開發(fā)

C++ 語言的數據處理框架。通過對業(yè)務邏輯的抽

象與封裝，形成可復用的功能組件，沉淀技術共

享能力，進一步提高研發(fā)效率。此外，結合數據

標準及元數據管理，設計了包含數據元、字段、

模型、物理表 / 文件等四層結構的維護模式，確

保字段在所有模型中均有一致的定義，有助于提

高數據質量。

2、數據處理框架

2.1 整體架構

上交所批處理系統(tǒng)的數據處理框架整體可分

為組件層和存儲抽象層。組件層包含基礎組件層

和功能組件層，其中基礎組件提供原始的數據處

理語義，如過濾、聯合、映射、分組等 ；功能組

件是對基礎組件的組合，實現一個完整的數據轉

換功能，如表 A 數據關聯更新表 B 數據、表數

據格式轉換后導入文件等。存儲抽象層則定義了

統(tǒng)一的數據訪問接口，如讀取、寫入、查找、更

新等，使組件層可以無差別的處理文件、數據庫

表、共享內存庫、Map 等多種存儲形式中的數據。

應用層的業(yè)務邏輯通常使用預定義的功能組

件實現，特殊情況下可直接組合基礎組件實現。

存儲抽象層屏蔽了存儲介質的差異，使框架易于

加強代碼可復用能力，降低開發(fā)及測試成本?？蚣艿恼w層次如圖 2.1 所示。

圖 2.1 數據處理框架整體架構圖

2.2 ;<=>?

存儲抽象層為不同存儲介質（如文件、數據表、Map 容器等）中的數據提供統(tǒng)一的訪問接口。對數據

圖 2.1 ：數據處理框架整體架構圖

本期熱點

26

融入現有的技術體系 ；組件層則主要體現了業(yè)務

邏輯的抽象與復用，加強代碼可復用能力，降低

開發(fā)及測試成本?？蚣艿恼w層次如圖 2.1 所示。

2.2 存儲抽象層

存儲抽象層為不同存儲介質（如文件、數據

表、Map 容器等）中的數據提供統(tǒng)一的訪問接口。

對數據處理框架而言，一方面屏蔽了存儲介質特

性，使組件層可以無差別地處理各種存儲形式的

數據 ；另一方面應用層無需關心存儲特性，提高

了應用批業(yè)務表達的清晰度。

技術實現上，不同的存儲類均實現 Storage

接口，類層級關系如圖 2.2 所示。根據存儲介質

的特性，并非所有接口都要實現，比如文件存儲

類（CBatFileStorage）無需實現查找和更新接口。

2.3 組件層

2.3.1 基礎組件

基礎組件是對常見批量數據處理動作的提

煉，描述了一次數據集的轉換?；A組件類似

Spark 和數據庫中的算子（Operator）概念。

主要基礎組件及其功能如下表 2.1 所示。

圖 2.1 數據處理框架整體架構圖

2.2 ;<=>?

存儲抽象層為不同存儲介質（如文件、數據表、Map 容器等）中的數據提供統(tǒng)一的訪問接口。對數據

處理框架而言，一方面屏蔽了存儲介質特性，使組件層可以無差別地處理各種存儲形式的數據；另一方面

應用層無需關心存儲特性，提高了應用批業(yè)務表達的清晰度。

技術實現上，不同的存儲類均實現 Storage 接口，類層級關系如圖 2.2 所示。根據存儲介質的特性，并

非所有接口都要實現，比如文件存儲類（CBatFileStorage）無需實現查找和更新接口。

圖 2.2 ： 類層級關系

圖 2.2 類層級關系

2.3 @A?

2.3.1基礎組件

基礎組件是對常見批量數據處理動作的提煉，描述了一次數據集的轉換?；A組件類似 Spark 和數據

庫中的算子（Operator）概念。

主要基礎組件及其功能如下表 2.1 所示。

表 2.1 基礎組件及其功能

基礎組件 功能簡介

Aggregate 支持數據聚合操作

DataSource 用于指定源數據集

CreateView 創(chuàng)建數據庫視圖

Expand 支持數據擴展操作

Filter 根據某一條件過濾數據集

Groupby 將數據集按某一條件分組，并執(zhí)行后續(xù)操作

Import 支持批量導入數據

Insert 支持數據插入

Join 支持數據集聯合

Orderby 支持數據集排序

Update 用于數據更新

Upsert 存在即更新，不存在即插入

Validate 支持數據校驗

基礎組件具備以下三個特征：

·可組合性。基礎組件輸入輸出接口的一致性保證了其可組合性，基礎組件的可組合性是實現復雜數

據處理邏輯的基礎。

·可復用性。單個基礎組件是對一類數據操作的抽象和提煉，實際使用時根據具體場景對其實例化。

表 2.1 ：基礎組件及其功能

交易技術前沿

27

基礎組件具備以下三個特征 ：

? 可組合性。基礎組件輸入輸出接口的一致

性保證了其可組合性，基礎組件的可組合性是實

現復雜數據處理邏輯的基礎。

? 可復用性。單個基礎組件是對一類數據操

作的抽象和提煉，實際使用時根據具體場景對其

實例化。

? 可擴展性。新的數據處理模式可以通過開

發(fā)新的基礎組件來支持，且由于組件的可組合性，

新組件可獲得更廣的應用范圍。

2.3.2 功能組件

功能組件以具體的數據轉換模式為基礎，統(tǒng)

一代碼模式，內化實現細節(jié)，僅表達數據轉換關

鍵信息，清晰地表達數據的變更方向和變更方式，

使代碼的業(yè)務表達能力更精練。組件的標準化和

可復用性有效提高了代碼的利用率，減少了應用

代碼的冗余度，對提高開發(fā)效率具有積極意義。

功能組件一般描述了數據從一個載體到另一

個載體的轉換過程。組件并不關心載體具體是什

么，重點是轉換過程。比如同一個組件既可以處

理文件數據經過過濾后導入 Map 的過程，又可以

處理表數據經過過濾后導入文件的過程。如前所

述，功能組件都是由一系列基礎組件組合而成。

圖 2.3 展例了兩個功能組件實現。

? 功能組件 1 ：適用于需要過濾源頭數據集

圖 2.3 功能組件示例

·功能組件 1：適用于需要過濾源頭數據集的場景。如篩選出輸入產品全量數據中的所有股票產品并

插入數據庫表。

·功能組件 2：適用于目標數據集為源數據集和中間數據集聯合的場景。如在展開賬戶對所有產品子

類型的權限并插入到進程 map 的需求中，使用 cross join 操作。

根據實際業(yè)務場景，選擇合適的功能組件是實現應用業(yè)務處理的關鍵點。當功能組件不滿足業(yè)務場景

時，可通過組合基礎組件開發(fā)新的功能組件。以具體業(yè)務場景為示例，圖 2.4 展示了具體的業(yè)務場景衍生

出的功能組件和基礎組件的關系。

圖 2.4 業(yè)務場景與組件關系

功能組件根據執(zhí)行模式可分為兩種。一種是在內存中迭代執(zhí)行，另一種是轉換成 SQL 后在數據庫內執(zhí)

行。下面分別介紹兩種執(zhí)行模式的執(zhí)行步驟。

迭代執(zhí)行模式圖 2.3 功能組件示例

·功能組件 1：適用于需要過濾源頭數據集的場景。如篩選出輸入產品全量數據中的所有股票產品并

插入數據庫表。

·功能組件 2：適用于目標數據集為源數據集和中間數據集聯合的場景。如在展開賬戶對所有產品子

類型的權限并插入到進程 map 的需求中，使用 cross join 操作。

根據實際業(yè)務場景，選擇合適的功能組件是實現應用業(yè)務處理的關鍵點。當功能組件不滿足業(yè)務場景

時，可通過組合基礎組件開發(fā)新的功能組件。以具體業(yè)務場景為示例，圖 2.4 展示了具體的業(yè)務場景衍生

出的功能組件和基礎組件的關系。

圖 2.3 ：功能組件示例

圖 2.4 ：業(yè)務場景與組件關系

本期熱點

28

的場景。如篩選出輸入產品全量數據中的所有股

票產品并插入數據庫表。

? 功能組件 2 ：適用于目標數據集為源數據

集和中間數據集聯合的場景。如在展開賬戶對所

有產品子類型的權限并插入到進程 map 的需求

中，使用 cross join 操作。

根據實際業(yè)務場景，選擇合適的功能組件是

實現應用業(yè)務處理的關鍵點。當功能組件不滿足

業(yè)務場景時，可通過組合基礎組件開發(fā)新的功能

組件。以具體業(yè)務場景為示例，圖 2.4 展示了具體

的業(yè)務場景衍生出的功能組件和基礎組件的關系。

功能組件根據執(zhí)行模式可分為兩種。一種是

在內存中迭代執(zhí)行，另一種是轉換成 SQL 后在數

據庫內執(zhí)行。下面分別介紹兩種執(zhí)行模式的執(zhí)行

步驟。

一、迭代執(zhí)行模式

下面以圖 2.3 中的功能組件 2 為例展示迭代

執(zhí)行的機制。

圖 2.5 迭代執(zhí)行模式

引用關系，箭頭表示下游節(jié)點對上游節(jié)點的引用；藍線是函數調用執(zhí)行的順序

載IterateExecute 函數（如圖 2.3），且都由 save() 接口觸發(fā)。執(zhí)行規(guī)則是下游節(jié)

數據（query），直到最上游的算子節(jié)點直接從源數據集中取到數據，然后數據經

turn）最下游的算子節(jié)點。為避免對內存過多的占用，數據以分批的形式在各節(jié)圖 2.5 ：迭代執(zhí)行模式

紅線表示節(jié)點引用關系，箭頭表示下游節(jié)點

對上游節(jié)點的引用 ；藍線是函數調用執(zhí)行的順序

迭代執(zhí)行的組件都重載 IterateExecute 函數

（如圖 2.3），且都由 save() 接口觸發(fā)。執(zhí)行規(guī)則

是下游節(jié)點遞歸的向上游節(jié)點請求數據（query），

直到最上游的算子節(jié)點直接從源數據集中取到數

據，然后數據經過各級節(jié)點處理后返回（return）

最下游的算子節(jié)點。為避免對內存過多的占用，

數據以分批的形式在各節(jié)點間傳遞。同時，為避

免數據在各節(jié)點間過多拷貝，節(jié)點間傳遞的是數

據指針，且多數節(jié)點不緩存數據。例外的是映射

節(jié)點（project），因為涉及到數據結構的變動，映

射節(jié)點將緩存新結構的數據，并向下游傳遞新數

據的指針。

二、數據庫執(zhí)行模式

與迭代執(zhí)行不同，數據庫執(zhí)行的組件都重載

DbExecute，且都由 doDbExecute 觸發(fā)，如組件 3

所示（圖 2.6）。

圖 2.7 展示數據庫執(zhí)行的機制。

數據庫執(zhí)行組件先將數據處理流程編譯成

SQL 語句，然后在數據庫中執(zhí)行對應 SQL。SQL

的編譯過程借鑒 SQLAchemy 項目的思路，主

要應用了 Visitor 設計模式。每個算子節(jié)點可接

收一個 Visitor 對象，并把其參數傳給 Visitor 對

象。在上圖的例子中，Insert 算子通過 visit_insert

接口把目的表信息傳遞給 SqlVisitor ；Project 算

子把字段映射關系通過 visit_project 接口傳遞給

SqlVisitor ；Join 算子把關聯的左表和右表以及關

聯條件傳遞給 SqlVisitor。通過遍歷整個數據流中

的節(jié)點，SqlVisitor 收集到所有的表操作要素并放

在其內部的 SqlBuilder 中，最后由 SqlBuilder 將

表操作要素編譯成 SQL 語句。

2.4 應用示例

對于實際的盤后批處理應用，可將一個批

（Job）的業(yè)務功能拆分成多個步驟的數據集轉換

（Stage），每個 Stage 由單個功能組件實現，完成

一次數據集的轉換。多個 Stage 順序執(zhí)行最終完

成目的數據集的生成。

Step1 ：為 DatasetContext 對 象 提 供 上 下 文

參數，構造初始數據集對象（Dataset）。構造

Dataset 時需指定其存儲類型、存儲資源 ID、數

據結構（C-Struct）等信息。這些數據集既包含

交易技術前沿

29

二、數據庫執(zhí)行模式

與迭代執(zhí)行不同，數據庫執(zhí)行的組件都重載 DbExecute，且都由 doDbExecute 觸發(fā)，如組件 3 所示（圖

2.6）。

圖 2.6 數據庫功能組件

下圖 2.7 展示數據庫執(zhí)行的機制。

例外的是映射節(jié)點（project），因為涉及到數據結構的變動，映射節(jié)點將緩存新結構的數據，并向下游傳遞

新數據的指針。

二、數據庫執(zhí)行模式

與迭代執(zhí)行不同，數據庫執(zhí)行的組件都重載 DbExecute，且都由 doDbExecute 觸發(fā)，如組件 3 所示（圖

2.6）。

圖 2.6 數據庫功能組件

下圖 2.7 展示數據庫執(zhí)行的機制。

圖 2.6 ：數據庫功能組件

圖 2.7 ：數據庫執(zhí)行模式

紅線表示節(jié)點引用關系，箭頭表示下游節(jié)點對上游節(jié)點的引用；藍線是函數調用

執(zhí)行的順序

圖 2.7 數據庫執(zhí)行模式

紅線表示節(jié)點引用關系，箭頭表示下游節(jié)點對上游節(jié)點的引用；藍線是函數調用執(zhí)行的順序

數據庫執(zhí)行組件先將數據處理流程編譯成 SQL 語句，然后在數據庫中執(zhí)行對應 SQL。SQL 的編譯過

程借鑒 SQLAchemy 項目的思路，主要應用了 Visitor 設計模式。每個算子節(jié)點可接收一個 Visitor 對象，并

把其參數傳給 Visitor 對象。在上圖的例子中，Insert 算子通過 visit_insert 接口把目的表信息傳遞給 SqlVisitor；

Project 算子把字段映射關系通過 visit_project 接口傳遞給 SqlVisitor；Join 算子把關聯的左表和右表以及關

聯條件傳遞給 SqlVisitor。通過遍歷整個數據流中的節(jié)點，SqlVisitor 收集到所有的表操作要素并放在其內部

的 SqlBuilder 中，最后由 SqlBuilder 將表操作要素編譯成 SQL 語句。

2.4 B#CD

對于實際的盤后批處理應用，可將一個批（Job）的業(yè)務功能拆分成多個步驟的數據集轉換（Stage），

每個 Stage 由單個功能組件實現，完成一次數據集的轉換。多個 Stage 順序執(zhí)行最終完成目的數據集的生成。

圖 2.8 應用示例解析

Step1：為 DatasetContext 對象提供上下文參數，構造初始數據集對象（Dataset）。構造 Dataset 時需指

定其存儲類型、存儲資源 ID、數據結構（C-Struct）等信息。這些數據集既包含輸入數據集也包含輸出數

據集圖 2.8 ：應用示例解析

本期熱點

30

輸入數據集也包含輸出數據集。

Step2 ：按順序執(zhí)行每個 Stage 的功能組件。

每個功能組件完成一個目標數據集數據的生成。

前面 Stage 的目標數據集可作為后續(xù) Stage 的源數

據集。數據集的讀寫均通過Storage接口統(tǒng)一完成。

2.5 代碼生成

由于批任務代碼基于預定義的組件，且代碼

結構有較強的規(guī)律性，我們在此基礎上設計了一

套 Yaml 配置規(guī)則，并開發(fā)了配套的代碼生成程

序，支持將 Yaml 配置翻譯成批任務代碼。其收

益包括 ：一方面進一步提高了業(yè)務開發(fā)人員的編

碼效率 ；另一方面在于將業(yè)務邏輯結構化處理，

支持后續(xù)對業(yè)務邏輯的進一步解析與應用，生成

數據的血緣關系。如圖 2.9 所示，左邊為 Yaml

配置，右邊為生成的批任務代碼。

3、元數據管理

3.1 數據模型構建

批處理系統(tǒng)承載交易系統(tǒng)文件聚合、轉發(fā)等

業(yè)務功能，具有數據量大、數據結構復雜等特點。

批處理系統(tǒng)強化數據標準體系建設工作，在業(yè)務

層面，有助于明確業(yè)務含義，明確業(yè)務與業(yè)務間、

業(yè)務與技術間統(tǒng)一口徑與認識 ；在技術層面，有

助于構建規(guī)范的物理數據模型，提供對數據元的

格式規(guī)范，進而提高數據質量水平 ；此外，有助

于配合與對接所級別數據標準的建設。

目前，批處理中心使用數據元定義、字段定

義、模型定義、文件 / 數據表定義的遞進引用結

構（如圖 3.1），對系統(tǒng)所使用的元數據進行管理

與維護。

圖 2.9 業(yè)務配置與代碼生成

3 I$%J'

3.1 $%KL:M

批處理系統(tǒng)承載交易系統(tǒng)文件聚合、轉發(fā)等業(yè)務功能，具有數據量大、數據結構復雜等特點。批系統(tǒng)強化數據標準體系建設工作，在業(yè)務層面，有助于明確業(yè)務含義，明確業(yè)務與業(yè)務間、業(yè)務與技統(tǒng)一口徑與認識；在技術層面，有助于構建規(guī)范的物理數據模型，提供對數據元的格式規(guī)范，進而提據質量水平；此外，有助于配合與對接所級別數據標準的建設。

目前，批處理中心使用數據元定義、字段定義、模型定義、文件/數據表定義的遞進引用結構（如圖 對系統(tǒng)所使用的元數據進行管理與維護。

圖 3.1 遞進引用結構

其中，數據元是數據標準定義的基本單位。以標準數據類型為基準，建立數據標準體系。數據元主題大類、主題子類劃分類別（詳見表 3.1）。

字段在數據元基礎上進行定義，同一個數據元可擁有多個字段，多個字段可指向同一數據元。同圖 3.1 ：遞進引用結構

圖 2.9 業(yè)務配置與代碼生成

3 I$%J'

圖 2.9 ：業(yè)務配置與代碼生成

交易技術前沿

31

其中，數據元是數據標準定義的基本單位。

以標準數據類型為基準，建立數據標準體系。數

據元按照主題大類、主題子類劃分類別（詳見表

3.1）。

字段在數據元基礎上進行定義，同一個數據

元可擁有多個字段，多個字段可指向同一數據元。

同一數據元僅有一個標準格式字段 ；可擁有多個

擴展格式字段 ；其中，在模型設計規(guī)范中定義 ：

批處理系統(tǒng)內部維護的字段均為標準格式字段。

若輸入接口中的字段非標準格式，其進入系統(tǒng)內

部模型前需轉換為標準格式 ；若輸出接口中的字

段為非標準格式，需將內部模型中的標準格式字

段轉換為輸出接口要求的格式。

模型是由字段組合形成的邏輯概念 ；文件、

數據表在邏輯模型的基礎上定義，增加落地的物

理屬性。同一個模型可被定義為多個文件 / 數據

表實體。

3.2 配置自動生成

數據元配置可自動化生成文件 / 數據表等

模型的接口文件。目前支持生成文件結構接口、

數據表結構接口、SQL 建表語句等。既減輕了

開發(fā)人員的工作量，另一方面保證了元數據與

代碼結構的同源性，提升研發(fā)效率的同時有效

提高數據維護質量。配置自動生成說明如表 3.2

所示。

在后續(xù)工作中，批處理系統(tǒng)將持續(xù)加強對元

數據組織方式、標準及規(guī)范定義、評審流程等工

作的完善，形成高效可控的管理機制。

4、血緣關系提取

上交所批處理系統(tǒng)涉及的證券數據，主要有

以下特征 ：一、業(yè)務繁多，幾乎所有業(yè)務均包含

盤后處理；二、相關方多，上下游交互系統(tǒng)較多，

主要包含外部對等機構、所內業(yè)務系統(tǒng)、市場這

三大類 ；三、業(yè)務規(guī)則變更、所內外接口變更較

頻繁，影響評估工作量大 ；四、盤后批處理應急

場景多，亟需高效的影響評估手段。

基于以上交易系統(tǒng)盤后批處理數據及業(yè)務特

征，通過維護數據血緣關系，可有效提高數據變

更影響評估的效率和準確度 ；生產應急情況下，

應急時間窗口緊張，短時間內人工評估數據影響

容易錯漏，提供自動化手段可提高運維效率 ；方

據元僅有一個標準格式字段；可擁有多個擴展格式字段；其中，在模型設計規(guī)范中定義：批處理系統(tǒng)內部

維護的字段均為標準格式字段。若輸入接口中的字段非標準格式，其進入系統(tǒng)內部模型前需轉換為標準格

式；若輸出接口中的字段為非標準格式，需將內部模型中的標準格式字段轉換為輸出接口要求的格式。

模型是由字段組合形成的邏輯概念；文件、數據表在邏輯模型的基礎上定義，增加落地的物理屬性。

同一個模型可被定義為多個文件/數據表實體。

表 3.1 數據模型分級試圖

邏輯主題 主題大類 主題子類

市場參與者

賬戶信息

賬戶基礎信息

賬戶指定關系

賬戶權限

持有 賬戶持倉

機構

機構信息 機構基礎信息

PBU 信息

PBU 基礎信息

PBU 產品業(yè)務權限

產品

產品信息 基礎信息

產品業(yè)務信息

產品業(yè)務交易參數

產品業(yè)務平臺對應關系

業(yè)務 業(yè)務信息

業(yè)務基礎信息

業(yè)務時間表

市場 市場信息

交易日歷

全局交易時間表

3.2 NOPQGH

數據元配置可自動化生成文件/數據表等模型的接口文件目前支持生成文件結構接口數據表結構接表 3.1 ：數據模型分級試圖

本期熱點

32

便業(yè)務理解，提高需求分析、運維工作效率和工

作質量。

4.1 提取方式

常見的數據血緣關系提取主要以解析 SQL

為主。通過遍歷 SQL 的抽象語法樹（AST）分析

數據血緣關系。但是批處理系統(tǒng)除了有基于數據

庫的數據處理，還有基于文件和內存的處理過程，

這些處理過程無法用 SQL 體現。因此通過解析體

現業(yè)務邏輯的 Yaml 配置可以獲得更為完整的數

據血緣關系。

與代碼生成邏輯類似，通過解析每個數據

處理流程的 From、Join、Insert、Update 等節(jié)點

的數據集信息可以獲取文件和表級別的血緣關

系（粗粒度）。進一步解析 Insert 和 Update 等節(jié)

點的字段賦值關系可以收集字段級別的血緣關

系（細粒度）。

一、文件 / 表級別

任務包含多個輸入和輸出，通過建立文件 /

數據表的血緣關系，便于分析數據流向，了解數

據的重要程度，為相關業(yè)務決策提供參考基礎。

特別對于上下游系統(tǒng)交互較多的多任務處理系

統(tǒng)，當生產環(huán)境上游文件未及時到達，能迅速進

行影響分析，為應急處置提供幫助。目前我們已

經完成粗粒度血緣關系提取工具的開發(fā)，并將血

緣關系導入到了 Apache Atlas 平臺。下圖 4.1 展

示了港股通限制產品導出功能的文件、表與批任

務的血緣關系。

二、字段級別

交易系統(tǒng)基于數據處理，海量交易數據分散

在多個系統(tǒng)，實際場景中經常會遇到分析字段變

更的影響范圍、字段來源于哪里等問題。因此，

分析字段間的血緣關系變得尤為重要。通過分析

批業(yè)務配置中文件或表字段賦值的關系，可以生

成細粒度 column 級別的字段流向樹。圖 4.2 為

mem_code（會員代碼）字段的血緣圖譜分析結果。

后續(xù)將開發(fā)字段級別血緣關系的自動化的提取工

具，完善細粒度血緣關系的展示。

血緣關系的維護對后續(xù)構建交易系統(tǒng)業(yè)務畫

像、優(yōu)化系統(tǒng)業(yè)務架構和性能、分析數據變更對

系統(tǒng)造成的影響評估等方面起到更大應用。

5、總結與展望

在借鑒主流數據處理框架優(yōu)秀設計的基礎

上，結合上交所批處理系統(tǒng)特性自研了一套數據

處理框架。一方面可以與批處理系統(tǒng)現有的技術

更好的融合 ；另一方面無需獨立的運行時環(huán)境，

避免額外的運維負擔 ；數據處理框架同時支持內

存迭代執(zhí)行和數據庫 SQL 執(zhí)行兩種模式，統(tǒng)一了

數據庫外和數據庫內兩種數據處理模式的表達方

式。最后，元數據管理不但統(tǒng)一了字段的業(yè)務含

表 3.2 ：配置自動生成說明

3.2 NOPQGH

數據元配置可自動化生成文件/數據表等模型的接口文件。目前支持生成文件結構接口、數據表結構接

口、SQL 建表語句等。既減輕了開發(fā)人員的工作量，另一方面保證了元數據與代碼結構的同源性，提升研

發(fā)效率的同時有效提高數據維護質量。配置自動生成說明如表 3.2 所示。

在后續(xù)工作中，批處理系統(tǒng)將持續(xù)加強對元數據組織方式、標準及規(guī)范定義、評審流程等工作的完善，

形成高效可控的管理機制。

表 3.2 配置自動生成說明

使用場景 生成物名稱 生成物用途

數據庫表注冊信息

table_info_list.cpp 數據表與結構體對應關系

refdata_table_list.cpp 數據表分類情況

table_id_enum.hpp 數據表 ID 注冊

table_flag_index.h 數據表 flag 文件注冊

數據庫表、視圖接口 db_interface_<tablename>.hpp 數據庫表結構&建表語句定義

<tablename>.h 數據庫表就緒通知文件

文件接口 ifm_<filename>.h 文件結構定義

from/to_<filename>.h 文件路徑等屬性定義

模型文檔

tables.xls 數據表接口文檔

files.xls 文件接口文檔

4 RSTUVW

上交所批處理系統(tǒng)涉及的證券數據，主要有以下特征：一、業(yè)務繁多，幾乎所有業(yè)務均包含盤后處理；

交易技術前沿

33

義和技術定義，也使接口代碼可自動化生成，提

高了開發(fā)效率和準確度。

目前批處理系統(tǒng)已經使用新的開發(fā)模式投入

創(chuàng)新業(yè)務及交易系統(tǒng)升級建設的研發(fā)工作中，基

本實現代碼復用、自動化的血緣關系提取以及提

高數據維護質量的目標。將在后續(xù)業(yè)務支持過程

中持續(xù)完善數據處理功能，并探索把數據處理框

架的應用范圍擴展到其他處理場景。

集字段級別的血緣關系（細粒度）。

一、文件/表級別

任務包含多個輸入和輸出，通過建立文件/數據表的血緣關系，便于分析數據流向，了解數據的重要程

度，為相關業(yè)務決策提供參考基礎。特別對于上下游系統(tǒng)交互較多的多任務處理系統(tǒng)，當生產環(huán)境上游文

件未及時到達，能迅速進行影響分析，為應急處置提供幫助。目前我們已經完成粗粒度血緣關系提取工具

的開發(fā)，并將血緣關系導入到了 Apache Atlas 平臺。下圖 4.1 展示了港股通限制產品導出功能的文件、表與

批任務的血緣關系。

圖 4.1 文件級別血緣關系提取

二、字段級別

圖 4.1 ：文件級別血緣關系提取

交易系統(tǒng)基于數據處理，海量交易數據分散在多個系統(tǒng)，實際場景中經常會遇到分析字段變更的影響

范圍、字段來源于哪里等問題。因此，分析字段間的血緣關系變得尤為重要。通過分析批業(yè)務配置中文件

或表字段賦值的關系，可以生成細粒度 column 級別的字段流向樹。圖 4.2 為 mem_code（會員代碼）字段

的血緣圖譜分析結果。后續(xù)將開發(fā)字段級別血緣關系的自動化的提取工具，完善細粒度血緣關系的展示。

圖 4.2 字段級別血緣關系提取

血緣關系的維護對后續(xù)構建交易系統(tǒng)業(yè)務畫像、優(yōu)化系統(tǒng)業(yè)務架構和性能、分析數據變更對系統(tǒng)造成

的影響評估等方面起到更大應用。

5 Z[\\]^

在借鑒主流數據處理框架優(yōu)秀設計的基礎上，結合上交所批處理系統(tǒng)特性自研了一套數據處理框架。

一方面可以與批處理系統(tǒng)現有的技術更好的融合；另一方面無需獨立的運行時環(huán)境，避免額外的運維負擔；

數據處理框架同時支持內存迭代執(zhí)行和數據庫 SQL 執(zhí)行兩種模式，統(tǒng)一了數據庫外和數據庫內兩種數據處

理模式的表達方式。最后，元數據管理不但統(tǒng)一了字段的業(yè)務含義和技術定義，也使接口代碼可自動化生

成，提高了開發(fā)效率和準確度。

前批系統(tǒng)經使新的發(fā)模式投創(chuàng)新務交易系統(tǒng)升級建的發(fā)作中基本實代圖 4.2 ：字段級別血緣關系提取

本期熱點

34

目前，滬深市場上的普通期權產品以及國泰君安的場外期權產品的定價方式均是采用

基于蒙特卡羅模擬，通過軟件計算來實現。由于蒙特卡羅模擬往往需要模擬十萬條以上的路

徑，傳統(tǒng)的期權定價方法面臨著處理時間過長，計算效率過低等問題。本文基于此類問題，

提出并通過 oneAPI 實現了一種基于 FPGA 的并行流水線期權價格計算方案，能夠完成對

歐式香草期權與雪球期權的定價。經過對比與測試，相比于 CPU 通過 C++ 軟件實現的方式，

通過 oneAPI 設計，并通過 FPGA 來實現的定價方式在性能上有顯著的提升。

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

馬輝1

、鄒經緯1

、白君潔1

、鐘浪輝2

、韓大偉2

、黃琦3

、余洋洋3

、李彪3 / 1 國泰君安證券股份有限公

司 上海 2 上交所技術有限責任公司 上海 3 英特爾移動通信技術 ( 上海 ) 有限公司 上海

E-mail :baijunjie026611@gtjas.com

引言

期權作為最基礎的金融衍生產品之一，為其定

價一直是金融工程的重要研究領域，主要使用的定

價方法有偏微分方程法、鞅方法和數值方法。而數

值方法又包括了二叉樹方法、有限差分法和蒙特卡

羅模擬方法。蒙特卡羅模擬方法的理論基礎是概率

論和數理統(tǒng)計，其實質是通過模擬標的資產價格路

徑預測期權的平均回報并得到期權價格估計值。

蒙特卡羅方法的最大優(yōu)勢是誤差收斂率不依

賴于問題的維數，從而非常適宜為高維期權定價。

當期權定價模型維數增大時，如多資產的期權模

型，無論是理論還是實際中，不會采用確定性方

法。因此，業(yè)內最普遍采用的方法還是蒙特卡羅

方法，特別是對 Path-Dependent（路徑依賴）的

各類奇異期權以及 Multi-Asset（多資產）期權模

型，蒙特卡羅方法直觀有效。理論上，隨機模擬

方法效率和精度很低，但蒙特卡羅算法的模擬路

徑部分相互獨立，可以并行計算。但是，蒙特卡

羅模擬的缺點就是速率很慢，數值解誤差與隨機

次數開根號分之一同階，也就是說，若數值解要

精確到小數點后面 1 位，需要試驗 100 次 ；要精

確到小數點后面 2 位，則需要試驗 10000 次 ；要

精確到小數點后面 3 位，需要試驗 10 的 6 次方次。

使用 CPU 通過軟件計算的傳統(tǒng)期權定價

會相當耗時，相比，FPGA（Field Programmable

Gate Array，現場可編程門陣列）具有良好的并

行計算特性，使用 FPGA 通過蒙特卡羅模擬進

行期權定價能獲得很好的性能提升。本文使用

Intel 公司的 oneAPI 開發(fā)工具，通過 DPC++(Data

Parallel C++ , 數據并行 C++) 語言設計了各類型

期權定價算法，并完成綜合實現，在 FPGA 加速

交易技術前沿

35

板卡上進行了功能驗證與性能對比。

1、期權定價原理

歐式和美式看漲看跌期權等衍生品被稱為普

通期權（也稱為香草期權），其具有定義良好的

標準屬性與廣大的交易占比。國內市場上常見的

50ETF 期權、滬市 300ETF 期權、深市 300ETF

期權、滬深 300 股指期權均為歐式期權。

場外衍生品屬于非標準產品，場外期權也被

稱為奇異期權，盡管它們通常只占投資組合中相

對較小的一部分，但對于衍生品交易商來說，外

來產品是非常重要的，因此它們通常比普通衍生

品的利潤更高。

國泰君安在普通期權與場外奇異期權的定價

都有深入的研究，本文以歐式香草期權與場外期

權中的雪球期權為例進行分析。

1.1 歐式期權定價

歐式期權可分為看漲和看跌期權，是指在

將來的某個特定的時間（到期日），期權的持有

者有權力以事先約定的匯率（敲定價）向期權

出售者購買 / 出賣約定數量的貨幣，并支付購買

該項權力的權力金。歐式期權風險中性定價通

過 Black-Scholes(BS) 模型實現，其隨機微分方程

（SDE）由下面公式給出 ：

/0

權可分為看漲和看跌期權，是指在將來的某個特定的時間（到期日），期權的持有者有權力以

匯率（敲定價）向期權出售者購買/出賣約定數量的貨幣，并支付購買該項權力的權力金。歐式

性定價通過 Black-Scholes(BS)模型實現，其隨機微分方程（SDE）由下面公式給出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 1

為資產價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行（維

為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權的價格作為最終現貨

收益的貼現期望，到期時間為??：

??,-.?? ?? ?? ?? 2

望是在適當的風險中性度量下得到的，該度量使漂移量??等于無風險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 4

個常系數隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 5

于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0,1)。

(1)

其中，S 為資產價格，μ 為股票的漂移量（瞬

時期望收益率），σ 為股票的波動率，B 為布朗

運行（維納過程）。

可以認為 dB 是一個均值為 0，方差為 dt 的

正態(tài)分布隨機變量，使用歐式香草期權的價格作

為最終現貨價格的期權收益的貼現期望，到期時

間為 T ：

為看漲和看跌期權，是指在將來的某個特定的時間（到期日），期權的持有者有權力以

敲定價）向期權出售者購買/出賣約定數量的貨幣，并支付購買該項權力的權力金。歐式

通過 Black-Scholes(BS)模型實現，其隨機微分方程（SDE）由下面公式給出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 1

產價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行（維

一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權的價格作為最終現貨

貼現期望，到期時間為??：

??,-.?? ?? ?? ?? 2

適當的風險中性度量下得到的，該度量使漂移量??等于無風險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 4

數機微分由式解 (2)

這個期望是在適當的風險中性度量下得到

的，該度量使漂移量μ等于無風險利率r，可得到:

納過程）。

可以認為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權的價格作為最終現價格的期權收益的貼現期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當的風險中性度量下得到的，該度量使漂移量??等于無風險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0,1)將上式使用??(??)的指數形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風險中性定價方法可以得到期權價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權或看跌期權的收益。通過對這些收益的總和取平均值，然后取無風險折現，我們得到了期權的近似價格。

2.2 <=67/0

雪球期權屬于路徑依賴型奇異期權，其結構相對復雜，本質是一種帶障礙的看跌期權，自 2019 年開

始，雪球這種非保本型收益憑證受到市場上越來越多的關注，各類金融機構紛紛以不同角色參與其中。表 1 所示案例為例：

表 1 雪球期權相關要素

雪球期權

掛鉤標的 股票/指數

標的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(3)

通過伊藤引理得到 ：

納過程）。

可以認為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權的價格作為最終價格的期權收益的貼現期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當的風險中性度量下得到的，該度量使漂移量??等于無風險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0將上式使用??(??)的指數形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風險中性定價方法可以得到期權價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權或看跌期權的收益。通過對這些收益的總和取平均值，然后取險折現，我們得到了期權的近似價格。

2.2 <=67/0

雪球期權屬于路徑依賴型奇異期權，其結構相對復雜，本質是一種帶障礙的看跌期權，自 2019 始，雪球這種非保本型收益憑證受到市場上越來越多的關注，各類金融機構紛紛以不同角色參與其中表 1 所示案例為例：

表 1 雪球期權相關要素

雪球期權

掛鉤標的 股票/指數

標的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(4)

這是一個常系數隨機微分方程，可由下式解

出 ：

其中，??為資產價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運納過程）。

可以認為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權的價格作為最價格的期權收益的貼現期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當的風險中性度量下得到的，該度量使漂移量??等于無風險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ??將上式使用??(??)的指數形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風險中性定價方法可以得到期權價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權或看跌期權的收益。通過對這些收益的總和取平均值，然后險折現，我們得到了期權的近似價格。

2.2 <=67/0

雪球期權屬于路徑依賴型奇異期權，其結構相對復雜，本質是一種帶障礙的看跌期權，自 20始，雪球這種非保本型收益憑證受到市場上越來越多的關注，各類金融機構紛紛以不同角色參與其表 1 所示案例為例：

表 1 雪球期權相關要素

雪球期權

掛鉤標的 股票/指數

標的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(5)

這里由于 B(t) 為布朗運動，因此滿足均值為

0， 方 差 為 T 的 正 態(tài) 分 布， 可 以 改 寫 為 ：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 1

其中，??為資產價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行（維

程）。

可以認為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權的價格作為最終現貨

的期權收益的貼現期望，到期時間為??：

??,-.?? ?? ?? ?? 2

這個期望是在適當的風險中性度量下得到的，該度量使漂移量??等于無風險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 4

這是一個常系數隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 5

這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0,1)。

將上式使用??(??)的指數形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 6

使用風險中性定價方法可以得到期權價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 7

在這種情況下，??的值是看漲期權或看跌期權的收益。通過對這些收益的總和取平均值，然后取無風

現，我們得到了期權的近似價格。

=67/0

雪球期權屬于路徑依賴型奇異期權，其結構相對復雜，本質是一種帶障礙的看跌期權，自 2019 年開

雪球這種非保本型收益憑證受到市場上越來越多的關注，各類金融機構紛紛以不同角色參與其中。以

所示案例為例：

表 1 雪球期權相關要素

雪球期權

掛鉤標的 股票/指數

標的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

。

將上式使用 S(t) 的指數形式改寫為 ：

期權風險中性定價通過 Black-Scholes(BS)模型實現，其隨機微分方程（SDE）由下面公式給出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 其中，??為資產價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行（維

納過程）。

可以認為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權的價格作為最終現價格的期權收益的貼現期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當的風險中性度量下得到的，該度量使漂移量??等于無風險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(0,1)將上式使用??(??)的指數形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風險中性定價方法可以得到期權價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權或看跌期權的收益。通過對這些收益的總和取平均值，然后取無險折現，我們得到了期權的近似價格。

2.2 <=67/0

雪球期權屬于路徑依賴型奇異期權，其結構相對復雜，本質是一種帶障礙的看跌期權，自 2019 年開

始，雪球這種非保本型收益憑證受到市場上越來越多的關注，各類金融機構紛紛以不同角色參與其中。表 1 所示案例為例：

表 1 雪球期權相關要素

雪球期權

掛鉤標的 股票/指數

標的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(6)

使用風險中性定價方法可以得到期權價格的

表達式如下 ：

事先約定的匯率（敲定價）向期權出售者購買/出賣約定數量的貨幣，并支付購買該項權力的權力金期權風險中性定價通過 Black-Scholes(BS)模型實現，其隨機微分方程（SDE）由下面公式給出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 其中，??為資產價格，??為股票的漂移量（瞬時期望收益率），??為股票的波動率，??為布朗運行納過程）。

可以認為????是一個均值為 0，方差為????的正態(tài)分布隨機變量，使用歐式香草期權的價格作為最終價格的期權收益的貼現期望，到期時間為??：

??,-.?? ?? ?? ?? 這個期望是在適當的風險中性度量下得到的，該度量使漂移量??等于無風險利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通過伊藤引理得到：

?? ?????? ?? ?? = ?? ? 1

2 ??8 ???? + ?????? ?? 這是一個常系數隨機微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? ? 1

2 ??8 ?? + ?? ???? 0,1 這里由于??(??)為布朗運動，因此滿足均值為 0，方差為??的正態(tài)分布，可以改寫為：??(??) = ????(將上式使用??(??)的指數形式改寫為：

?? ?? = ?? 0 ??-,@

8AB .CA .D E,@ 使用風險中性定價方法可以得到期權價格的表達式如下：

??,-.?? ?? ?? 0 ??-,@

8AB .CA .D E,@ 在這種情況下，??的值是看漲期權或看跌期權的收益。通過對這些收益的總和取平均值，然后取險折現，我們得到了期權的近似價格。

2.2 <=67/0

雪球期權屬于路徑依賴型奇異期權，其結構相對復雜，本質是一種帶障礙的看跌期權，自 2019 始，雪球這種非保本型收益憑證受到市場上越來越多的關注，各類金融機構紛紛以不同角色參與其中表 1 所示案例為例：

表 1 雪球期權相關要素

雪球期權

掛鉤標的 股票/指數

標的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

(7)

在這種情況下，f 的值是看漲期權或看跌期

權的收益。通過對這些收益的總和取平均值，然

后取無風險折現，我們得到了期權的近似價格。

2.2 雪球期權定價

雪球期權屬于路徑依賴型奇異期權，其結

構相對復雜，本質是一種帶障礙的看跌期權，自

2019 年開始，雪球這種非保本型收益憑證受到市

場上越來越多的關注，各類金融機構紛紛以不同

角色參與其中。以表 1 所示案例為例。

其年化收益率與掛鉤標的價格變化的關系如

其年化收益率與掛鉤圖 1 所示。 標的價格變化的關系如圖 1 所示。

圖 1 雪球期權與標的價格關系

雪球期權最主要的特點是具有敲出水平和與敲入水平兩個門限，敲出水平每月觀測一次，敲入水平每

日觀測一次，如果發(fā)生敲出事件，產品終止并兌付收益；如果發(fā)生敲入事件，保護失效，若期末未敲出，

則相當于持有該股票。因此截止期末可分為三種情況：第一種情況為敲出，可獲得票息為：年化票息×名義

本金×存續(xù)月數/12，如圖 2 所示，第二個月雖然發(fā)生了敲入事件，但第三個月底敲出觀察日時發(fā)生了敲出

事件，因此可本金無損外加 3 個月的票息收益。

圖 1 ：雪球期權與標的價格關系

雪球期權最主要的特點是具有敲出水平和與

本期熱點

36

敲入水平兩個門限，敲出水平每月觀測一次，敲

入水平每日觀測一次，如果發(fā)生敲出事件，產品

終止并兌付收益；如果發(fā)生敲入事件，保護失效，

若期末未敲出，則相當于持有該股票。因此截

止期末可分為三種情況 ：第一種情況為敲出，可

獲得票息為 ：年化票息 × 名義本金 × 存續(xù)月數

/12，如圖 2 所示，第二個月雖然發(fā)生了敲入事件，

但第三個月底敲出觀察日時發(fā)生了敲出事件，因

此可本金無損外加 3 個月的票息收益。

其年化收益率與掛鉤標的價格變化的關系如圖 1 所示。

圖 1 雪球期權與標的價格關系

雪球期權最主要的特點是具有敲出水平和與敲入水平兩個門限，敲出水平每月觀測一次，敲入水平每

觀測一次，如果發(fā)生敲出事件，產品終止并兌付收益；如果發(fā)生敲入事件，保護失效，若期末未敲出，

相當于持有該股票。因此截止期末可分為三種情況：第一種情況為敲出，可獲得票息為：年化票息×名義

金×存續(xù)月數/12，如圖 2 所示，第二個月雖然發(fā)生了敲入事件，但第三個月底敲出觀察日時發(fā)生了敲出

件，因此可本金無損外加 3 個月的票息收益。

圖 2 敲出

第二種情況為敲入未敲出，結算金額為：名義本金×MAX（0，期初價格-期末價格）/期初價格，如圖

所示，在第三個月發(fā)生了敲入事件，產品存續(xù)期間未發(fā)生敲出事件，因此本金受損，無票息收益。

圖 3 敲入未敲出

第三種情況為未敲入未敲出，可獲得票息為：年化票息×名義本金×存續(xù)月數/12，如圖 4 所示，存續(xù)

圖 2 ：敲出

第二種情況為敲入未敲出，結算金額為 ：名

義本金 ×MAX（0，期初價格 - 期末價格）/ 期

初價格，如圖 3 所示，在第三個月發(fā)生了敲入事

件，產品存續(xù)期間未發(fā)生敲出事件，因此本金受

損，無票息收益。

其年化收益率與掛鉤標的價格變化的關系如圖 1 所示。

圖 1 雪球期權與標的價格關系

雪球期權最主要的特點是具有敲出水平和與敲入水平兩個門限，敲出水平每月觀測一次，敲入水平每

日觀測一次，如果發(fā)生敲出事件，產品終止并兌付收益；如果發(fā)生敲入事件，保護失效，若期末未敲出，

則相當于持有該股票。因此截止期末可分為三種情況：第一種情況為敲出，可獲得票息為：年化票息×名義

本金×存續(xù)月數/12，如圖 2 所示，第二個月雖然發(fā)生了敲入事件，但第三個月底敲出觀察日時發(fā)生了敲出

事件，因此可本金無損外加 3 個月的票息收益。

圖 2 敲出

第二種情況為敲入未敲出，結算金額為：名義本金×MAX（0，期初價格-期末價格）/期初價格，如圖

所示，在第三個月發(fā)生了敲入事件，產品存續(xù)期間未發(fā)生敲出事件，因此本金受損，無票息收益。

圖 3 敲入未敲出

第三種情況為未敲入未敲出，可獲得票息為：年化票息×名義本金×存續(xù)月數/12，如圖 4 所示，存續(xù)

圖 3 ：敲入未敲出

第三種情況為未敲入未敲出，可獲得票息為：

年化票息 × 名義本金 × 存續(xù)月數 /12，如圖 4

所示，存續(xù)期間期間未發(fā)生敲入事件與敲出事件，

期間期間未發(fā)生敲入事可獲得滿期 6 個月的票息收益。 件與敲出事件，可獲得滿期 6 個月的票息收益。

圖 4 未敲入未敲出

圖 4 ：未敲入未敲出

2、FPGA 與 oneAPI 的優(yōu)勢

CPU（Central Processing Unit， 中 央 處 理

器）的摩爾定律已入暮年，在高性能計算領域，

CPU 的表現已經漸漸被 GPU（Graphics Processing

Unit，圖形處理器）、ASIC（Application Specific

Integrated Circuit，專用集成電路）和 FPGA 等硬

件超越。FPGA 常年來被用于 ASIC 的小批量替

代品，以同時提供強大的計算能力和足夠的靈活

性，如圖 5 所示。

CPU、GPU 都屬于馮·諾依曼結構，指令

譯碼執(zhí)行、共享內存。FPGA 之所以比 CPU 甚至

GPU 能效高，本質上是無指令、無需共享內存的

體系結構帶來的福利。馮氏結構中，由于執(zhí)行單

元（如 CPU 核）可能執(zhí)行任意指令，就需要有指

令存儲器、譯碼器、各種指令的運算器、分支跳

轉處理邏輯。由于指令流的控制邏輯復雜，不可

能有太多條獨立的指令流，因此 GPU 使用 SIMD

（Single Instruction Multiple Data)，單指令流多數據

流）來讓多個執(zhí)行單元以同樣的步調處理不同的

數據，CPU 也支持 SIMD 指令。而 FPGA 每個邏

輯單元的功能在重編程（燒寫）時就已經確定，

不需要指令。馮氏結構中使用內存有兩種作用。

一是保存狀態(tài)，二是在執(zhí)行單元間通信。由于內

存是共享的，就需要做訪問仲裁 ；為了利用訪問

局部性，每個執(zhí)行單元有一個私有的緩存，這就

要維持執(zhí)行部件間緩存的一致性。對于保存狀態(tài)

的需求，FPGA 中的寄存器和 BRAM（Block RAM，

片上內存）是屬于各自的控制邏輯的，無需不必

險折現，我們得到了期權的近似價格。

2.2 <=67/0

雪球期權屬于路徑依賴型奇異期權，其結構相對復雜，本質是一種帶障礙的看跌期權，自 2019 年開

始，雪球這種非保本型收益憑證受到市場上越來越多的關注，各類金融機構紛紛以不同角色參與其中。以

表 1 所示案例為例：

表 1 雪球期權相關要素

雪球期權

掛鉤標的 股票/指數

標的初始價格 100 元

期限 6 個月

敲出水平 100%

敲入水平 75%

票息 年化 25%

表 1 ：雪球期權相關要素

交易技術前沿

37

要的仲裁和緩存。對于通信的需求，FPGA 每個

邏輯單元與周圍邏輯單元的連接在重編程（燒寫）

時就已經確定，并不需要通過共享內存來通信。

FPGA 同時擁有流水線并行和數據并行，而

GPU 幾乎只有數據并行（流水線深度受限）。

例如處理一個數據包有 10 個步驟，FPGA

可以搭建一個 10 級流水線，流水線的不同級在

處理不同的數據包，每個數據包流經 10 級之后

處理完成，每處理完成一個數據包，就能馬上輸

出 ；而 GPU 的數據并行方法是做 10 個計算單元，

每個計算單元也在處理不同的數據包，然而所有

的計算單元必須按照統(tǒng)一的步調，做相同的事情，

這就要求 10 個數據包必須一起輸入、一起輸出，

輸入輸出的延遲增加了。

當任務是逐個而非成批到達的時候，流水線

并行比數據并行可實現更低的延遲。因此對流式

計算的任務，FPGA 比 GPU 天生有延遲方面的優(yōu)

勢，如圖 6 所示。

執(zhí)行單元有一個私有的緩存，這就要維持執(zhí)行部件間緩存的一致性。對于保存狀態(tài)的需求，FPGA 中的寄

存器和 BRAM（Block RAM，片上內存）是屬于各自的控制邏輯的，無需不必要的仲裁和緩存。對于通信

的需求，FPGA 每個邏輯單元與周圍邏輯單元的連接在重編程（燒寫）時就已經確定，并不需要通過共享

內存來通信。

FPGA 同時擁有流水線并行和數據并行，而 GPU 幾乎只有數據并行（流水線深度受限）。

例如處理一個數據包有 10 個步驟，FPGA 可以搭建一個 10 級流水線，流水線的不同級在處理不同的

數據包，每個數據包流經 10 級之后處理完成，每處理完成一個數據包，就能馬上輸出；而 GPU 的數據并

行方法是做 10 個計算單元，每個計算單元也在處理不同的數據包，然而所有的計算單元必須按照統(tǒng)一的步

調，做相同的事情，這就要求 10 個數據包必須一起輸入、一起輸出，輸入輸出的延遲增加了。

當任務是逐個而非成批到達的時候，流水線并行比數據并行可實現更低的延遲。因此對流式計算的任

務，FPGA 比 GPU 天生有延遲方面的優(yōu)勢，如圖 6 所示。

圖 6 并行流水線

各體系架構性能數量級比較（以 16 位整數乘法為例）如表 2 所示。

表 2 各體系架構性能數量級比較

體系架構 吞吐量 延遲 功耗 靈活性

CPU ~1T N/A ~100W 很高

GPU ~10T ~1ms ~300W 高

FPGA(Stratix 10) ~10T ~1us ~30W 高

ASIC ~10T ~1us ~30W 低

期權計算不可能有閉合形式的解，而是通過用蒙特卡羅方法模擬了許多可能的路徑，最終得到了一個

預期的收益值。使用蒙特卡羅模擬需要生成高質量的隨機數，并進行上千萬點的模擬，傳統(tǒng)的使用 CPU 來

進行計算，耗時非常巨大，而 FPGA 通過使用通道以及循環(huán)流水線的排布，能夠有效提升性能，減小計算

延遲。

而傳統(tǒng)的 FPGA 開發(fā)一般選擇硬件描述語言（如 VHDL/Verilog HDL），開發(fā)周期長、難度大，對于

使用高級語言進行開發(fā)的軟件工程師而言，進入的門檻非常高。在開發(fā) FPGA 時，需要硬件理解深刻，重

點是需要非常詳細的設計工作，合理規(guī)劃硬件資源進行任務并行和數據并行的處理業(yè)務，包括處理的時序、

RAM 的分配,還要經過一系列的仿真、綜合等。

Intel FPGA SDK 提供了高效的使用高級語言開發(fā) FPGA 的方式，通過 OpenCL 或 oneAPI 工具來進行

FPGA 開發(fā)。相比于 OpenCL，作為升級版，oneAPI 真正意義上實現了天下大同。oneAPI 編程模型簡化了

CPU 和加速器的編程，基于 C++特性與 SYCL 并行性的標準跨體系結構語言 DPC++。DPC++支持主機和

加速器的代碼復用，使用單一的源語言，執(zhí)行和內存依賴清晰地溝通。DPC++代碼內的映射可用于將應用

圖 6 ：并行流水線

各體系架構性能數量級比較（以 16 位整數

乘法為例）如表 2 所示。

期權計算不可能有閉合形式的解，而是通過

用蒙特卡羅方法模擬了許多可能的路徑，最終得

到了一個預期的收益值。使用蒙特卡羅模擬需要

生成高質量的隨機數，并進行上千萬點的模擬，

傳統(tǒng)的使用 CPU 來進行計算，耗時非常巨大，

2 FPGA > oneAPI )?@

CPU（Central Processing Unit，中央處理器）的摩爾定律已入暮年，在高性能計算領域，CPU 的表現

已經漸漸被 GPU（Graphics Processing Unit，圖形處理器）、ASIC（Application Specific Integrated Circuit，

專用集成電路）和 FPGA 等硬件超越。FPGA 常年來被用于 ASIC 的小批量替代品，以同時提供強大的計算

能力和足夠的靈活性，如圖 5 所示。

圖 5 不同體系結構性能和靈活性的比較

CPU、GPU 都屬于馮·諾依曼結構，指令譯碼執(zhí)行、共享內存。FPGA 之所以比 CPU 甚至 GPU 能效

高，本質上是無指令、無需共享內存的體系結構帶來的福利。馮氏結構中，由于執(zhí)行單元（如 CPU 核）可

能執(zhí)行任意指令，就需要有指令存儲器、譯碼器、各種指令的運算器、分支跳轉處理邏輯。由于指令流的

控制邏輯復雜，不可能有太多條獨立的指令流，因此 GPU 使用 SIMD（Single Instruction Multiple Data)，單

指令流多數據流）來讓多個執(zhí)行單元以同樣的步調處理不同的數據，CPU 也支持 SIMD 指令。而 FPGA 每

個邏輯單元的功能在重編程（燒寫）時就已經確定，不需要指令。馮氏結構中使用內存有兩種作用。一是

保存狀態(tài)，二是在執(zhí)行單元間通信。由于內存是共享的，就需要做訪問仲裁；為了利用訪問局部性，每個

圖 5 ：不同體系結構性能和靈活性的比較

執(zhí)行單元有一個私有的緩存，這就要維持執(zhí)行部件間緩存的一致性。對于保存狀態(tài)的需求，FPGA 中的寄

存器和 BRAM（Block RAM，片上內存）是屬于各自的控制邏輯的，無需不必要的仲裁和緩存。對于通信

的需求，FPGA 每個邏輯單元與周圍邏輯單元的連接在重編程（燒寫）時就已經確定，并不需要通過共享

內存來通信。

FPGA 同時擁有流水線并行和數據并行，而 GPU 幾乎只有數據并行（流水線深度受限）。

例如處理一個數據包有 10 個步驟，FPGA 可以搭建一個 10 級流水線，流水線的不同級在處理不同的

數據包，每個數據包流經 10 級之后處理完成，每處理完成一個數據包，就能馬上輸出；而 GPU 的數據并

行方法是做 10 個計算單元，每個計算單元也在處理不同的數據包，然而所有的計算單元必須按照統(tǒng)一的步

調，做相同的事情，這就要求 10 個數據包必須一起輸入、一起輸出，輸入輸出的延遲增加了。

當任務是逐個而非成批到達的時候，流水線并行比數據并行可實現更低的延遲。因此對流式計算的任

務，FPGA 比 GPU 天生有延遲方面的優(yōu)勢，如圖 6 所示。

圖 6 并行流水線

各體系架構性能數量級比較（以 16 位整數乘法為例）如表 2 所示。

表 2 各體系架構性能數量級比較

體系架構 吞吐量 延遲 功耗 靈活性

CPU ~1T N/A ~100W 很高

GPU ~10T ~1ms ~300W 高

FPGA(Stratix 10) ~10T ~1us ~30W 高

ASIC ~10T ~1us ~30W 低

期權計算不可能有閉合形式的解，而是通過用蒙特卡羅方法模擬了許多可能的路徑，最終得到了一個

預期的收益值。使用蒙特卡羅模擬需要生成高質量的隨機數，并進行上千萬點的模擬，傳統(tǒng)的使用 CPU 來

進行計算，耗時非常巨大，而 FPGA 通過使用通道以及循環(huán)流水線的排布，能夠有效提升性能，減小計算

延遲。

表 2 ：各體系架構性能數量級比較

本期熱點

38

而 FPGA 通過使用通道以及循環(huán)流水線的排布，

能夠有效提升性能，減小計算延遲。

而傳統(tǒng)的 FPGA 開發(fā)一般選擇硬件描述語言

（如 VHDL/Verilog HDL），開發(fā)周期長、難度大，

對于使用高級語言進行開發(fā)的軟件工程師而言，

進入的門檻非常高。在開發(fā) FPGA 時，需要硬件

理解深刻，重點是需要非常詳細的設計工作，合

理規(guī)劃硬件資源進行任務并行和數據并行的處理

業(yè)務，包括處理的時序、RAM 的分配 , 還要經過

一系列的仿真、綜合等。

Intel FPGA SDK 提供了高效的使用高級語言

開發(fā) FPGA 的方式，通過 OpenCL 或 oneAPI 工具

來進行 FPGA 開發(fā)。相比于 OpenCL，作為升級

版，oneAPI 真正意義上實現了天下大同。oneAPI

編程模型簡化了 CPU 和加速器的編程，基于

C++ 特性與 SYCL 并行性的標準跨體系結構語言

DPC++。DPC++ 支持主機和加速器的代碼復用，

使用單一的源語言，執(zhí)行和內存依賴清晰地溝通。

DPC++ 代碼內的映射可用于將應用程序轉換為在

硬件 ( 或一組硬件 ) 上運行，從而最大程度地加

速工作負載。主機可以簡化設備代碼的開發(fā)和調

試，甚至在沒有加速器的平臺上也是如此。

圖 7 所示為一個通過 DPC++ 語言開發(fā)的

oneAPI 簡單應用，用來將數組的每個元素設置

為其下標的值?？梢钥闯觯鳈C代碼和加速器代

碼都組合在一個源文件中，使用的語法是標準的

C++，并通過 C++ 類來實現并行性。該示例的邏

輯為 ：第 8 行和第 9 行創(chuàng)建了一個包含 16 個 int

元素的 buffer，第 11 行構造一個隊列來表示主機

到加速器之間的連接。創(chuàng)建隊列后，調用形參為

lambda 函數的 submit() 成員函數向加速器提交工

作，它在第 12 行創(chuàng)建一個訪問器，使得可以在

buffer 中寫入元素，在第 13 行調用 parallel_for()

函數來執(zhí)行加速器上的代碼。調用的 parallel_

for() 函數有兩個參數，一個參數是 lambda 函數，

另一個是表示 buffer 中元素數量的范圍對象“r”，

lambda 在加速器上被該范圍內的每個索引調用一

次，通過使用在第 12 行創(chuàng)建的 out 訪問器將一

個值賦給 buffer。在調用 parallel_for() 之后，代碼

的主機部分將繼續(xù)運行，而無需等待加速器上的

工作完成，并在第 18 行創(chuàng)建一個構造函數 host_

accessor 來讀取 buffer 中的元素，這里 buffer 中的

元素是由加速器寫入的，所以在 parallel_for() 的

數據傳遞完成之前，host_accessor 將被阻塞，加

速器工作完成后，主機開始執(zhí)行第 18 行之后的

代碼。

程序轉換為在硬件(或一組硬件)上運行，從而最大程度地加速工作負載。主機可以簡化設備代碼的開發(fā)和調試，甚至在沒有加速器的平臺上也是如此。

圖7所示為一個通過DPC++語言開發(fā)的oneAPI簡單應用，用來將數組的每個元素設置為其下標的值可以看出，主機代碼和加速器代碼都組合在一個源文件中，使用的語法是標準的 C++，并通過 C++類來現并行性。該示例的邏輯為：第 8 行和第 9 行創(chuàng)建了一個包含 16 個 int 元素的 buffer，第 11 行構造一個列來表示主機到加速器之間的連接。創(chuàng)建隊列后，調用形參為 lambda 函數的 submit()成員函數向加速器交工作，它在第 12 行創(chuàng)建一個訪問器，使得可以在 buffer 中寫入元素，在第 13 行調用 parallel_for()函數執(zhí)行加速器上的代碼。調用的 parallel_for()函數有兩個參數，一個參數是 lambda 函數，另一個是表示 bu中元素數量的范圍對象“r”，lambda 在加速器上被該范圍內的每個索引調用一次，通過使用在第 12 行建的 out 訪問器將一個值賦給 buffer。在調用 parallel_for()之后，代碼的主機部分將繼續(xù)運行，而無需等加速器上的工作完成，并在第 18 行創(chuàng)建一個構造函數 host_accessor 來讀取 buffer 中的元素，這里 buffer 的元素是由加速器寫入的，所以在 parallel_for()的數據傳遞完成之前，host_accessor 將被阻塞，加速器工完成后，主機開始執(zhí)行第 18 行之后的代碼。

圖 7 oneAPI 開發(fā)示例

此外，oneAPI 編程模型提供了可以跨硬件目標使用的全面統(tǒng)一的開發(fā)人員工具組合，包括跨越多個作負載域的一系列性能庫。這些庫包括為每個目標體系結構定制編碼的函數，因此相同的函數調用可以受支持的體系結構之間提供優(yōu)化的性能，如圖 8 所示，利用 oneAPI 編程模型的應用程序可以在從 CPU FPGA 的多個目標硬件平臺上運行。

圖 7 ：oneAPI 開發(fā)示例

此外，oneAPI 編程模型提供了可以跨硬件

目標使用的全面統(tǒng)一的開發(fā)人員工具組合，包括

跨越多個工作負載域的一系列性能庫。這些庫包

括為每個目標體系結構定制編碼的函數，因此相

同的函數調用可以在受支持的體系結構之間提供

優(yōu)化的性能，如圖 8 所示，利用 oneAPI 編程模

型的應用程序可以在從 CPU 到 FPGA 的多個目

標硬件平臺上運行。

與此同時，Intel 也在大力投入對 oneAPI 的

研發(fā)，使其開發(fā)效率，編譯性能，以及運算性能

都在不斷提高，oneAPI 的某些運算引擎甚至超過

了硬件語言描述 DPS 的性能。使用 oneAPI 來通

交易技術前沿

39

過 FPGA 進行期權定價加速，無論從效率還是性

能上講都是不二之選。

3、基于 oneAPI 期權定價設計

期權計算的流程主要可分為隨機數生成與

期權數值計算兩部分，隨機數部分又可分解為隨

機數初始化和隨機數生成，數值計算部分可分解

為定價和求和。使用 oneAPI 進行設計，每部分

都可通過 Channel 利用 FIFO 隊列將各 kernel 模

塊連接起來，達到流水線并行的效果，流程如圖

9 所示。MT Initial 選擇一個隨機數種子，計算

出梅森旋轉鏈，放入 Channel 0 ；MT Generation

從 Channel 0 中取出梅森旋轉鏈數據，計算出

偽 隨 機 數， 輸 入 Channel 1 ；Stock price Motion

從 Channel 1 中取出生成的隨機數，利用定價模

型計算出的結果輸入 Channel 2 ；累加器 Partial

Accumulate 從 Channel 2 中取出計算結果，累加

求和，輸出結果。

Mersenne Twister 初始化時，需要一個初始

化種子，然后生成長度為 624 的梅森旋轉鏈。因

為旋轉鏈上的后一個數據需要對前一個數據進行

計算才能得到，所以旋轉鏈的生成無法數據并行，

可以選擇流水線的方式進行優(yōu)化。MT Initial 和

MT Generation 之間通過 Channel 0 傳輸梅森旋轉

鏈數據。一般在選擇 Channel 數據大小和深度時，

選擇 2 的整數次冪。MT Initial 生成的旋轉鏈長

度為 624，可以選擇每次傳輸旋轉鏈中的 64 個或

128 個數據給 MT Generation。

MT Generation 的計算邏輯是 ：取出初始化

的 624 長度的初始化旋轉鏈，然后執(zhí)行旋轉算

法（針對整個鏈），以后以 624 為周期，用梅森

狀態(tài)鏈每生成 624 個隨機數，旋轉一次，隨后生

成下一組 624 個隨機數。同樣，將生成的隨機數

通過大小為 64 或 128 的 Channel 1 傳入到下一個

kernel 進行計算。歐式期權和雪球期權隨機數生

圖 8 oneAPI 跨工作域

與此同時，Intel 也在大力投入對 oneAPI 的研發(fā)，使其開發(fā)效率，編譯性能，以及運算性能都在不斷

提高，oneAPI 的某些運算引擎甚至超過了硬件語言描述 DPS 的性能。使用 oneAPI 來通過 FPGA 進行期權

定價加速，無論從效率還是性能上講都是不二之選。

3 !\" oneAPI 67/0AB

期權計算的流程主要可分為隨機數生成與期權數值計算兩部分，隨機數部分又可分解為隨機數初始化

和隨機數生成，數值計算部分可分解為定價和求和。使用 oneAPI 進行設計，每部分都可通過 Channel 利用

FIFO 隊列將各 kernel 模塊連接起來，達到流水線并行的效果，流程如圖 9 所示。MT Initial 選擇一個隨機

數種子，計算出梅森旋轉鏈，放入 Channel 0；MT Generation 從 Channel 0 中取出梅森旋轉鏈數據，計算出

偽隨機數，輸入 Channel 1；Stock price Motion 從 Channel 1 中取出生成的隨機數，利用定價模型計算出的

結果輸入 Channel 2；累加器 Partial Accumulate 從 Channel 2 中取出計算結果，累加求和，輸出結果。

圖 9 期權定價流水線并行

Mersenne Twister 初始化時，需要一個初始化種子，然后生成長度為 624 的梅森旋轉鏈。因為旋轉鏈

上的后一個數據需要對前一個數據進行計算才能得到，所以旋轉鏈的生成無法數據并行，可以選擇流水線

的方式進行優(yōu)化。MT Initial 和 MT Generation 之間通過 Channel 0 傳輸梅森旋轉鏈數據。一般在選擇 Channel

數據大小和深度時選擇2的整數次冪MTIitil生成的旋轉鏈長度為624可以選擇每次傳輸旋轉鏈中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 進行期權

定價加速，無論從效率還是性能上講都是不二之選。

3 !\" oneAPI 67/0AB

期權計算的流程主要可分為隨機數生成與期權數值計算兩部分，隨機數部分又可分解為隨機數初始化

和隨機數生成，數值計算部分可分解為定價和求和。使用 oneAPI 進行設計，每部分都可通過 Channel 利用

FIFO 隊列將各 kernel 模塊連接起來，達到流水線并行的效果，流程如圖 9 所示。MT Initial 選擇一個隨機

數種子，計算出梅森旋轉鏈，放入 Channel 0；MT Generation 從 Channel 0 中取出梅森旋轉鏈數據，計算出

偽隨機數，輸入 Channel 1；Stock price Motion 從 Channel 1 中取出生成的隨機數，利用定價模型計算出的

結果輸入 Channel 2；累加器 Partial Accumulate 從 Channel 2 中取出計算結果，累加求和，輸出結果。

圖 9 期權定價流水線并行

Mersenne Twister 初始化時，需要一個初始化種子，然后生成長度為 624 的梅森旋轉鏈。因為旋轉鏈

上的后一個數據需要對前一個數據進行計算才能得到，所以旋轉鏈的生成無法數據并行，可以選擇流水線

的方式進行優(yōu)化。MT Initial 和 MT Generation 之間通過 Channel 0 傳輸梅森旋轉鏈數據。一般在選擇 Channel

數據大小和深度時，選擇 2 的整數次冪。MT Initial 生成的旋轉鏈長度為 624，可以選擇每次傳輸旋轉鏈中

的 64 個或 128 個數據給 MT Generation。

MT Generation 的計算邏輯是：取出初始化的 624 長度的初始化旋轉鏈，然后執(zhí)行旋轉算法（針對整

個鏈），以后以 624 為周期，用梅森狀態(tài)鏈每生成 624 個隨機數，旋轉一次，隨后生成下一組 624 個隨機

數。同樣，將生成的隨機數通過大小為 64 或 128 的 Channel 1 傳入到下一個 kernel 進行計算。歐式期權和

雪球期權隨機數生成的方法是一樣的。

Stock Price Motion 部分為最主要的計算部分。與上面邏輯相同，通過 Channel 進行數據讀寫，首先將

Mersenne

Twister Initial

Mersenne

Twister

Generation

Stock Price

Motion

Partial

Accumulation

Channel 0 Channel 1 Channel 2

圖 8 ：oneAPI 跨工作域

圖 9 ：期權定價流水線并行

本期熱點

成的方法是一樣的。

Stock Price Motion部分為最主要的計算部分。

與上面邏輯相同，通過 Channel 進行數據讀寫，

首先將 MT Generation 傳入的隨機數值域限定在

0~1 之間，此時滿足（0，1）上的均勻分布，隨

后通過 Box-Muller 算法將（0，1）上的均勻分布

轉化為標準正態(tài)分布，進行下面的計算。對于歐

式期權，可直接使用 BS 公式進行定價，將結果

寫入 Channel 2 中，由于運算邏輯簡單，可使用

NDRange 提升計算性能，每次下發(fā) 8192 個計算

任務，充分使用流水線計算。對于雪球期權，在

BS 公式的基礎上，還需要進行復雜的向量運算，

來模擬三種不同的情景，所以每次展開一條蒙特

卡羅路徑進行模擬，將每條路徑的模擬價格寫入

Channel 2 中，每條路徑內部的 for 循環(huán)可以使用

數據并行來提高計算性能。

最 后 Partial Accumulation 部 分 為 累 加 求

和 , 從 Channel ２中讀取出期權價格之和，寫回

Buffer 中。對于歐式期權，每次發(fā)送 8192 個線

程，所以需要讀取完 8192 個數據；對于雪球期權，

進行了 mc 條蒙特卡羅路徑的模擬，所以需要讀

取完 mc 個數據。將和寫回主機的 Result Buffer

中求取平均值完成最終的期權定價。

4、結果驗證與分析

CPU 和 FPGA 在期權定價流程中有各自擅長

的模塊，本次驗證對歐式期權和雪球期權定價最

終性能在 CPU 和 FPGA 上進行綜合對比。

測試驗證對比環(huán)境 ：

CPU: Intel core i7 10700 @2.9GHz 8 cores

FPGA: Intel PAC D5005 with Stratix 10 GX

FPGA

4.1 歐式期權性能分析

在相同參數與相同蒙特卡羅模擬次數情況下

CPU 與 FPGA 的對歐式期權的定價結果如圖 10

與圖 11 所示。

改變蒙特卡羅模擬次數，對定價性能進行

比較，如圖 12 所示，可以看到，模擬次數越多，

FPGA 能夠更大程度地釋放性能。

FPGA 資源使用情況如圖 13 所示。

4.2 雪球期權性能分析

同樣，在相同參數與相同蒙特卡羅模擬次數

情況下 CPU 與 FPGA 對雪球期權的定價結果如

圖 14 與圖 15 所示。

改變蒙特卡羅模擬次數，對定價性能進行比

較，如圖 16 所示，同樣，隨著模擬次數的增加，

FPGA 性能提升更加明顯。

FPGA 資源使用情況如圖 17 所示。

圖 18 與圖 19 分別為雪球期權價格與波動率

sigma 以及票息 coupon 關系的線性回歸，計算符

合預期效果。

MT Generation 傳入的隨機數值域限定在 0~1 之間，此時滿足（0，1）上的均勻分布，隨后通過 Box-Muller

算法將（0，1）上的均勻分布轉化為標準正態(tài)分布，進行下面的計算。對于歐式期權，可直接使用 BS 公

式進行定價，將結果寫入 Channel 2 中，由于運算邏輯簡單，可使用 NDRange 提升計算性能，每次下發(fā) 8192

個計算任務，充分使用流水線計算。對于雪球期權，在 BS 公式的基礎上，還需要進行復雜的向量運算，

來模擬三種不同的情景，所以每次展開一條蒙特卡羅路徑進行模擬，將每條路徑的模擬價格寫入 Channel 2

中，每條路徑內部的 for 循環(huán)可以使用數據并行來提高計算性能。

最后 Partial Accumulation 部分為累加求和,從 Channel ２中讀取出期權價格之和，寫回 Buffer 中。對

于歐式期權，每次發(fā)送 8192 個線程，所以需要讀取完 8192 個數據；對于雪球期權，進行了 mc 條蒙特卡

羅路徑的模擬，所以需要讀取完 mc 個數據。將和寫回主機的 Result Buffer 中求取平均值完成最終的期權定

價。

4 CDEF>GH

CPU 和 FPGA 在期權定價流程中有各自擅長的模塊，本次驗證對歐式期權和雪球期權定價最終性能在

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

在相同參數與相同蒙特卡羅模擬次數情況下 CPU 與 FPGA 的對歐式期權的定價結果如圖 10 與圖 11

所示。

圖 10 歐式期權 CPU 定價結果

圖 11 歐式期權 FPGA 定價結果

改變蒙特卡羅模擬次數，對定價性能進行比較，如圖 12 所示，可以看到，模擬次數越多，FPGA 能夠

更大程度地釋放性能。

MT Generation 傳入的隨機數值域限定在 0~1 之間，此時滿足（0，1）上的均勻分布，隨后通過 Box-Muller

算法將（0，1）上的均勻分布轉化為標準正態(tài)分布，進行下面的計算。對于歐式期權，可直接使用 BS 公

式進行定價，將結果寫入 Channel 2 中，由于運算邏輯簡單，可使用 NDRange 提升計算性能，每次下發(fā) 8192

個計算任務，充分使用流水線計算。對于雪球期權，在 BS 公式的基礎上，還需要進行復雜的向量運算，

來模擬三種不同的情景，所以每次展開一條蒙特卡羅路徑進行模擬，將每條路徑的模擬價格寫入 Channel 2

中，每條路徑內部的 for 循環(huán)可以使用數據并行來提高計算性能。

最后 Partial Accumulation 部分為累加求和,從 Channel ２中讀取出期權價格之和，寫回 Buffer 中。對

于歐式期權，每次發(fā)送 8192 個線程，所以需要讀取完 8192 個數據；對于雪球期權，進行了 mc 條蒙特卡

羅路徑的模擬，所以需要讀取完 mc 個數據。將和寫回主機的 Result Buffer 中求取平均值完成最終的期權定

價。

4 CDEF>GH

CPU 和 FPGA 在期權定價流程中有各自擅長的模塊，本次驗證對歐式期權和雪球期權定價最終性能在

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

在相同參數與相同蒙特卡羅模擬次數情況下 CPU 與 FPGA 的對歐式期權的定價結果如圖 10 與圖 11

所示。

圖 10 歐式期權 CPU 定價結果

圖 11 歐式期權 FPGA 定價結果

改變蒙特卡羅模擬次數，對定價性能進行比較，如圖 12 所示，可以看到，模擬次數越多，FPGA 能夠

更大程度地釋放性能。

圖 10 ：歐式期權 CPU 定價結果

圖 11 ：歐式期權 FPGA 定價結果

40

交易技術前沿

圖圖 12 ：歐式期權性能對比 12 歐式期權性能對比

FPGA 資源使用情況如圖 13 所示。

圖 13 歐式期權 FPGA 資源使用情況

4.2 <=67IJGH

同樣，在相同參數與相同蒙特卡羅模擬次數情況下 CPU 與 FPGA 對雪球期權的定價結果如圖 14 與圖

15 所示。

圖 14 雪球期權 CPU 定價結果

圖 12 歐式期權性能對比

FPGA 資源使用情況如圖 13 所示。

圖 13 歐式期權 FPGA 資源使用情況

4.2 <=67IJGH

同樣，在相同參數與相同蒙特卡羅模擬次數情況下 CPU 與 FPGA 對雪球期權的定價結果如圖 14 與圖

15 所示。

圖 14 雪球期權 CPU 定價結果

圖 13 ：歐式期權 FPGA 資源使用情況

圖 12 歐式期權性能對比

FPGA 資源使用情況如圖 13 所示。

圖 13 歐式期權 FPGA 資源使用情況

4.2 <=67IJGH

同樣，在相同參數與相同蒙特卡羅模擬次數情況下 CPU 與 FPGA 對雪球期權的定價結果如圖 14 與圖

15 所示。

圖 14 雪球期權 CPU 定價結果

圖 12 歐式期權性能對比

FPGA 資源使用情況如圖 13 所示。

圖 13 歐式期權 FPGA 資源使用情況

4.2 <=67IJGH

同樣，在相同參數與相同蒙特卡羅模擬次數情況下 CPU 與 FPGA 對雪球期權的定價結果如圖 14 與圖

15 所示。

圖 14 雪球期權 CPU 定價結果

圖 14 ：雪球期權 CPU 定價結果

圖 15 ：雪球期權 FPGA 定價結果

41

本期熱點

圖 15 雪球期權 FPGA 定價結果

改變蒙特卡羅模擬次數，對定價性能進行比較，如圖 16 所示，同樣，隨著模擬次數的增加，FPGA

性能提升更加明顯。

圖 16 雪球期權性能對比

FPGA 資源使用情況如圖 17 所示。

圖 17 雪球期權 FPGA 資源使用情況

圖 18 與圖 19 分別為雪球期權價格與波動率 sigma 以及票息 coupon 關系的線性回歸，計算符合預期

效果。

圖 15 雪球期權 FPGA 定價結果

改變蒙特卡羅模擬次數，對定價性能進行比較，如圖 16 所示，同樣，隨著模擬次數的增加，FPGA

性能提升更加明顯。

圖 16 雪球期權性能對比

FPGA 資源使用情況如圖 17 所示。

圖 17 雪球期權 FPGA 資源使用情況

圖 18 與圖 19 分別為雪球期權價格與波動率 sigma 以及票息 coupon 關系的線性回歸，計算符合預期

效果。

圖 16 ：雪球期權性能對比

圖 17 ：雪球期權 FPGA 資源使用情況

圖 18 雪球期權價格與 sigma 的線性回歸

圖 19 雪球期權價格與 coupon 的線性回歸

CK圖 18 雪球期權價格與 sigma 的線性回歸

圖 18 ：雪球期權價格與 sigma 的線性回歸 圖 19 ：雪球期權價格與 coupon 的線性回歸

42

交易技術前沿

結論

本研究作為使用 oneAPI 在金融領域進行加

速的初步探索，使用 DPC++ 語言，采用流水線

并行與數據并行方式，設計出多種期權定價模

型，并分別通過對歐式期權定價與雪球期權定價

的對比分析，相比于傳統(tǒng)軟件處理方式，使用

FPGA 處理的綜合性能均可獲得較大的提升，并

且隨著模擬次數的增加，獲得更加精確的期權定

價結果的同時，FPGA 能夠更大程度地釋放性能，

在模擬 2M（2*1024*1024）條蒙特卡羅路徑時，

分別可獲得 20 倍左右與 30 倍左右的性能提升。

國泰君安在金融硬件加速領域深耕多年，后續(xù)將

繼續(xù)精進，使用 oneAPI 與 FPGA 在金融硬件加

速領域進行更多的研究與探索，為業(yè)內持續(xù)輸出

經驗。

43

探索與應用

6 證券運維系統(tǒng)自動化代理平臺建設實踐

7 基于上證云的數據跨境流動管理方案研究與實現

8 安信證券網絡系統(tǒng)自動化運維平臺建設實踐

9 興業(yè)證券應用性能監(jiān)控系統(tǒng)建設思路、方法和實踐

10 一種可擴展的多因素訪問控制方法及實踐

11 證券公司智慧營銷與服務平臺建設

12 證券行業(yè)網站智能數據搜索服務的研究與實踐

13 關于 ION GROUP 遭遇勒索病毒攻擊事件的分析

思考報告

交易技術前沿

45

證券運維系統(tǒng)自動化代理平臺

建設實踐

肖鋼、徐志彬、柴晨、王軍、喻文強、張皓凌 / 中信建投證券股份有限公司

E-mail ：chaichen@csc.com.cn

1、概述

在智能運維時代，自動化代理平臺是必不可

少的網絡運維系統(tǒng)。面對眾多運維子系統(tǒng)，系統(tǒng)

基本是“相互孤立、獨自運行”的，并沒有統(tǒng)一

的代理平臺對接龐雜的服務器，各個運維子系統(tǒng)

在執(zhí)行業(yè)務操作的時候，往往自研一套服務器交

互系統(tǒng)獨自進行， 既造成了公司內部研發(fā)資源的

浪費，同時這些交互系統(tǒng)無論是系統(tǒng)架構可用性

還是穩(wěn)定性，可擴展性上都差強人意。甚至有些

在全球數字化經濟的大浪潮下，人工智能、區(qū)塊鏈、云計算和大數據等技術的發(fā)展

不斷沖擊著證券行業(yè)的運維模式。隨著運維體系的復雜化和服務器的差異化加劇，運維成

本不斷增長，運維人員的技術要求更加苛刻，因此，智能化、高可靠、統(tǒng)一的自動化代理

平臺成為證券運維體系的一項重點工作。

中信建投證券自動化代理平臺通過構建統(tǒng)一的運維服務入口，將運維系統(tǒng)有機結合

在一起。近年來，微服務架構與異步通信技術快速發(fā)展，并逐漸成為系統(tǒng)建設的主流技術，

微服務架構與異步通信技術能夠有效提高系統(tǒng)穩(wěn)定性與可擴展性，為自動化代理平臺建設

提供了成熟的解決方案。本文通過介紹自動化代理平臺的探索和實踐，針對運維體系數字

化轉型中遇到的外部數據規(guī)范不統(tǒng)一、服務器差異化、運維系統(tǒng)復雜化等問題，分享解決

方案和實踐經驗，助力證券行業(yè)數字化發(fā)展。

探索與應用

46

業(yè)務場景下，還需要運維人員人為干預，手動的

在服務器上執(zhí)行運維指令，無形增加了運維人員

的工作難度，加大了運維成本。

自動化代理平臺將運維子系統(tǒng)和服務器有機

的連接在一起，通過自動化代理平臺統(tǒng)一對服務

器進行動態(tài)管理，同時使用高效的異步接口為運

維子系統(tǒng)提供服務。自動化代理平臺作為外部系

統(tǒng)和內部服務器之間通信的橋梁，我們設計了文

件傳輸、命令調用等基礎功能，在此基礎上，又

將擴展出信息采集、數據備份、應用部署和代理

節(jié)點狀態(tài)監(jiān)控等一系列功能。為了系統(tǒng)的穩(wěn)定運

行，需要對代理的穩(wěn)定性、安全性進行有效地把

握，所以對代理的性能的并發(fā)量、吞吐量、安全

性又有一定的要求。此外，還需要對代理的各個

客戶端進行統(tǒng)一管理，實現代理狀態(tài)監(jiān)控和自動

修復。

目前，運維系統(tǒng)逐漸走向智能化、標準化，

自動化代理平臺可節(jié)省大量人力運維成本，并且

可提供高效、穩(wěn)定的運維服務。如何利用云計算

技術與微服務架構，構建高可用、可擴展的自動

化代理平臺，成為證券公司亟需解決的問題。本

文將介紹中信建投證券對于自動化代理平臺的架

構探索，并闡述架構探索中的實踐與經驗。

2、自動化代理平臺架構

2.1 總體設計

自動化代理平臺采用微服務架構，系統(tǒng)中的

各個微服務可被獨立部署，各個微服務之間是松

耦合的。每個微服務僅關注某項獨立的功能模塊。

整體架構具有快速部署、高擴展性、高容錯性和

去集中化等特點，主要由六個層級構成 ：

（1）用戶層

用戶層是自動化代理平臺的操作入口，用戶

可以通過將運維管理系統(tǒng)與自動化代理平臺對接

來處理自身業(yè)務訴求，也可以通過訪問自動化代

理平臺的 Web 頁面進行人機交互。為了便于用

戶系統(tǒng)對接用戶層，我們提供了可直接集成的自

動化代理平臺工具包，用戶通過 API 指令調用自

動化代理平臺工具包，并由自動化代理平臺工具

包來完成與自動化代理平臺系統(tǒng)的交互。

（2）網關層

網關層可以對外暴露聚合 API，屏蔽內部微

服務的微小變動，保持整個系統(tǒng)的穩(wěn)定性。

在運維體系中，通常會有眾多終端服務器，

他們提供不同類型的服務，且通常分布在不同的

物理機房中。想要從用戶層精準的操作某一個機

圖 1 ：自動化代理平臺層級結構圖 圖 1 自動化代理平臺層級結構圖

（1）用戶層

用戶層是自動化代理平臺的操作入口，用戶可以通過將運維管理系統(tǒng)與自動化代理平臺對接來處理自

身業(yè)務訴求，也可以通過訪問自動化代理平臺的 Web 頁面進行人機交互。為了便于用戶系統(tǒng)對接用戶層，

我們提供了可直接集成的自動化代理平臺工具包，用戶通過 API 指令調用自動化代理平臺工具包，并由自

交易技術前沿

47

房的某一臺服務器通常是很困難和繁瑣的。自動

化代理平臺采用了二級代理和動態(tài)路由的方案解

決了這個痛點問題，通過在物理機房部署二級代

理，將機房內的服務器使用 Netty 連接在一起，再

通過動態(tài)路由的方式將用戶請求路由到各二級代

理，最終通過 Netty 完成指定服務器的業(yè)務操作。

當然這只是網關層眾多功能中的一部分，它

還可以做負載均衡，統(tǒng)一鑒權，協(xié)議轉換，監(jiān)控

監(jiān)測等一系列功能。

（3）熔斷層

分布式系統(tǒng)環(huán)境下，服務間依賴非常常見，

一個業(yè)務調用通常依賴多個基礎服務。對于同步

調用，當某服務不可用時，會導致上級服務的請

求線程被阻塞，當有大批量上級服務請求時，最

終可能導致整個系統(tǒng)資源耗盡，無法繼續(xù)對外提

供服務。并且這種不可用可能沿請求調用鏈向上

傳遞，導致雪崩效應。因此，為了構建穩(wěn)定、可

靠的分布式系統(tǒng)，熔斷層必不可少，熔斷層能夠

對對來自依賴的故障進行隔離，當依賴服務不可

用時，當前服務啟動自我保護功能，從而避免發(fā)

生雪崩效應。

（4）服務層

服務層負責提供可復用的服務，通過集群

方式實現高可用，用戶層通過分布式服務調用框

架訪問到服務層，分布式服務調用框架會在網關

層實現軟件負載均衡，并通過服務注冊中心服務

EurekaServer 對提供服務的服務器進行心跳檢測，

發(fā)現有服務不可用，立即通知客戶端程序修改服

務訪問列表，剔除不可用的服務器。

AgentServer 在架構上充當了二級代理的角

色，通過 AgentServer 將用戶層和邏輯層連接在

一起，AgentServer 在功能上是自動化代理平臺的

核心服務，通過 Netty 服務端的形式與邏輯層的

服務器中的 Netty 客戶端進行連接，將用戶層請

求處理過后交由邏輯層進行執(zhí)行。

AgentRegister 主要有兩個作用，一是作為

Netty 客戶端的注冊中心，對 Netty 連接狀態(tài)進行

監(jiān)控管理，二是為網關層提供動態(tài)的 Netty 連接

信息，是實現動態(tài)路由的關鍵。

（5）邏輯層

邏輯層包含特定于業(yè)務領域的邏輯，是最終

進行業(yè)務操作的環(huán)節(jié)。各服務器通過 Netty 客戶

端與服務層建立連接，接收服務層請求并完成相

應業(yè)務邏輯，對于耗費資源類操作部分通過服務

層運算完成后再交由邏輯層進一步處理，避免服

務器負載過高影響其他交易系統(tǒng)的操作。

（6）數據層

數據層是操作數據（數據庫或者文本文件等）

的操作層，為業(yè)務邏輯層或控制層提供數據服務。

對于使用頻率較低，數據量龐大的數據，例如審

計信息、歷史數據等，使用關系型數據庫 MySQL

進行管理，對于使用頻率較高，同時對使用場景

的響應時間要求較為嚴格的關鍵數據，在存儲

MySQL 的同時還運用到了緩存數據庫 Redis，一

來提升數據查詢的響應速度，二來對 MySQL 進

一步保護，避免出現緩存擊穿和雪崩，三來提供

分布式鎖，避免集群場景下的服務間狀態(tài)不感知

導致的業(yè)務故障。

2.2 技術框架

自動化代理平臺技術選型為 Spring Cloud 微

服務架構和 Netty 框架。

Spring Cloud 是一系列框架的有序集合。它

利用 Spring Boot 的開發(fā)便利性巧妙地簡化了分

布式系統(tǒng)基礎設施的開發(fā)，如服務發(fā)現注冊、配

置中心、消息總線、負載均衡、斷路器、數據監(jiān)

控等。Spring Cloud 作為一套成熟的分布式服務

治理的框架，已得到了廣泛的應用。

Netty 是一款用于開發(fā)高性能網絡系統(tǒng)的

Java 框架，它封裝了網絡編程的復雜性，使得網

絡編程更容易的實現，同時 Netty 作為高度可伸

縮的、異步的、事件驅動的網絡編程框架，完美

契合了自動化代理平臺對多服務器管理、快速響

應、異步調用的場景需要。

探索與應用

48

自動化代理平臺采用網關加二級代理的通信

方式，用戶側請求進入網關后動態(tài)路由到對應物

理機房的二級代理，再通過二級代理與服務器之

間的 Netty 連接進行進一步業(yè)務操作。同時 Netty

的連接信息通過注冊中心進行管理，并動態(tài)刷新

到網關，使得網關能將用戶請求正確路由到對應

二級代理。如圖 2 所示。

二級代理的方式解決不同物理機房間服務

器網絡不互通的安全需求，機房中使用 Netty 架

構構建二級代理和服務器的連接。基于 Netty 無

連接數據報套接字支持和相較 Java 核心 API 更

高的吞吐量以及更低的延遲，使得二級代理能同

時處理成千上萬的并發(fā)客戶端?？蛻舳藙?chuàng)建消息

處理的入站處理器流和出站處理器流，并向服

務端發(fā)起建聯請求。二級代理作為服務端創(chuàng)建

消息處理的入站處理器流和出站處理器流，并

通過 Channel 完成與客戶端的對接。在業(yè)務處理

時，二級代理通過目標索引獲取到對應服務器的

Channel，使用事件對服務器進行業(yè)務指令下發(fā)。

注冊中心用于統(tǒng)籌全局的服務器信息，作為

特殊的 Netty 客戶端與各物理機房的二級代理服

務端建連，實時同步服務器信息并將數據寫入本

地數據庫中。同時將二級代理與服務器之間的基

本信息存入緩存數據庫，并將該緩存數據與網關

實時共享。

自動化代理平臺為用戶提供 Restful 和 API

兩種類型的調用接口，Restful 接口主要用于操作

指令，如服務升級、信息采集等，API 接口提供

文件的上傳下載。Restful 接口進入網關后，網關

根據指令的服務器信息從緩存中匹配對應的二級

代理，并負載均衡的將請求路由到指定二級代理。

API 接口需要用戶系統(tǒng)導入自動化代理平臺為用

AgentRegister 主要有兩個作用，一是作為 Netty 客戶端的注冊中心，對 Netty 連接狀態(tài)進行監(jiān)控管理，

二是為網關層提供動態(tài)的 Netty 連接信息，是實現動態(tài)路由的關鍵。

（5）邏輯層

邏輯層包含特定于業(yè)務領域的邏輯，是最終進行業(yè)務操作的環(huán)節(jié)。各服務器通過 Netty 客戶端與服務

層建立連接，接收服務層請求并完成相應業(yè)務邏輯，對于耗費資源類操作部分通過服務層運算完成后再交

由邏輯層進一步處理，避免服務器負載過高影響其他交易系統(tǒng)的操作。

（6）數據層

數據層是操作數據（數據庫或者文本文件等）的操作層，為業(yè)務邏輯層或控制層提供數據服務。對于

使用頻率較低，數據量龐大的數據，例如審計信息、歷史數據等，使用關系型數據庫 MySQL 進行管理，

對于使用頻率較高，同時對使用場景的響應時間要求較為嚴格的關鍵數據，在存儲 MySQL 的同時還運用

到了緩存數據庫 Redis，一來提升數據查詢的響應速度，二來對 MySQL 進一步保護，避免出現緩存擊穿和

雪崩，三來提供分布式鎖，避免集群場景下的服務間狀態(tài)不感知導致的業(yè)務故障。

2.2 <=>7

自動化代理平臺技術選型為 Spring Cloud 微服務架構和 Netty 框架。

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)

基礎設施的開發(fā)，如服務發(fā)現注冊、配置中心、消息總線、負載均衡、斷路器、數據監(jiān)控等。Spring Cloud

作為一套成熟的分布式服務治理的框架，已得到了廣泛的應用。

Netty 是一款用于開發(fā)高性能網絡系統(tǒng)的 Java 框架，它封裝了網絡編程的復雜性，使得網絡編程更容

易的實現，同時 Netty 作為高度可伸縮的、異步的、事件驅動的網絡編程框架，完美契合了自動化代理平

臺對多服務器管理、快速響應、異步調用的場景需要。

自動化代理平臺采用網關加二級代理的通信方式，用戶側請求進入網關后動態(tài)路由到對應物理機房的

二級代理，再通過二級代理與服務器之間的 Netty 連接進行進一步業(yè)務操作。同時 Netty 的連接信息通過注

冊中心進行管理，并動態(tài)刷新到網關，使得網關能將用戶請求正確路由到對應二級代理。如下圖所示：

圖 2 自動化代理平臺架構圖

二級代理的方式解決不同物理機房間服務器網絡不互通的安全需求，機房中使用 Netty 架構構建二級

代理和服務器的連接?；?Netty 無連接數據報套接字支持和相較 Java 核心 API 更高的吞吐量以及更低的

延遲，使得二級代理能同時處理成千上萬的并發(fā)客戶端?？蛻舳藙?chuàng)建消息處理的入站處理器流和出站處理

器流，并向服務端發(fā)起建聯請求。二級代理作為服務端創(chuàng)建消息處理的入站處理器流和出站處理器流，并

通過 Channel 完成與客戶端的對接。在業(yè)務處理時，二級代理通過目標索引獲取到對應服務器的 Channel，

圖 2 ：自動化代理平臺架構圖 使用事件對服務器進行業(yè)務指令下發(fā)。

圖 3 自動化代理平臺消息流轉圖

注冊中心用于統(tǒng)籌全局的服務器信息，作為特殊的 Netty 客戶端與各物理機房的二級代理服務端建連，

實時同步服務器信息并將數據寫入本地數據庫中。同時將二級代理與服務器之間的基本信息存入緩存數據

庫，并將該緩存數據與網關實時共享。

自動化代理平臺為用戶提供Restful和API兩種類型的調用接口Restful接口主要用于操作指令如圖 3 ：自動化代理平臺消息流轉圖