主管 ：上海证券交易所

主办 ：上海证券交易所

总编 ：邱勇、蔡建春

副总编 ：王泊

执行总编 ：唐忆

责任编辑 ：徐广斌、徐丹、陆伟、王昕、黄淦

上海市杨高南路 388 号

邮编 ：200127

电话 ：021-68607129，021-68607131

传真 ：021-68813188

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

内部资料 2022 年第四期（总第 51 期）

准印证号 ：沪（K）0671

NO.4

交易技术前沿THE FORELAND OF TRADING TECHNOLOGY

资本市场在现代经济活动的重要作用日益凸显，交易系统作为资本市场运作和发展的直接承载体 ,

对于维护市场安全稳定高效运行发挥着至关重要的作用。开展交易系统核心技术研究 , 有利于行业机

构改良自身技术、降低运行风险 , 亦有利于促进我国资本市场国际竞争力和影响力的提升。本期《交

易技术前沿》以“交易系统”为主题，收录行业交易系统研究及前沿技术探索等方面的优秀文章，其中。

《异构交易系统介绍》展现了中金所自主研发异构交易平台的系统架构和技术亮点，该平台借鉴

了航空航天业在软件可靠性上的最佳实践，旨在降低交易系统故障率、提高容灾容错性。

《可复用数据处理框架在证券数据处理中的探索和实践》在主流的数据处理框架基础上，开发了

批处理系统的处理框架和元数据管理模式，在提高数据维护质量的同时降低数据血缘关系维护难度。

目前该开发模式已运用在创新业务和交易系统的实际研发中。

《海通证券兼容多基础平台的新一代核心交易系统运营管理平台设计与实现》采用全面自主可控

的链路技术，实现智能路由识别、统一路由管理，在保证平台兼容性的前提下，有效提升核心交易系

统运营管理效率并降低运营管理成本。

《机构交易接入中台建设实践》聚焦于屏蔽核心交易系统差异性的自主可控交易接入中台，为各

类交易终端接入 OST 极速交易系统、第三方快速交易系统等打下基础。

《基于证通云的数据跨境流动管理方案的研究与实现》旨在通过综合运用数据加密、权限控制、

操作留痕等技术手段，在现有政策环境下，提出一种基于“证通云”的数据跨境流动管理解决方案。

《交易技术前沿》编辑部

2023 年 3 月 23 日

篇首语

本期热点

探索与应用

1 异构交易系统介绍 / 应国力、仇沂、李雯、王维

2 海通证券兼容多基础平台的新一代核心交易系统运营管理平台设计与实现 / 霍轶伦、周尤珠、

陆颂华、王东、袁康

3 机构交易接入中台建设实践 / 胡长春、单兴邦、高春蕾、李沁、黄赛、何少锋

4 可复用数据处理框架在证券数据处理中的探索和实践 / 蔡文博、张舒、鲍倩倩、杜小静、胡红星

5 基于 oneAPI 的金融衍生品定价加速 / 马辉、邹经纬、白君洁、钟浪辉、韩大伟、黄琦、余洋洋、

李彪

4

11

17

24

34

目录

信息资讯采撷

监管科技全球追踪 98

6 证券运维系统自动化代理平台建设实践 / 肖钢、徐志彬、柴晨、王军、喻文强、张皓凌

7 基于上证云的数据跨境流动管理方案研究与实现 / 操浩东、刘政言、何雷

8 安信证券网络系统自动化运维平台建设实践 / 梁德汉、何洲星、武孟军

9 兴业证券应用性能监控系统建设思路、方法和实践 / 刘洋、石良生、杨洋

10 一种可扩展的多因素访问控制方法及实践 / 姜洪涛、宫珂、于慧

11 证券公司智慧营销与服务平台建设 / 潘建东、徐政钧、刘逸雄、谷航宇

12 证券行业网站智能数据搜索服务的研究与实践 / 季晓娟、王中澎、李炜、赵冬昊、王汉杰、李蓉

13 关于 ION GROUP 遭遇勒索病毒攻击事件的分析思考报告 / 张涛、卢雅哲、徐广斌、谢毅

45

51

57

71

79

85

91

94

本期热点

1 异构交易系统介绍

2 海通证券兼容多基础平台的新一代核心交易系统运营

管理平台设计与实现

3 机构交易接入中台建设实践

4 可复用数据处理框架在证券数据处理中的探索和实践

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

本期热点

异构交易系统介绍

应国力、仇沂、李雯、王维 / 上海金融期货信息技术有限公司 交易系统部 上海 200127

E-mail ：yinggl@cffex.com.cn

4

1、关键技术问题

如何提升软件可靠性 ：软件可靠性是软件质

量体系中最重要的衡量指标之一，根据软件可靠

性理论，缺陷是无法完全穷举罗列的，无法完全

避免。中金所已具备完备的硬件故障恢复体系，

应对软件故障也有较丰富的应对手段，如图 1 所

示，但面对其他软件逻辑缺陷或架构级别严重缺

近年来，在全球经济复苏疲软叠加疫情冲击的背景下，全球交易所核心系统稳定性

面临较大考验，软件故障频发。针对软件缺陷类故障无有效应对方式的现状，中国金融期

货交易所（以下简称为“中金所”）自主设计研发打造了异构交易系统，该系统是一套软

件架构与主交易相异的容错备系统，通过多版本容错技术、维护多个异构交易系统来降低

服务的整体故障率，在主交易系统发生严重软件缺陷、且已有的应急保障措施均失效的情

况下，可尝试快速接管，持续为市场提供基本的交易及行情服务。

!\"#$%&'(

应国力 1

，仇沂 1

，李雯 1

，王维 1

1上海金融期货信息技术有限公司 交易系统部 上海 200127

E-mail ：yinggl@cffex.com.cn

摘 要：近年来，在全球经济复苏疲软叠加疫情冲击的背景下，全球交易所核心系统稳定性面临较大考验，

软件故障频发。针对软件缺陷类故障无有效应对方式的现状，中国金融期货交易所（以下简称为“中金所”）

自主设计研发打造了异构交易系统，该系统是一套软件架构与主交易相异的容错备系统，通过多版本容错

技术、维护多个异构交易系统来降低服务的整体故障率，在主交易系统发生严重软件缺陷、且已有的应急

保障措施均失效的情况下，可尝试快速接管，持续为市场提供基本的交易及行情服务。

关键词：异构；交易系统；软件故障；业务连续性

1 )*+,-.

如何提升软件可靠性：软件可靠性是软件质量体系中最重要的衡量指标之一，根据软件可靠性理论，

缺陷是无法完全穷举罗列的，无法完全避免。中金所已具备完备的硬件故障恢复体系，应对软件故障也有

较丰富的应对手段，如图 1 所示，但面对其他软件逻辑缺陷或架构级别严重缺陷类故障仍缺乏解决方案。

运

维

类

事

故

基础设施类

事故

软件类事故

应用层

架构层

两套实时

监控软件

应急并行

排障环境

每15分钟

人工巡检

现场应急

处理小组

突发事件

应急预案

IT 灾难

恢复计划

业务持续

性计划

硬件单点

故障

硬件大面

积故障

软件单

指令故障

其他软件

逻辑缺陷

软件主备切换

硬件双机冗余

同城灾备切换

异地远备切换

应用自动避障

跳过1条致命指令

?

图 1 核心系统事故应急方案

极简架构下的高性能：交易核心系统对性能容量有着极致的要求。建设一套全新的系统需要较大资源

投入，一是研发阶段的成本投入，需要实现所有线上业务功能；二是运维阶段的成本投入，需要同时维护

两套线上系统。因此，在资源极简的前提下，如何实现高性能目标也是难点之一。

图 1 ：核心系统事故应急方案

交易技术前沿

5

陷类故障仍缺乏解决方案。

极简架构下的高性能 ：交易核心系统对性能

容量有着极致的要求。建设一套全新的系统需要

较大资源投入，一是研发阶段的成本投入，需要

实现所有线上业务功能 ；二是运维阶段的成本投

入，需要同时维护两套线上系统。因此，在资源

极简的前提下，如何实现高性能目标也是难点之

一。

切换影响最小化 ：当主系统发生软件故障切

换到异构交易系统时，需要尽可能降低内外部影

响。一方面是切换效率要高，对市场无影响，会

员端需要做到无感切换 ；另一方面是对交易所内

部上下游系统无影响，需要做到切换后周边各业

务系统持续平稳运行。

数据一致性：异构系统与主系统架构不一致，

存在业务不一致的风险，如何保证异构系统接管

后仍能正确运行不出错，也是关键之一。

“卡脖子”问题仍需攻关 ：面对严峻多变的

国际形势，提升交易所技术的安全自主可控性更

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

探索交易所核心系统在自主可控环境落地，才能

在面对不同局势时从容不迫。

2、异构交易系统架构介绍

异构交易系统内部异构于主交易系统，采用

了以高性能通信组件为连接件、多级交易流水线

为中心、内置查询业务和行情生成的架构，外部

复用了主系统前置和外围系统。异构交易系统总

体架构如图 2 所示。

高性能通信组件是中金所在多年来交易系统

研发的基础上，对底层开发框架及通用功能组件

进行分离封装，形成的一套功能丰富的开发框架。

开发框架由 C++ 实现，包含了事件处理框架、高

性能通信、可靠多播、高级容错组件等。

多级流水线模型是异构交易系统的消息处理

架构，异构于主交易的业务单线程处理，后续章

节中将详细介绍。

内置查询业务和行情生成是考虑到查询模

块和行情生成模块的轻量性及其与交易行为的耦

合，将这两个模块纳入异构交易系统核心进程中，

可降低异构系统运维的复杂度。

复用主交易前置和外围接口模块可以保证在

切换时省去反演恢复数据的时间，提高切换效率，

并且可维持切换后对外服务地址不变，降低切换

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

异构交易系统内部异构于主交易系统，采用了以高性能通信组件为连接件、多级交易流水线为中心、

内置查询业务和行情生成的架构，外部复用了主系统前置和外围系统。异构交易系统总体架构如图 2 所示：

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

上行流 行情流

结果流

主交易系

统

会员柜台系统

FibPro

xy

生产结果流

切换指令

初始化 上场

异构交易核心

行情生成

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

查询

交易流水线

查询请求

查询应答

图 2 异构交易系统架构

高性能通信组件是中金所在多年来交易系统研发的基础上，对底层开发框架及通用功能组件进行分离

封装，形成的一套功能丰富的开发框架。开发框架由 C++实现，包含了事件处理框架、高性能通信、可靠

多播、高级容错组件等。

图 2 ：异构交易系统架构

本期热点

6

对会员端及交易所内部上下游系统的影响。

从运行方式与数据流向上来看，异构交易系

统日常作备并行运行，实时订阅主系统撮合结果

流水，实时恢复最小完整状态集。当主交易系统

出现故障切换至异构交易系统时，开始订阅外部

前置及上场消息继续进行交易业务。

3、系统关键技术

3.1 运行模式及流水复制恢复技术

异构交易系统支持两种运行模式 ：撮合模式

和恢复模式。运行模式属于架构层的概念，它决

定了系统的订阅关系、流持久化逻辑等。详细介

绍如下 ：

撮合模式 ：异构交易系统做主系统运行，从

上场模块进行初始化，从交易前置接收外部指令

（如报单、报价等）。业务层进行撮合操作，撮合

结果直接写入结果流。此模式下与主系统运行模

式无异，当主系统故障切换至异构系统时，异构

系统以此模式运行。

恢复模式 ：异构交易系统作为备系统运行，

此时作为主系统的并行系统，将订阅主中心发来

的全量流。此模式下应用了流水复制恢复技术，

只处理结果消息，用来复制主中心的撮合结果，

恢复构建对应业务域状态、内存表以及相关变量

的状态，如资金占用、仓位统计、活跃订单簿等，

保证异构一致性。收到切换指令后，异构交易系

统会切换为主中心，发生订阅关系和业务层操作

模式的变化 ：取消订阅主中心结果流，转向订阅

上场模块消息，开始接收前置的外部消息，业务

层操作由流水复制恢复切换为撮合。线上运行默

认为此模式。

3.2 基于聚合根的多层领域模型

通过抽取基于交易参与者 + 合约的最细粒度

数据聚合根，将不同业务域数据按层级进行挂载，

实现数据访问的简化和高效率，对原主交易系统

的业务模型进行了完全的重构，通过异构避免严

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

全新的领域服务校验模型内部通过业务功

能、领域模型、内存数据三层进行划分，配合数

据聚合根，业务逻辑不再关心数据存取访问，模

型抽象程度更高。同时，领域服务不依赖外部系

统、不保存状态，所以更容易进行单元测试，这

对于提高系统的质量是非常有帮助的。

3.3 高性能多级流水线模型

异构交易系统的消息传递采用多级流水线模

型，将业务数据处理流程在逻辑上划分成相互独

立的若干部分，每个部分由一个线程驱动，线程

之间共享消息队列。

从总体业务模型的角度上来看，如图 3 所示，

相比于主交易系统的订阅 -> 单线程撮合 -> 发布

的结构，异构交易系统将撮合线程按延时占比拆

分为撮合前、撮合、撮合后三部分异步处理消息。

在同一测试环境进行测试，多级流水线性能

提升显著，具体如表 1 所示。引入撮合流水线后，

系统吞吐能力显著提升。由于架构上进行了本地

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

以内。

从技术模型实现来看，异构交易系统的业务

处理部分由四个线程驱动，分别为订阅消息加工

认为此模式。

3.2 :;<=>?@ABC2D

通过抽取基于交易参与者+合约的最细粒度数据聚合根，将不同业务域数据按层级进行挂载，实现数

据访问的简化和高效率，对原主交易系统的业务模型进行了完全的重构，通过异构避免严重故障，提升了

软件可靠性。

全新的领域服务校验模型内部通过业务功能、领域模型、内存数据三层进行划分，配合数据聚合根，

业务逻辑不再关心数据存取访问，模型抽象程度更高。同时，领域服务不依赖外部系统、不保存状态，所

以更容易进行单元测试，这对于提高系统的质量是非常有帮助的。

3.3 EFG@H56I2D

异构交易系统的消息传递采用多级流水线模型，将业务数据处理流程在逻辑上划分成相互独立的若干

部分，每个部分由一个线程驱动，线程之间共享消息队列。

从总体业务模型的角度上来看，如图 3 所示，相比于主交易系统的订阅->单线程撮合->发布的结构，

异构交易系统将撮合线程按延时占比拆分为撮合前、撮合、撮合后三部分异步处理消息。

订阅 撮合 发布 订

阅

撮

合

前

撮

合

撮

合

后

共享动态消息队列

发

布

图 3 交易系统多级流水线业务模型

在同一测试环境进行测试，多级流水线性能提升显著，具体如表 1 所示。引入撮合流水线后，系统吞

吐能力显著提升。由于架构上进行了本地持久化的原因，延时略微增加，但仍在合理范围以内。

表 1 异构交易性能比对表

系统处理延时吞吐能力图 3 ：交易系统多级流水线业务模型

交易技术前沿

7

线程、撮合前检查线程、撮合及撮合后处理线程、

发布消息处理线程，与图 4 中线程一一对应。其

中，订阅消息加工线程将异构交易上行的消息包

进行解包，生成消息队列的包头以及流水线的第

零级消息，消息队列包头是多个线程访问消息队

列的关键，控制着线程对同一个消息的读写权限，

第零级消息通常是上行数据包的原始数据，也就

是输入的请求包 ；撮合前检查线程消费消息队列

包头和第零级流水线的消息，同时生成第一级流

水线的消息 ；撮合及撮合后处理线程消费消息队

列包头和第零、一级流水线的消息，同时生成第

二级流水线的消息 ；发布消息处理线程消费消息

队列包头和第零、一、二级流水线的消息，并将

消息打包，提供给其他模块消费。消息队列保存

了每一级流水生成的消息，并维护了消息之间的

对应关系。

其中，动态消息队列是为了适配多级流水线

模型而设计的组件，它的生产消费模式与多级流

水线模型是紧耦合的。对于消息队列而言，订阅

消息加工线程是生产者，发布消息处理线程是消

费者，撮合前检查线程和撮合及撮合后处理线程

既是生产者又是消费者。

在动态消息队列中，消息头的结构至关重要，

对于一个原始请求消息及其在各级流水线中生成

的衍生消息，消息头记录了流水线的处理结果和

上一级处理该消息的流水线序号，各级流水线通

过消息头判断消息是否可读。动态消息队列内部

实现大致如图 5 所示。

3.4 架构极简及业务极简

在技术架构方面，异构交易系统主要用于应

急场景，因此在架构上剥离了分布式容错撮合集

群，仅保留订单、行情关键路径模块，构成最小

完整状态集，使得架构层代码减少 20%。

在业务架构方面，基于全新的抽象程度更高、

基于聚合根的领域服务业务模型，剥离了非必须

业务，仅保留交易业务最小集，去除了为扩展性

预留的以及未开启的业务功能，在确保业务延续

性的同时，保证了业务应用层的简化，精简了核

心计算逻辑。以不同的实现方式重构之后，实现

了相同的业务功能，业务代码行数减少 55%，减

少了开发成本。

在模块架构方面，对比主交易系统，考虑到

查询模块和行情生成模块的轻量性及其与交易行

7

订阅 撮合 发布 订

阅

撮

合

前

撮

合

撮

合

后

共享动态消息队列

发

布

图 3 交易系统多级流水线业务模型

在同一测试环境进行测试，多级流水线性能提升显著，具体如表 1 所示。引入撮合流水线后，系统吞

吐能力显著提升。由于架构上进行了本地持久化的原因，延时略微增加，但仍在合理范围以内。

表 1 异构交易性能比对表

系统 处理延时 吞吐能力

主交易系统 98us 7.1 万笔/秒

异构交易系统 110us 16.5 万笔/秒

从技术模型实现来看，异构交易系统的业务处理部分由四个线程驱动，分别为订阅消息加工线程、撮

合前检查线程、撮合及撮合后处理线程、发布消息处理线程，与图 4 中线程一一对应。其中，订阅消息加

工线程将异构交易上行的消息包进行解包，生成消息队列的包头以及流水线的第零级消息，消息队列包头

是多个线程访问消息队列的关键，控制着线程对同一个消息的读写权限，第零级消息通常是上行数据包的

原始数据，也就是输入的请求包；撮合前检查线程消费消息队列包头和第零级流水线的消息，同时生成第

一级流水线的消息；撮合及撮合后处理线程消费消息队列包头和第零、一级流水线的消息，同时生成第二

级流水线的消息；发布消息处理线程消费消息队列包头和第零、一、二级流水线的消息，并将消息打包，

提供给其他模块消费。消息队列保存了每一级流水生成的消息，并维护了消息之间的对应关系。

图 4 异构交易系统多级流水线运行架构

认为此模式。

3.2 :;<=>?@ABC2D

通过抽取基于交易参与者+合约的最细粒度数据聚合根，将不同业务域数据按层级进行挂载，实现数

据访问的简化和高效率，对原主交易系统的业务模型进行了完全的重构，通过异构避免严重故障，提升了

软件可靠性。

全新的领域服务校验模型内部通过业务功能、领域模型、内存数据三层进行划分，配合数据聚合根，

业务逻辑不再关心数据存取访问，模型抽象程度更高。同时，领域服务不依赖外部系统、不保存状态，所

以更容易进行单元测试，这对于提高系统的质量是非常有帮助的。

3.3 EFG@H56I2D

异构交易系统的消息传递采用多级流水线模型，将业务数据处理流程在逻辑上划分成相互独立的若干

部分，每个部分由一个线程驱动，线程之间共享消息队列。

从总体业务模型的角度上来看，如图 3 所示，相比于主交易系统的订阅->单线程撮合->发布的结构，

异构交易系统将撮合线程按延时占比拆分为撮合前、撮合、撮合后三部分异步处理消息。

订阅 撮合 发布 订

阅

撮

合

前

撮

合

撮

合

后

共享动态消息队列

发

布

图 3 交易系统多级流水线业务模型

在同一测试环境进行测试，多级流水线性能提升显著，具体如表 1 所示。引入撮合流水线后，系统吞

吐能力显著提升。由于架构上进行了本地持久化的原因，延时略微增加，但仍在合理范围以内。

表 1 异构交易性能比对表

系统 处理延时 吞吐能力

主交易系统 98us 7.1 万笔/秒

异构交易系统 110us 16.5 万笔/秒

从技术模型实现来看，异构交易系统的业务处理部分由四个线程驱动，分别为订阅消息加工线程、撮

合前检查线程、撮合及撮合后处理线程、发布消息处理线程，与图 4 中线程一一对应。其中，订阅消息加

工线程将异构交易上行的消息包进行解包，生成消息队列的包头以及流水线的第零级消息，消息队列包头

是多个线程访问消息队列的关键，控制着线程对同一个消息的读写权限，第零级消息通常是上行数据包的

原始数据，也就是输入的请求包；撮合前检查线程消费消息队列包头和第零级流水线的消息，同时生成第

一级流水线的消息；撮合及撮合后处理线程消费消息队列包头和第零、一级流水线的消息，同时生成第二

级流水线的消息；发布消息处理线程消费消息队列包头和第零、一、二级流水线的消息，并将消息打包，

提供给其他模块消费。消息队列保存了每一级流水生成的消息，并维护了消息之间的对应关系。

图 4 异构交易系统多级流水线运行架构

表 1 ：异构交易性能比对表

图 4 ：异构交易系统多级流水线运行架构

本期热点

8

为的耦合，将这两个模块纳入异构交易系统核心

进程中。除了复用的主交易前置及外围模块，异

构交易系统仅有一个进程，保证了异构交易系统

的轻量级和灵活性。

3.5 运维视图及故障根因分析系统

为了实现故障的快速发现和定位，在开发异

构交易系统的同时，交付了一套基于大数据、集成

了运维视图及故障根因分析系统的智能运维平台，

实时跟踪主交易系统及异构交易系统运行状态。

根因分析系统融合了 Logging+Tracing+Metrics 的监控设计理念，定义了异构交易系统健康

运行五大黄金指标 ：通讯量、错误率、资源饱和

度、进程状态、同步数据落差，通过数十个监控

子指标监控系统运行状况，运用 Splunk 搭建了运

维指标视图，所有指标均支持分钟粒度告警和回

溯，实现了事前监控、事中定位、事后回溯的全

时段功能。

指标监控报错监测到故障时，可通过根因自

动分析系统（图 6）查看故障根因，也可通过日

志全链路追踪，进行主系统的故障发现及定位，

大幅减少根因定位时间，快速为切换异构交易系

统决策提供辅助依据。同时，智能运维平台也支

持一键切换，切换至异构交易系统后同样可持续

监控异构系统作为主系统运行时的各项指标。

智能运维平台针对日常运维和特殊排障场景

提供了全面的运维方案和体系，减少了异构交易

系统的运维成本。

3.6 平滑切换

接口一致性 ：异构交易系统在设计开发中维

持对外 API 及对内上下游系统接口不变，使得切

换时会员端系统、所内上下游系统可持续平稳运

行。在故障切换时，对外会员无需任何操作，做

到会员端无感知。对内支持断点续传，保证了数

据一致性与完整性。在业务层面保证了平滑切换，

切换后的所支持的业务也维持不变。

业务一致性：异构交易系统以备模式运行时，

其中，动态消息队列是为了适配多级流水线模型而设计的组件，它的生产消费模式与多级流水线模型

是紧耦合的。对于消息队列而言，订阅消息加工线程是生产者，发布消息处理线程是消费者，撮合前检查

线程和撮合及撮合后处理线程既是生产者又是消费者。

在动态消息队列中，消息头的结构至关重要，对于一个原始请求消息及其在各级流水线中生成的衍生

消息，消息头记录了流水线的处理结果和上一级处理该消息的流水线序号，各级流水线通过消息头判断消

息是否可读。动态消息队列内部实现大致如图 5 所示。

图 5 动态消息队列实现结构

3.4 /\"JK4LMJK

在技术架构方面，异构交易系统主要用于应急场景，因此在架构上剥离了分布式容错撮合集群，仅保

留订单、行情关键路径模块，构成最小完整状态集，使得架构层代码减少 20%。

在业务架构方面，基于全新的抽象程度更高、基于聚合根的领域服务业务模型，剥离了非必须业务，

仅保留交易业务最小集，去除了为扩展性预留的以及未开启的业务功能，在确保业务延续性的同时，保证

了业务应用层的简化，精简了核心计算逻辑。以不同的实现方式重构之后，实现了相同的业务功能，业务

代码行数减少 55%，减少了开发成本。

在模块架构方面，对比主交易系统，考虑到查询模块和行情生成模块的轻量性及其与交易行为的耦合，

将这两个模块纳入异构交易系统核心进程中。除了复用的主交易前置及外围模块，异构交易系统仅有一个

进程，保证了异构交易系统的轻量级和灵活性。

3.5 0NOP4QR>STU%&

为了实现故障的快速发现和定位，在开发异构交易系统的同时，交付了一套基于大数据、集成了运维

视图及故障根因分析系统的智能运维平台，实时跟踪主交易系统及异构交易系统运行状态。

根因分析系统融合了 Logging+Tracing+Metrics 的监控设计理念，定义了异构交易系统健康运行五大黄

金指标：通讯量、错误率、资源饱和度、进程状态、同步数据落差，通过数十个监控子指标监控系统运行

状况，运用 Splunk 搭建了运维指标视图，所有指标均支持分钟粒度告警和回溯，实现了事前监控、事中定

图 5 ：动态消息队列实现结构

交易技术前沿

9

实时接收来自主系统的数据，并将数据进行重构，

使得异构交易系统的数据及状态与主系统保持一

致。以主模式运行时，为了保证重构结果的一致

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

比对，验证了异构交易系统在主模式下与主系统

业务功能结果完全一致。业务一致性保证了切换

后异构交易系统可平滑接管业务。

为了保证异构交易系统与主交易系统的业

务、行情的一致性，采用了两套同步一致性比对

方案 ：

一是实时接收主交易系统和异构交易系统恢

复模式下的撮合结果及行情流水，进行交易结果

数据、行情发布数据的业务比对稽核，确保在恢

复模式下主系统与异构系统的数据一致性 ；

二是在并行环境上部署了一套以撮合模式运

行的异构交易系统，实时接收主中心的请求消息

并进行撮合，将撮合及行情结果与主中心进行比

对。此系统仅用作撮合模式的结果比对，验证异

构系统撮合模式的正确性，不参与应急切换。

极速切换 ：异构交易系统复用主交易的交易

前置和行情前置，切换后核心与前置均无需进行

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

程和决策的时间，可以做到秒级切换，最大程度

保证业务连续性。

3.7 国产化自主可控

异构交易系统在设计阶段充分考虑跨平台

运行需求，在组件开发阶段严格在自主可控环境

进行测试验证，确保自主可控环境的可用性。在

基于 X86_64 架构、浪潮服务器、麒麟操作系统、

海光 CPU 的自主可控环境上，异构交易系统的

各项功能平稳运行、延时及吞吐的性能指标达标，

并在自主可控环境成功上线，平稳运行至今。

在功能方面，异构交易系统在自主可控环境

上累计执行回归测试用例 14 余万条，并通过了

近两年的生产流水反演比对测试 ；在性能方面，

对环境特性及参数进行了分析和调优，使得性能

提升了 8%，异构交易系统在自主可控环境中的

报单吞吐量为9万笔/秒，报单延时约为150微秒。

4、系统建设成效

提高交易所业务连续性保障能力。交易系统

是交易所核心竞争力的重要体现，是金融市场中

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

指标监控报错监测到故障时，可通过根因自动分析系统（图 6）查看故障根因，也可通过日志全链路

追踪，进行主系统的故障发现及定位，大幅减少根因定位时间，快速为切换异构交易系统决策提供辅助依

据。同时，智能运维平台也支持一键切换，切换至异构交易系统后同样可持续监控异构系统作为主系统运

行时的各项指标。

数据库（事件库，交易知识库，推导规则库，历史事件库）

EventMatch

事件匹配

事件

GenGraph

生成故障分析图谱

交易知识 图谱存储

EventAnalysis

根因推导

推导规则

② ④

时间序列数据库

③

LogParse

日志解析

EventShow

根因展示

⑤

智能运维交互终端

⑥

砸纬纫愿

LightCam ①

同步日志

告警

①

图 6 根因自动分析系统

智能运维平台针对日常运维和特殊排障场景提供了全面的运维方案和体系，减少了异构交易系统的运

维成本。

3.6 VWXY

接口一致性：异构交易系统在设计开发中维持对外 API 及对内上下游系统接口不变，使得切换时会员

端系统、所内上下游系统可持续平稳运行。在故障切换时，对外会员无需任何操作，做到会员端无感知。

对内支持断点续传，保证了数据一致性与完整性。在业务层面保证了平滑切换，切换后的所支持的业务也

维持不变。

业务一致性：异构交易系统以备模式运行时，实时接收来自主系统的数据，并将数据进行重构，使得

异构交易系统的数据及状态与主系统保持一致。以主模式运行时，为了保证重构结果的一致性，通过近年

的交易流水反演比对和同步一致性比对，验证了异构交易系统在主模式下与主系统业务功能结果完全一致。

业务一致性保证了切换后异构交易系统可平滑接管业务。

为了保证异构交易系统与主交易系统的业务、行情的一致性，采用了两套同步一致性比对方案：

一是实时接收主交易系统和异构交易系统恢复模式下的撮合结果及行情流水，进行交易结果数据、行

情发布数据的业务比对稽核，确保在恢复模式下主系统与异构系统的数据一致性；

二是在并行环境上部署了一套以撮合模式运行的异构交易系统，实时接收主中心的请求消息并进行撮

合，将撮合及行情结果与主中心进行比对。此系统仅用作撮合模式的结果比对，验证异构系统撮合模式的

正确性，不参与应急切换。

极速切换：异构交易系统复用主交易的交易前置和行情前置，切换后核心与前置均无需进行反演就可

直接进行交易，除去停止主交易核心进程和决策的时间，可以做到秒级切换，最大程度保证业务连续性。

3.7 Z[\\]^_`

异构交易系统在设计阶段充分考虑跨平台运行需求，在组件开发阶段严格在自主可控环境进行测试验

图 6 ：根因自动分析系统

本期热点

最为核心的交易基础设施。异构交易系统上线后，

可提高核心系统的整体可用性。在主系统可用性

为 99.999% 的情况下，主系统每年的宕机时间为

36 秒以下，而加入了异构交易系统后，在异构系

统本身可用性为 99%、异构率为 50% 的情况下，

根据计算，整体系统每年的宕机时间将下降为 18

秒，且随着异构率的上升，宕机时间还将继续减

少。异构交易系统的上线，有效提高了交易所的

业务连续性保障能力，降低了技术故障对市场的

冲击，在保障金融市场安全稳定运行方面起到重

要作用。

探索实践下一代核心系统。异构交易系统作

为具备主交易系统完备业务功能的异构系统和下

一代交易系统的原型，在简化了部分可靠性保障

机制的情况下，比照全面建设一套新系统再上线

的时间周期，异构交易系统在上线周期上大约可

缩短 60%。其在生产环境上的运行，绝大部分时

间在作备的场景下运行，既能作为主系统软件故

障时的应急补充，又能使其经历生产环境真实场

景的考验逐步迭代完善，大大降低了下一代系统

验证的成本。此外，异构交易系统中投入使用的

更先进的框架、组件、模型等不但可作为下一代

核心系统的技术底座，还可以在其他项目组中被

复用，也可为公司节省下一定软件研发费用，并

缩短研发周期。

核心系统自主可控环境落地。异构交易系统

在设计阶段充分考虑跨平台运行需求，在开发阶

段严格在自主可控环境进行测试验证，确保系统

在自主可控环境的可用性。在基于国产海光服务

器、麒麟操作系统的自主可控环境，异构交易系

统运行平稳、各项功能正常、延时及吞吐等性能

指标达标。异构交易系统在自主可控环境的成功

落地，实现了软件层硬件层双异构，提升了核心

系统在基础设施层的自主可控性。

5、总结与展望

本文对异构交易系统的技术难点、架构、关

键技术分别进行了介绍和阐述。异构交易系统在

大规模数据量、极低时延要求的应用场景下，可

实时接替主系统提供全量交易服务，大幅提升核

心系统的可靠性，降低由于软件故障导致系统性

风险发生的可能性。同时在自主可控环境中，维

持内部延时基本不变的前提下，相比非自主可控

环境撮合吞吐仍可提升 135%。

目前，异构交易系统已在生产环境顺利上线，

成功主备并行运行至今。同时，在测试演练方面，

先后组织了多次自主可控生产环境的会员切换演

练，在会员接入的情况下，成功从非自主可控主

核心系统切换至自主可控异构交易系统，业务持

续平稳运行。

未来随着中国金融市场的发展，各家交易所

的系统复杂性必然会不断上升，外部环境也趋更

加变幻莫测，“交易不断，数据不乱”的目标仍

会是重中之重，如何在软件层面建立完备的容错

机制就显得更加重要。异构交易系统将结合各家

交易所先进经验，持续探索优化，为金融市场稳

定运行作出贡献。

10

交易技术前沿

随着客户数量的增加，业务功能的完善，以及多节点的扩展需求，海通证券新一代

核心交易系统运营管理平台的统一路由模式应运而生。海通证券新一代核心交易系统的运

营管理平台链路技术创新，全面自主可控，适配多种基础平台及中间件。其采用了智能路

由识别、统一路由管理机制，并支持全节点汇总数据查询，具有高可扩展性、安全性、灵

活性的特征。

海通证券兼容多基础平台的新一代核

心交易系统运营管理平台设计与实现

霍轶伦、周尤珠、陆颂华、王东、袁康 / 海通证券股份有限公司

E-mail ：hyl13866@haitong.com

1、引言

在证券行业快速发展、金融科技广泛应用

的背景下，分布式系统逐渐成为了证券行业核心

交易业务的发展趋势，全球许多证券交易所和投

行机构都在使用分布式的平台和架构用以提高交

易系统的处理能力，降低交易系统响应时间。海

通证券新一代核心交易系统拥有上海和深圳两个

交易中心，多个分布式交易节点，因此其对于使

用一套运营管理平台运营维护多个分布式交易节

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

控的链路技术也是保障数据安全与网络安全的关

键。在这种情形下，海通证券新一代核心交易系

统急需一个统一的运营管理平台，实现用一套运

营管理平台统一路由分发，进行全节点客户交易

与运营管理，并对多个交易节点数据汇总查询的

功能。有效提升运营管理效率、降低运营管理成

本，满足统一平台运营管理多节点的市场需求。

并需要开发适配各种创新可控的应用服务器与中

间件，兼容多种创新浏览器及版本，高度保障网

11

本期热点

12

络安全、数据安全。

2、多技术平台兼容适配

目前证券公司交易系统的核心部件大多依赖

于外部供应厂商，自主选择余地较小。同时关键

领域的自主可控能力已经逐渐发展为行业可持续

发展的核心竞争力。海通证券的新一代核心交易

系统研发出一套自主可控、应用技术创新的核心

交易系统运营管理平台并成功投产运行。

2.1 采用海通统一研发平台

海通证券新一代核心交易系统的统一运营管

理平台采用海通证券统一的研发管理平台技术，

在开源框架 GUNSV6.0 的基础上开发集成，并整

合了海通管理类框架的技术优势。其基于主流的

前后端开发技术 Vue+SpringBoot，并拥有丰富的

UI 组件体系。研发平台提供统一的技术标准与

脚手架，封装通用技术能力，有效提高研发效率

和质量。

新一代核心交易系统的运营管理平台除支持

例如微服务框架、安全机制、链路监控、配置中

心等核心模块外，还拥有丰富的插件化架构体系，

使得在平台建设过程中可以自由组合各模块，实

现不同功能的结合与分离，从而更加便捷高效地

搭建可扩展的业务系统。整个运营管理平台采用

“基座 + 插件”的架构模式，“基座”保证整体框

架的稳定性、兼容性、连续性。“插件”用于扩

展整体框架的适配性，提高连通性、安全性，用

以快速响应客户需求。

整体运营管理平台架构规范、完善，并具有

较高的研发效率和研发质量，拥有更高的设计和

源码掌控能力。

2.2 兼容多个应用技术创新平台

海通证券新一代核心交易系统的统一运营管

理平台采用 B/S 架构，开放兼容多个应用技术创

新平台，并可以灵活进行平台之间的迁移。高度

保障网络安全、数据安全，搭建了稳固的自有生

态。

如图 2 所示，对于浏览器，其可兼容多种应

用技术创新浏览器，如 360 浏览器、奇安信可信

浏览器等，并适配支持浏览器的多个版本，保障

用户无感迁移使用。对于各种浏览器均能保证页

面显示兼容性、插件兼容性与代码兼容性。对于

应用中间件、Nginx 及缓存服务，其兼容东方通

的 tongWeb tongWeb、tongRDS tongRDS，及保兰德的 BES 等。对

于数据库，其适配 Oracle、达梦数据库、巨杉数

据库等数据独立存储的关系型数据库，也适配

MYSQL、GOLDENDB GOLDENDB、TiDB 等 分 布 式 数 据 库。 等 分 布 式 数 据 库。

对于操作系统，可适配诸如麒麟操作系统（基于

Hygon 芯片）、欧拉操作系统等面向企业级的通

N I?6789*+CDOPN

新一代核心交易系统的运营管理平台除支持例如微服务框架、安全机制、链路监控、配置中心等核心

模块外，还拥有丰富的插件化架构体系，使得在平台建设过程中可以自由组合各模块，实现不同功能的结

图 1 ：运营管理平台技术框架图

交易技术前沿

13

用服务器架构平台。

3、统一路由应用层设计与实现

随着我国证券交易市场的发展与完善，证券

交易业务愈发多样化、复杂化。为提升证券交易

这一核心业务的低时延、高可用、高扩展能力，

满足不同业务场景需要，海通证券新一代核心交

易系统采用了基于开放平台和消息总线的分布式

架构，支持各分布式节点灵活部署与水平扩展。

海通证券新一代核心交易系统拥有上海和深圳两

个交易中心，多个分布式交易节点，其对于统一

运营管理也提出了更高的技术要求。因此为了运

营维护多个分布式交易节点并支持后续节点高效

扩展的需求，海通证券新一代核心交易系统采用

了统一路由的策略进行路由识别与转发，实现一

个运营管理平台对多个分布式节点的运营管理。

3.1 运营管理平台统一路由功能实现

3.1.1 统一路由链路设计

如图 3 所示，运营管理平台由 WEB 服务、

统一路由微服务、公司级企业服务总线有机组成。

柜员从浏览器端发起访问请求，各个访问请求通

过 Nginx 反向代理发送至运营管理平台的统一路

由微服务，并根据系统节点、客户节点及指令节

点增加节点信息字段，将此信息发送至公司级企

业服务总线，并在此进行路由分发，各节点的数

据库变更内容实时采集同步至汇总数据库，用于

汇总数据查询。

适配 MYSQL、GOLDENDB、TiDB 等分布式数据库。对于操作系统，可适配诸如麒麟操作系统（基于 Hygon 芯

片）、欧拉操作系统等面向企业级的通用服务器架构平台。!

!

T?5.UVRKW:;<=>?

随着我国证券交易市场的发展与完善，证券交易业务愈发多样化、复杂化。为提升证券交易这一核心

业务的低时延、高可用、高扩展能力，满足不同业务场景需要，海通证券新一代核心交易系统采用了基于

开放平台和消息总线的分布式架构，支持各分布式节点灵活部署与水平扩展。海通证券新一代核心交易系

统拥有上海和深圳两个交易中心，多个分布式交易节点，其对于统一运营管理也提出了更高的技术要求。

因此为了运营维护多个分布式交易节点并支持后续节点高效扩展的需求，海通证券新一代核心交易系统采

用了统一路由的策略进行路由识别与转发，实现一个运营管理平台对多个分布式节点的运营管理。

XHI?6789*+5.UVYZ=>?

3.1.1 统一路由链路设计

如图 3 所示，运营管理平台由 WEB 服务、统一路由微服务、公司级企业服务总线有机组成。柜员从浏

览器端发起访问请求，各个访问请求通过 Nginx 反向代理发送至运营管理平台的统一路由微服务，并根据

系统节点、客户节点及指令节点增加节点信息字段，将此信息发送至公司级企业服务总线，并在此进行路

由分发，各节点的数据库变更内容实时采集同步至汇总数据库，用于汇总数据查询。

N X?6789*+[U

1）WEB 服务采用 Nginx 反向代理负载均衡

为提高系统并发处理能力，解决系统同一时间段接受到大量客户端请求的问题，采用 Nginx 反向代理

模式，将请求信息根据 Nginx 配置的服务器地址随机分发到负载均衡的微服务中进行处理，以保证更快的

响应和更好的用户体验。

2） 统一路由微服务解析客户端信息

图 3 ：运营管理平台链路

1）WEB 服务采用 Nginx 反向代理负载均衡

为提高系统并发处理能力，解决系统同一时

间段接受到大量客户端请求的问题，采用 Nginx

反向代理模式，将请求信息根据 Nginx 配置的服

务器地址随机分发到负载均衡的微服务中进行处

理，以保证更快的响应和更好的用户体验。

2） 统一路由微服务解析客户端信息

统一路由微服务是解析处理客户端请求并连

接公司级企业服务总线的信息转换器，其根据浏

览器请求中携带的系统节点、客户节点、指令节

点在消息的报头中添加代表节点信息的字段，并

能力。!

GHG?%&'QRKCDS-*+?

海通证券新一代核心交易系统的统一运营管理平台采用 B/S 架构，开放兼容多个应用技术创新平台，

并可以灵活进行平台之间的迁移。高度保障网络安全、数据安全，搭建了稳固的自有生态。

N G?%&'RKCDS-*+

如图 2 所示，对于浏览器，其可兼容多种应用技术创新浏览器，如 360 浏览器、奇安信可信浏览器等，

并适配支持浏览器的多个版本，保障用户无感迁移使用。对于各种浏览器均能保证页面显示兼容性、插件

兼容性与代码兼容性。对于应用中间件、Nginx 及缓存服务，其兼容东方通的 tongWeb、tongRDS，及保兰

德的 BES 等。对于数据库，其适配 Oracle、达梦数据库、巨杉数据库等数据独立存储的关系型数据库，也

图 2 ：兼容多应用技术创新平台

本期热点

14

将此信息发送至公司级企业服务总线。

3） 公司级企业服务总线分发多个分布式节点

公司级企业服务总线也称 ESB（Enterprise

Service Bus），主要负责对于消息进行路由节点分

发。根据沪深两个交易中心，ESB 设置了两个安

全集成平台（也称 DataPower），并为每一个交易

节点配置一个协议转换平台（也称 CpackPower）

进行消息分发。DataPower 根据请求中携带的节

点信息发至不同的 CpackPower，并将 HTTP 协议

转换为加密后的安全协议。

3.1.2 统一路由分发机制

如何正确反映客户端请求与各节点后台组件

之间的映射关系从而让请求发送至对应的系统节

点是成功实现多节点路由分发的关键，简洁可靠

的路由分发机制可以保障运营管理平台的路由安

全性与路由准确性。

1）节点信息映射

每一个节点的后台组件都有相应的系统编

号，在数据库中存在一个系统路由映射表，其

唯一确认并代表着网页端选择的系统节点和后台

组件系统编号的映射关系，根据此映射表，可以

准确获取前后台节点之间的对应关系。统一路由

微服务根据前台界面中选择的节点号在系统路由

映射表中获得此请求对应的后台组件节点号，并

为此 WEB 前端请求补充了代表后台节点信息的

route 字段。

2）路由分发中心

DataPower 作为公司级企业服务总线的关键

组成部分，其也是运营管理平台的节点路由分发

中心。节点路由分发中心的各子元素的节点名称

为统一路由微服务中的 route 字段值，子元素的

值则为对应节点适配器的负载均衡地址，该地址

指定请求所发往的后台组件系统，从而进行安全

可靠的路由分发。

3.2 统一路由技术亮点

3.2.1 动态扩展路由

新一代核心交易系统的运营管理平台支持在

系统路由界面动态扩展系统路由并实时生效，该

动态路由策略具备很好的可靠性和灵活性，为系

统灵活扩展的需求提供了有效的技术途径。

1）扩展可靠性

支持配置某个节点作为默认的系统路由，当

操作人员在界面既不选择操作的节点，也不选择

相应的客户号时，则选取此运营管理平台配置的

默认节点作为其发送的系统节点，进行请求数据

的分发，保证系统的可靠性。

2）配置灵活性

当需要新增或者减少系统节点时，仅需在系

统路由界面针对相应的节点配置或删除对应的系统

名称、系统编码、企业服务总线地址即可，支持横

向扩展配置，没有流量限制，可以任意配置多个节

点且能够及时生效，增强系统的灵活扩展性。

3.2.2 路由策略控制

新一代核心交易系统的路由策略主要可分为

节点级、客户级、指令级三个控制力度，分级可控。

1）节点级 ：对于每个系统节点可以在系统

路由中进行节点配置，选择是否为运营管理平台

的默认系统路由，同时也可以直接选择访问节点，

实现节点级别的路由控制。

2）客户级 ：根据客户号获取客户所属交易

节点 , 自动进行对应节点的请求发送，简化操作

人员的操作复杂度，无需进行节点的选择即可自

动控制路由配置进行请求的发送。

3）指令级 ：针对每一个不同的业务和交易，

运营管理平台都为其分配有对应的交易编码指令

号，对于每一个交易编码系统都支持配置其可发

送的路由节点，实现控制每条操作指令对应的系

统路由。

3.3 统一路由业务亮点

3.3.1 适配多种统一路由业务场景

新一代核心交易系统运营管理平台的统一路

由适配的业务场景主要分为以下几类，涵盖了全

交易技术前沿

15

部业务人员使用需求 ：

1）参数设置类 ：操作人员使用同一客户端

即可对于证券基本信息等参数设置业务指定需要

同时修改的相应节点，进行一次设置多节点分发

的参数设置模式。

2）查询类 ：查询类路由场景可分为客户类查

询和节点类查询。对于客户类查询，即操作人员

输入客户号后由系统自动识别客户所在节点，并

将查询请求发送至此客户所在节点进行针对此客

户的数据查询。节点类查询即操作人员指定系统

节点，对于此节点内的全部有权限数据进行查询。

3）交易类 ：操作人员输入客户号后系统即

可自动识别客户所在系统节点，并将此下单信息

发送至客户对应节点的后台组件进行交易类功

能。

4）清算管理类 ：运维人员在清算管理全流

程中灵活配置，对于多个节点统一管理，并清晰

记录操作日志，使得运维人员在一个清算管理模

块即可清晰直观地统一维护多节点清算管理步

骤。

3.3.2 降低运营管理复杂度，简化运维升级

流程

对于运营部门的参数管理岗位人员，其需要

对于全部分布式节点中的权限数据、基本信息等

参数进行维护。采用统一路由机制的运营管理平

台可以使得运营人员仅在一个平台进行设置即可

实时同步至多个交易节点后台，提升参数管理维

护的效率，及参数维护的安全性、一致性。

对于运维升级人员，原有的一套运营管理平

台对应一套分布式交易节点后台的模式需要对于

多个运营管理平台进行升级维护，耗时较大，维

护成本较高。统一路由的运营管理平台解决了此

运维痛点，同时其简化了整个运维升级流程，采

用配置中心模式，极大的缩减了运维升级时间，

提高了运维升级效率。

4、分布式节点数据汇总

分布式架构逐渐成为证券行业核心交易系统

的技术发展必然趋势，随着客户量的增加，业务

复杂度的增长，分布式节点也在快速水平扩展。

各节点的数据信息分散在各自节点的数据库中，

对于需要同时获取多节点信息的场景，在节点路

由分发的过程中，考虑到数据请求的全面性、实

时性，以及对于多交易节点请求的复杂度，其不

再适用各节点分别分发请求并对返回数据汇总的

方式。因此如何能够在同一套运营管理平台对于

全节点的客户数据、交易信息进行汇总查询是适

N ^?_`UVab

1）节点级：对于每个系统节点可以在系统路由中进行节点配置，选择是否为运营管理平台的默认系统

路由，同时也可以直接选择访问节点，实现节点级别的路由控制。

2）客户级：根据客户号获取客户所属交易节点,自动进行对应节点的请求发送，简化操作人员的操作

复杂度，无需进行节点的选择即可自动控制路由配置进行请求的发送。

3）指令级：针对每一个不同的业务和交易，运营管理平台都为其分配有对应的交易编码指令号，对于

每一个交易编码系统都支持配置其可发送的路由节点，实现控制每条操作指令对应的系统路由。

XHX?5.UVcd\\]?

3.3.1 适配多种统一路由业务场景

新一代核心交易系统运营管理平台的统一路由适配的业务场景主要分为以下几类，涵盖了全部业务人

员使用需求：

1）参数设置类：操作人员使用同一客户端即可对于证券基本信息等参数设置业务指定需要同时修改的

相应节点，进行一次设置多节点分发的参数设置模式。

2）查询类：查询类路由场景可分为客户类查询和节点类查询。对于客户类查询，即操作人员输入客户

号后由系统自动识别客户所在节点，并将查询请求发送至此客户所在节点进行针对此客户的数据查询。节

点类查询即操作人员指定系统节点，对于此节点内的全部有权限数据进行查询。

3）交易类：操作人员输入客户号后系统即可自动识别客户所在系统节点，并将此下单信息发送至客户

对应节点的后台组件进行交易类功能。

4）清算管理类：运维人员在清算管理全流程中灵活配置，对于多个节点统一管理，并清晰记录操作日

志，使得运维人员在一个清算管理模块即可清晰直观地统一维护多节点清算管理步骤。

3.3.2 降低运营管理复杂度，简化运维升级流程

对于运营部门的参数管理岗位人员，其需要对于全部分布式节点中的权限数据、基本信息等参数进行

维护。采用统一路由机制的运营管理平台可以使得运营人员仅在一个平台进行设置即可实时同步至多个交

易节点后台，提升参数管理维护的效率，及参数维护的安全性、一致性。

图 4 ：分级路由策略

本期热点

应分布式节点扩展的关键。为了解决此问题，海

通证券新一代核心交易系统的运营管理平台采用

了将各自节点数据实时同步更新至汇总数据库的

机制，有效提升汇总查询效率，保障查询的实时

性、全面性。

整个运维升级流程，采用配置中心模式，极大的缩减了运维升级时间，提高了运维升级效率。

fgh]ijkl?

布式架构逐渐成为证券行业核心交易系统的技术发展必然趋势，随着客户量的增加，业务复杂度的

分布式节点也在快速水平扩展。各节点的数据信息分散在各自节点的数据库中，对于需要同时获取

信息的场景，在节点路由分发的过程中，考虑到数据请求的全面性、实时性，以及对于多交易节点

复杂度，其不再适用各节点分别分发请求并对返回数据汇总的方式。因此如何能够在同一套运营管

对于全节点的客户数据、交易信息进行汇总查询是适应分布式节点扩展的关键。为了解决此问题，

券新一代核心交易系统的运营管理平台采用了将各自节点数据实时同步更新至汇总数据库的机制，

升汇总查询效率，保障查询的实时性、全面性。

N m?klijn

]oijn,=pqr?

个分布式节点的数据库都有主备机制，为不影响主库的正常使用，使用备数据库进行数据同步至汇

库节点。保证对于生产系统和网络影响最小化，同时在秒级水平进行数据同步，保证数据的实时性

性。

数据库不仅支持本地局域网数据同步，还支持跨广域网数据同步。同时其还支持增量同步，数据

输，减少网络带宽。

tgklij?

数据库除了包含各个节点备数据库同步过来的节点数据库对象集合，还有一个以各个数据库对象

构建的视图，根据不同数据表结构和业务含义将不同的表进行去重排序。采用视图的形式使得基

数据安全性得以保障，同时可以聚焦于特定的数据集合，增强逻辑数据的独立性。

图 5 ： 汇总数据库

4.1 节点备数据库的实时同步

每个分布式节点的数据库都有主备机制，为

不影响主库的正常使用，使用备数据库进行数据

同步至汇总数据库节点。保证对于生产系统和网

络影响最小化，同时在秒级水平进行数据同步，

保证数据的实时性和一致性。

汇总数据库不仅支持本地局域网数据同步，

还支持跨广域网数据同步。同时其还支持增量同

步，数据压缩传输，减少网络带宽。

4.2 视图形式汇总数据

汇总数据库除了包含各个节点备数据库同步

过来的节点数据库对象集合，还有一个以各个数

据库对象集合汇总构建的视图，根据不同数据表

结构和业务含义将不同的表进行去重排序。采用

视图的形式使得基表中的数据安全性得以保障，

同时可以聚焦于特定的数据集合，增强逻辑数据

的独立性。

4.3 汇总数据查询服务、盯市服务

汇总数据查询服务部署于汇总数据库的服务

器上，其作为一个特殊节点的后台组件，用以查

询汇总库中的数据。对于汇总类公共数据，操作

人员选择节点为汇总节点，即可将请求通过统一

路由微服务及企业级消息总线发送至汇总节点的

汇总数据查询服务，对于此汇总数据库内的全部

有权限数据进行查询。

盯市服务作为对于融资融券客户进行维保比

例监控的重要组件，其通过数据同步机制将汇总

数据库的数据实时同步至服务内的内存数据库中

进行实时计算并盯市监控，通过汇总数据库模式，

其可同时对于全部分布式节点的客户数据进行汇

总监控，更加高效便捷。

5、总结

本文首先介绍了基于分布式架构的海通证券

新一代核心交易系统运营管理平台建设的客观背

景，随后介绍了应用技术创新、多技术平台兼容

机制，统一路由的设计方案与具体实现，及分布

式节点数据汇总模式。运营管理平台采用了海通

统一的研发平台，并兼容多个应用技术创新平台，

整个链路技术创新，全面自主可控，保障数据与

网络安全。海通证券新一代核心交易系统采用分

布式架构，有效提高交易系统的处理能力，降低

交易系统响应时间。为适应多分布式节点的发展

需要，运营管理平台采用了统一路由分发模式，

其具有节点策略多样性、动态灵活扩展的特点，

同时符合业务功能使用的全部场景，降低了系统

运营维护成本。分布式节点的数据汇总模式有效

提升了系统的实时性、全面性，有效解决了多节

点统一查询汇总问题。以上是海通证券兼容多基

础平台的新一代核心交易系统运营管理平台建设

过程中的实践总结，希望能给业内同行提供一点

参考与借鉴。

16

交易技术前沿

17

随着东方证券机构交易服务的深入发展和东方雨燕极速交易系统的日趋完善，为支

持各类机构交易终端以非极速的方式接入到东方雨燕极速交易系统、集中交易系统、新一

代业务核心系统、及其他第三方快速交易系统，并支持客户在不同交易系统中切换，以及

为构建机构交易生态圈打好基础，需要建设屏蔽核心交易系统差异性的自主可控的机构交

易接入中台。本文将重点介绍东方证券机构交易接入中台系统建设方案和实践经验。

机构交易接入中台建设实践

胡长春、单兴邦、高春蕾、李沁、黄赛、何少锋 / 东方证券股份有限公司 系统运行总部 上海 200010

E-mail ：huchangchun@orientsec.com.cn

1、引言

由东方证券和东证期货联合自主研发的东方

雨燕 OST 极速交易系统上线平稳运行，大量对交

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

交易型客户、量化社区客户、银行 / 保险 / 公募 /

期货等持牌机构量化业务客户通过类 CTP 的 API

接口对接进行证券交易，日均交易量百亿规模。

随着东方证券机构交易生态圈逐渐完善以及 OST

极速交易系统在量化客户中口碑稳步提升，除极

速量化客户外，越来越多高净值客户及活跃交易

型客户均希望通过原有机构交易终端在 OST 极速

交易系统中进行交易。其次为夯实财富管理业务

基石，快速响应公司财富管理业务转型发展需要，

提升公司核心业务系统的连续服务能力，保障安

全稳定，东方证券开始构建统一技术架构的新一

本期热点

18

代核心业务系统逐步替换原有集中交易系统。另

外为进一步落实以量化交易为重点的机构经纪业

务的定位，为客户提供从策略生成到交易执行、

软硬件配置等一系列优化支持服务，在量化交易

领域中的保持领先优势，满足特定客户需求可能

会进一步引入 FPGA 极速交易系统。

为支持机构交易终端接入 OST 极速交易系

统、集中交易系统、新一代核心业务系统、以及

可能后续可能引入的 FPGA 极速交易系统等第三

方快速交易系统，机构交易接入中台兼容不同交

易系统接口协议，为机构交易终端提供统一接入，

屏蔽后台复杂性和差异性。机构交易终端对接中

台后，客户在不同交易系统切换，机构交易终端

系统无需重新对接开发，通过验收测试后即可投

入生产，极大提高机构交易终端接入效率。

2、背景

2.1 交易系统

2.1.1 普通交易系统

普通交易系统即集中交易系统为证券公司的

核心业务系统，定位于面向所有普通客户进行全

部场内和部分场外交易。系统实现的目标是稳定、

容量大并支持全业务，技术上主要基于传统的关

系型数据库模式，交易延时较高，并发有一定限制。

2.1.2 快速交易系统

快速交易系统目标客户为有快速交易需求的

量化客户 ；系统通常追求高性能、高可靠性、容

量可扩展，并支持场内大部分业务 ；技术上主要

采用内存交易技术，部分采用硬件加速机制。为

满足客户上海深圳报盘极致速度的要求，通常支

持灵活的双节点，在上海和深圳分别部署，支持

同一投资者的两个证券账户两地就近报盘。

2.2 客户交易渠道

2.2.1 普通散户

客户通过互联网使用手机 APP、网上交易

PC 终端如同花顺、通达信等接入普通交易系统

进行场内和场外交易。客户对交易速度不敏感，

由于通过纯手工操作，对百毫秒级别的延迟感知

不明显。

2.2.2 极速量化客户

极速量化客户通常托管系统对接快速交易系

统进行场内竞价交易。托管系统主要指极速量化

客户自建的一套系统，该系统通过 API 对接证券

公司快速交易系统，并由证券公司向客户购买后

部署在证券公司机房，仅提供给该客户使用。客

户对交易速度非常敏感，毫秒级延迟可能影响程

序化交易的收益，通常追求微秒级延迟。客户除

主要通过托管系统进行交易外，通常还需要一套

备用机构交易终端，满足客户除托管系统交易外

的全业务交易需求。

2.2.3 机构交易终端客户

机构交易终端客户指通过机构交易终端进行

交易的客户，主要包括使用 PB 交易终端，如迅

投 PB、恒生 PB 客户、卡方、宇量策略平台，和

机构 PC 交易终端，如同花顺机构版、通达信机

构版、日内快速交易终端等的客户。机构交易终

端客户中的交易型客户通常对交易速度较敏感，

通常追求毫秒级延迟，将客户从普通交易系统迁

移至快速交易系统，能提升客户交易体验。

3、方案

3.1 总体方案

机构交易接入中台核心需求为提供成熟的、

符合竞价交易速度、稳定性、连续性要求的统一

入口，承载机构交易统一协议，实现路由控制、

负载均衡、安全控制、流量控制、访问控制、运

维支持等功能。

中台基于多套交易系统提供的接口协议定

义机构交易统一协议，实现 C++、Java、Python

语言的 API 封装机构交易统一协议 ；基于开源

Netty 开发实现 API 网关支持机构交易终端系统

交易技术前沿

19

接入，通过会话管控保证安全和访问控制并通过

gRPC 协议实现 API 网关与交易系统适配模块之

间内部通讯 ；并基于微服务 gRPC 框架实现交易

系统适配模块，负责将机构交易统一协议适配转

换为各种交易系统的接口协议。另外为简化系统

复杂度并提高系统可用性，引入开源 Nginx 服务

器提供具体路由控制、负载均衡、流量控制能力；

为支持主推送方式接入，引入开源 Kafka 消息中

间件存储回报消息，由 API 网关通过订阅 Kafka

获取和缓存回报消息并通过 TCP 协议推送至机构

交易终端。

3.2 API 与 gRPC 选择

关于机构交易终端系统接入方式，支持类

CTP API 方式还是采用公司业务中台广泛推广的

gRPC 接口，在比较 API 方式和 gRPC 接口的特

点后，考虑到主流 PB 交易终端系统的对接习惯，

以及 gRPC 接口在支持互联网接入情况下可能遭

遇非法终端接入的风险，最终选择支持 API 方式。

3.3 API 网关请求处理过程

为减少中心节点 API 网关的复杂度，提高系

统稳定性，API 网关采用基于机构交易统一协议

<=3.1 >?<=

机构交易接入中台核心需求为提供成熟的、符合竞价交易速度、稳定性、连续性要求的统一入口，

承载机构交易统一协议，实现路由控制、负载均衡、安全控制、流量控制、访问控制、运维支持等功能。

图 1 机构交易接入中台总体架构图

中台基于多套交易系统提供的接口协议定义机构交易统一协议，实现 C++、Java、Python 语言的 API

封装机构交易统一协议；基于开源 Netty 开发实现 API 网关支持机构交易终端系统接入，通过会话管控保

证安全和访问控制并通过 gRPC 协议实现 API 网关与交易系统适配模块之间内部通讯；并基于微服务

gRPC 框架实现交易系统适配模块，负责将机构交易统一协议适配转换为各种交易系统的接口协议。另外

为简化系统复杂度并提高系统可用性，引入开源 Nginx 服务器提供具体路由控制、负载均衡、流量控制能

力；为支持主推送方式接入，引入开源 Kafka 消息中间件存储回报消息，由 API 网关通过订阅 Kafka 获取

和缓存回报消息并通过 TCP 协议推送至机构交易终端。

图 1 ： 机构交易接入中台总体架构图

3.2 API @ gRPC AB

关于机构交易终端系统接入方式，支持类 CTP API 方式还是采用公司业务中台广泛推广的 gRPC 接

口，在比较 API 方式和 gRPC 接口的特点后，考虑到主流 PB 交易终端系统的对接习惯，以及 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 开发 需定制开发 无需 API 开发，仅提供接口文档，可通过工具自动生成

客户端 API

通讯特点 通过 TCP 长连接通讯，委托、回报时延低 采用 HTTP2 通讯，gRPC 协议相对 TCP 协议复杂，委

托、回报时延相对较高

适用场景 符合主流 PB 交易终端系统对接习惯 微服务架构，无需维护连接，无会话状态，容易横向扩

展

3.3 API CDEFGHIJ

为减少中心节点 API 网关的复杂度，提高系统稳定性，API 网关采用基于机构交易统一协议的 gRPC

接交系统模块机构交统协交系统接协的转换交系统模块完表 1 ：API 方式与 gRPC 接口对比

本期热点

的 gRPC 接口调用交易系统适配模块，机构交易

统一协议和交易系统接口协议的适配转换由交易

系统适配模块完成，API 网关负责解析通讯报文、

校验报文入参、校验会话、并根据业务功能、客户、

请求参数确定路由信息，转发请求和处理响应。

3.4 API 网关设计

API 网关主要内容包括 API 消息协议、API

网关初始化、会话管理、路由管理、订阅推送等

功能。

API 消息协议 TCP 报文内容结构包括消息

头、消息体、校验位三部分。消息头包括请求类

型、请求编号、业务消息长度、压缩标志、最后

报文标志、API版本等内容；消息体包括业务消息；

校验位为检查报文内容有效性。

API 网关启动初始化过程中，从管理数据库

获取资金账户白名单、以及关联的 IP、MAC 信息，

并通过调用交易系统适配模块 gRPC 服务获取各

交易系统节点支持的资金账户和市场。

机构交易终端在与 API 网关建立 TCP 连接

后，调用登录接口认证建立会话。建立会话过程

主要包括资金账户白名单、终端 IP、MAC 信息

校验，以及交易密码校验，校验通过后建立会话。

API 网关管理会话相关的 TCP 连接、资金账户、

消息订阅状态、终端信息等信息。在 TCP 连接断

开时，API 网关注销会话并清理会话相关内容。

API 网关根据请求资金账户和市场代码，确定

客户竞价交易相关请求对应的交易系统节点。针对

图 2 API 网关请求处理过程

3.4 API CD*K

API 网关主要内容包括 API 消息协议、API 网关初始化、会话管理、路由管理、订阅推送等功能。

API消息协议TCP报文内容结构包括消息头消息体校验位三部分消息头包括请求类型请求图 2 ：API 网关请求处理过程

20

交易技术前沿

快速交易系统不支持的业务，确定客户对应的普通

交易系统。通过在发往 Nginx 服务器的 gRPC 请求

元数据中加入交易系统类型信息，由 Nginx 服务器

将请求转发至对应交易系统适配模块。

3.5 交易系统适配模块

东方证券制定了企业技术架构向以微服务为

核心的现代化架构转型并选择了具有跨语言特性

的 gRPC 为核心框架，并在其基础之上新增服务

治理特性和星辰服务治理平台，优化改进服务质

量。综合考虑 gRPC 协议多路复用、高效编解码

方式、框架成熟度以及复用公司服务治理平台提

供的监控和告警等功能，交易系统适配模块采用

gRPC 接口方式实现机构交易统一协议，供 API

网关内部调用。基于机构交易统一协议，快速交

易系统适配模块提供给其支持的竞价交易相关的

接口，普通交易系统适配模块基本涵盖机构交易

统一协议定义的全部接口。

在引入新交易系统的情况下，通过新增交易

系统适配模块，并在 API 网关和 Nginx 调整路由

配置，即可支持原有机构交易终端接入新的交易

系统。

4、实践

4.1 统一协议

不同系统对于新股申购、ETF 申赎等业务功

能接口提供方式，资金账户、市场代码等业务字

段命名，委托市价、信用交易相关参数的组成，

市场代码、委托状态字段取值均可能不同。

机构交易统一协议主要以快速交易系统提供

的接口为基础，补充机构交易终端支持客户全业

务交易时所需证券交易接口。其中针对普通账户，

支持普通买卖、ETF 申赎、国债逆回购、新股申

购、配股配债、转股回售、港股通业务 ；针对信

用账户，提供担保品买卖、信用交易、非交易委托、

新股申购业务 ；针对股票期权账户，提供买入开

仓、卖出平仓、卖出开仓、买入平仓、备兑开仓、

备兑平仓等业务。

机构交易统一协议主要包括接口清单、接口

出入参字段、字典字段取值三部分内容。机构交

易统一协议接口 73 个，其中同时支持普通账户、

信用账户、期权账户的接口 27 个 ；同时支持普

通账户、信用账户的接口 37 个 ；接口出入参字

段 413 个，其中浮点型字段 170 个，字符类型

114 个，整型字段 76 个，长整型字段 53 个，入

参字段 131 个 ；字典字段 41 个，包括委托状态、

委托方式、委托属性、市场代码等。

4.2 全业务支持

由于快速交易系统主要支持竞价交易业务如

普通买卖、ETF 申赎、国债逆回购、信用交易、

股票期权交易等，而对速度要求不高的业务如新

股申购、配股配债、转股回售、港股通业务由普

通交易系统支持。统一协议中将委托接口主要拆

分为竞价委托和普通交易系统委托。

关于竞价委托，API 网关根据客户竞价交易

所在的交易系统，将请求转发至对应的交易系统

适配模块。而针对有的交易系统的竞价委托业务，

如市价委托、限价委托、ETF 申购、ETF 赎回，

由不同的接口支持，交易系统适配模块根据统一

协议确定请求具体业务类型，完成接口字段和字

典字段的适配，调用交易系统对应的 API。

关于普通交易系统委托，由于部分快速交易

系统也支持如新股申购、配股配债、转股等业务，

API 网关根据统一协议中普通交易系统委托的委托

属性判断业务类型，并根据客户该业务所在的交

易系统，将请求转发至对应的交易系统适配模块。

4.3 双节点客户支持

对于沪市深市证券账户分别在上海和深圳快

速交易系统节点的客户，称为双节点客户。通常

为追求报盘极致速度，这类客户通过托管系统进

行交易。部分交易型的机构交易终端客户也为双

21

本期热点

节点客户。针对双节点客户交易、资金、持仓、

委托流水、成交流水在不同交易系统节点的情况，

传统的方案是机构交易终端系统连接两个不同交

易系统地址，分别进行对应市场的交易，客户需

选择对应的地址或账号进行登录。

中台通过 API 网关路由和对查询结果进行合

并汇总，实现单点接入的方式支持双节点客户。

对于客户的资金、持仓、委托流水、成交流水在

不同节点的情况，API 网关分别将请求转发至对

应交易系统节点，并将查询结果进行合并汇总。

对于交易类请求，API 网关根据入参中市场代码，

将请求转发该市场对应交易系统节点。为兼容传

统方案，API 网关通过侦听不同的端口分别表示

对应上海、深圳、全市场交易系统节点。如果终

端系统连接上海或深圳交易系统节点对应的端

口，则 API 网关则将请求转发至对应交易系统节

点，不进行双节点消息的合并汇总处理。

4.4 消息订阅

为支持主推送模式接入，避免机构交易终端

定时查询的消息延迟，中台支持消息订阅，当委

托状态发生变化或有成交产生时，主动推送消息

到机构交易终端。通常机构交易终端系统启动时

以“从本交易日开始重传消息”的订阅模式接收

全量消息，在发生网络异常情况下以“从上次收

到点续传消息”的订阅模式接收后续消息，部分

不需要全量消息的机构交易终端，以“只传送订

阅后的消息”的订阅模式接收当时间节点后产生

的消息。

交易系统适配模块根据各自交易系统对于委

托状态和成交回报推送的方案，获取当日推送消

息并转换为机构交易统一协议定义的委托状态和

成交回报消息，存储到 Kafka 消息中间件。对于

不支持消息推送的交易系统，交易系统适配模块

定时增量查询获取并存储数据。

API 网关从 Kafka 消息中间件订阅数据进行必

要转换后在内存中按照客户缓存消息队列，并维

护会话中客户消息订阅请求和当前推送序号等状

态，在有后续消息达到内存消息队列时通过会话

的通讯通道主动推送消息到机构交易终端系统。

4.5 基于订阅消息提供查询

由于快速交易系统通过基于内存交易技术，

大量查询请求可能影响快速交易系统交易性能。

中台基于缓存的消息队列，提供委托查询和成交

查询，避免委托查询和成交查询请求透传至快速

交易系统。

对于成交查询，成交回报消息即为成交明细

消息。API 网关维护客户、消息定位串到成交回报

消息的映射关系，其中消息定位串以跳表的数据

结构组织，支持基于消息定位串入参的增量查询。

对于委托查询，每笔委托的最新委托状态消

息即为该笔委托的查询结果。API 网关维护客户、

消息定位串到委托状态消息的映射关系，并在委

托的最新消息到达时，更新映射关系。

基于缓存消息提供的查询接口，在查询性能

和并发支持方面有数量级提升。

4.6 委托引用

机构交易终端收到委托状态消息时，通常使

用委托状态消息的委托引用关联原委托。由于部

分交易系统对委托引用取值规则进行限定或者定

义类型不一致，不能返回机构交易终端委托的委

托引用。中台将委托引用定义为长整型字段，对

于支持长整型委托引用的交易系统，中台采取透

传方式；对于不支持长整型委托引用的交易系统，

中台维护委托引用和委托的关系，并在委托查询

结果和委托状态消息推送中补充委托引用字段。

中台在向交易系统转发委托请求前，在内存

维护委托引用和委托的关系，并通过 Kafka 消息

中间件存储和共享全量映射关系。在查询委托消

息或收到交易系统委托状态消息推送时，中台根

据映射关系填充委托引用字段。由于部分映射关

系是通过 Kafka 共享，极端情况可能发生存在先

22

交易技术前沿

收到委托状态消息而后获取映射关系的情况，为

保障推送客户消息的顺序性以及委托引用原值返

回，中台采用更新委托引用和回填委托引用两部

分。在更新委托引用阶段，如果未获取委托引用，

则等待若干毫秒后重试，直至超过允许处理的时

间，在该阶段该委托所属客户的其他消息也均暂

时阻塞，以保证消息的顺序性。回填阶段是指在

允许处理的时间内，未更新委托引用的消息，被

会记录并定时检查根据获取的映射关系进行回填。

4.7 算法交易

中台提供算法交易接口支持机构交易终端算

法交易，机构交易终端系统登录中台后其算法单的

母单子单处理流程如图，机构交易终端系统通过子

单的委托引用与母单委托编号一致匹配母单字单。

5、总结与展望

目前机构交易接入中台已投入生产使用，已

支持一套 PC 交易终端直接从互联网访问和一套

PB 交易终端 , 日均交易量约数千万。中台在测试

环境已支持 3 套交易系统的沪深 A 股普通交易、

沪深 A 股两融交易、港股通、ETF 申赎、期权业

务接入，并完成多家 PB 交易终端接入的联调测

试工作，随着联调测试继续推进，机构交易接入

中台将进一步完善。预计在东方证券完成新一代

核心业务系统切换时，机构交易终端系统均通过

中台接入交易系统，日均交易量约为数十亿。

由于快速交易系统通过基于内存交易技术，大量查询请求可能影响快速交易系统交易性能。中台基

于缓存的消息队列，提供委托查询和成交查询，避免委托查询和成交查询请求透传至快速交易系统。

对于成交查询，成交回报消息即为成交明细消息。API 网关维护客户、消息定位串到成交回报消息

的映射关系，其中消息定位串以跳表的数据结构组织，支持基于消息定位串入参的增量查询。

对于委托查询，每笔委托的最新委托状态消息即为该笔委托的查询结果。API 网关维护客户、消息

定位串到委托状态消息的映射关系，并在委托的最新消息到达时，更新映射关系。

基于缓存消息提供的查询接口，在查询性能和并发支持方面有数量级提升。

表 2 单笔查询平均耗时比较

记录条数

查询方式 1 100 1w 10w 100w

透传至交易系统 7.52ms 43.21ms 1.58s 12.08s 不支持

基于缓存消息查询 1.29ms 4.46ms 110ms 737ms 6.94s

4.6 fg0h

机构交易终端收到委托状态消息时，通常使用委托状态消息的委托引用关联原委托。由于部分交易

系统对委托引用取值规则进行限定或者定义类型不一致，不能返回机构交易终端委托的委托引用。中台将

委托引用定义为长整型字段，对于支持长整型委托引用的交易系统，中台采取透传方式；对于不支持长整

型委托引用的交易系统，中台维护委托引用和委托的关系，并在委托查询结果和委托状态消息推送中补充

委托引用字段。

中台在向交易系统转发委托请求前，在内存维护委托引用和委托的关系，并通过 Kafka 消息中间件

存储和共享全量映射关系。在查询委托消息或收到交易系统委托状态消息推送时，中台根据映射关系填充

委托引用字段。由于部分映射关系是通过 Kafka 共享，极端情况可能发生存在先收到委托状态消息而后获

表 2 ：单笔查询平均耗时比较

23

取映射关系的情况，为保障推送客户消息的顺序性以及委托引用原值返回，中台采用更新委托引用和回填

委托引用两部分。在更新委托引用阶段，如果未获取委托引用，则等待若干毫秒后重试，直至超过允许处

理的时间，在该阶段该委托所属客户的其他消息也均暂时阻塞，以保证消息的顺序性。回填阶段是指在允

许处理的时间内，未更新委托引用的消息，被会记录并定时检查根据获取的映射关系进行回填。

4.7 ij#$

中台提供算法交易接口支持机构交易终端算法交易，机构交易终端系统登录中台后其算法单的母单

子单处理流程如图，机构交易终端系统通过子单的委托引用与母单委托编号一致匹配母单字单。

图 3 算法交易处理流程

k/ >l@mn目前机构交易接入中台已投入生产使用，已支持一套 PC 交易终端直接从互联网访问和一套 PB 交易

终端,日均交易量约数千万。中台在测试环境已支持 3 套交易系统的沪深 A 股普通交易、沪深 A 股两融交

易、港股通、ETF 申赎、期权业务接入，并完成多家 PB 交易终端接入的联调测试工作，随着联调测试继续

推进，机构交易接入中台将进一步完善。预计在东方证券完成新一代核心业务系统切换时，机构交易终端

系统均通过中台接入交易系统，日均交易量约为数十亿。

opqr-

[1] 微服务框架 gRPC 交易接入网关实践 https://mp.weixin.qq.com/s/-PK26QNJy2t9p4TCTf2dEw

[2] 东方证券服务治理建设实践 https://mp.weixin.qq.com/s/igX11UL_cbLh-UrpjK-BQg

[3] 新一代证券交易系统应用架构的研究 https://mp.weixin.qq.com/s/SAvXEkaF0ck7XXApGYgk2A

企业级证券业务中台探索与实践图 3 ：算法交易处理流程

参考文献 ：

[1] 微服务框架 gRPC 交易接入网关实践 https://mp.weixin.qq.com/s/-PK26QNJy2t9p4TCTf2dEw

[2] 东方证券服务治理建设实践 https://mp.weixin.qq.com/s/igX11UL_cbLh-UrpjK-BQg

[3] 新一代证券交易系统应用架构的研究 https://mp.weixin.qq.com/s/SAvXEkaF0ck7XXApGYgk2A

[4] 企业级证券业务中台探索与实践 https://mp.weixin.qq.com/s/1RL6iSHU7t8R-COk1i7kJQ

本期热点

24

随着上交所批处理系统承接的业务越来越多，为了应对业务响应及时性、数据维护

质量和系统运行效率等方面的挑战，上交所技术在借鉴主流数据处理框架优秀设计的基础

上，结合自身系统特性，以提高代码复用度为目标，开发了一套轻量级的 C++ 数据处理

框架，并且结合元数据管理，在提高数据维护质量的同时降低了数据血缘关系维护难度。

本文从批处理系统面临的实际挑战出发，通过分析 Spark 等系统的优势以及自身需求，

设计和开发了批处理系统的数据处理框架和元数据管理模式。目前，新开发模式已投入在

创新业务及交易系统升级建设的研发工作中。

可复用数据处理框架

在证券数据处理中的探索和实践

蔡文博、张舒、鲍倩倩、杜小静、胡红星 / 上交所技术有限责任公司 技术开发总部 上海 200120

E-mail ：wbcai@sse.com.cn

1、背景和挑战

上交所批处理系统作为核心交易系统数据加

工及处理的重要模块，主要承担着交易后清结算

处理和基础数据维护两大功能。随着创新业务不

断发展及交易系统技术持续升级，对批处理系统

在业务响应及时性、数据维护质量、系统运行高

效等方面提出了更高的要求。现有的批处理系统

已表现出诸多不足，主要问题有 ：一是研发效率

不高，虽然使用了相对高效易用的基础库，但业

务应用抽象程度低，代码复用程度低，进而导致

创新业务需求响应能力差 ；二是缺乏统一的数据

标准，目前各接口独立定义字段，导致定义工作

重复、同一字段在不同接口命名不一致，增加系

统维护成本，降低数据整体质量 ；三是数据血缘

关系维护难度大，随着批处理系统承载的业务越

交易技术前沿

25

来越多，数据处理流程越来越复杂，准确全面维

护血缘关系的难度也越来越大。

近年来，上交所持续推进数字化转型，积极

助力科技赋能，批处理系统技术服务能力和数据

管理水平亟待升级。为解决以上问题，批处理系

统启动研发轻量级数据处理框架，既易于与现有

技术体系融合，又便于数据血缘关系的提取。首

先考察主流的数据处理框架，如 Spark，Flink 等，

在借鉴其关于数据算子抽象的基础上，设计开发

C++ 语言的数据处理框架。通过对业务逻辑的抽

象与封装，形成可复用的功能组件，沉淀技术共

享能力，进一步提高研发效率。此外，结合数据

标准及元数据管理，设计了包含数据元、字段、

模型、物理表 / 文件等四层结构的维护模式，确

保字段在所有模型中均有一致的定义，有助于提

高数据质量。

2、数据处理框架

2.1 整体架构

上交所批处理系统的数据处理框架整体可分

为组件层和存储抽象层。组件层包含基础组件层

和功能组件层，其中基础组件提供原始的数据处

理语义，如过滤、联合、映射、分组等 ；功能组

件是对基础组件的组合，实现一个完整的数据转

换功能，如表 A 数据关联更新表 B 数据、表数

据格式转换后导入文件等。存储抽象层则定义了

统一的数据访问接口，如读取、写入、查找、更

新等，使组件层可以无差别的处理文件、数据库

表、共享内存库、Map 等多种存储形式中的数据。

应用层的业务逻辑通常使用预定义的功能组

件实现，特殊情况下可直接组合基础组件实现。

存储抽象层屏蔽了存储介质的差异，使框架易于

加强代码可复用能力，降低开发及测试成本。框架的整体层次如图 2.1 所示。

图 2.1 数据处理框架整体架构图

2.2 ;<=>?

存储抽象层为不同存储介质（如文件、数据表、Map 容器等）中的数据提供统一的访问接口。对数据

图 2.1 ：数据处理框架整体架构图

本期热点

26

融入现有的技术体系 ；组件层则主要体现了业务

逻辑的抽象与复用，加强代码可复用能力，降低

开发及测试成本。框架的整体层次如图 2.1 所示。

2.2 存储抽象层

存储抽象层为不同存储介质（如文件、数据

表、Map 容器等）中的数据提供统一的访问接口。

对数据处理框架而言，一方面屏蔽了存储介质特

性，使组件层可以无差别地处理各种存储形式的

数据 ；另一方面应用层无需关心存储特性，提高

了应用批业务表达的清晰度。

技术实现上，不同的存储类均实现 Storage

接口，类层级关系如图 2.2 所示。根据存储介质

的特性，并非所有接口都要实现，比如文件存储

类（CBatFileStorage）无需实现查找和更新接口。

2.3 组件层

2.3.1 基础组件

基础组件是对常见批量数据处理动作的提

炼，描述了一次数据集的转换。基础组件类似

Spark 和数据库中的算子（Operator）概念。

主要基础组件及其功能如下表 2.1 所示。

图 2.1 数据处理框架整体架构图

2.2 ;<=>?

存储抽象层为不同存储介质（如文件、数据表、Map 容器等）中的数据提供统一的访问接口。对数据

处理框架而言，一方面屏蔽了存储介质特性，使组件层可以无差别地处理各种存储形式的数据；另一方面

应用层无需关心存储特性，提高了应用批业务表达的清晰度。

技术实现上，不同的存储类均实现 Storage 接口，类层级关系如图 2.2 所示。根据存储介质的特性，并

非所有接口都要实现，比如文件存储类（CBatFileStorage）无需实现查找和更新接口。

图 2.2 ： 类层级关系

图 2.2 类层级关系

2.3 @A?

2.3.1基础组件

基础组件是对常见批量数据处理动作的提炼，描述了一次数据集的转换。基础组件类似 Spark 和数据

库中的算子（Operator）概念。

主要基础组件及其功能如下表 2.1 所示。

表 2.1 基础组件及其功能

基础组件 功能简介

Aggregate 支持数据聚合操作

DataSource 用于指定源数据集

CreateView 创建数据库视图

Expand 支持数据扩展操作

Filter 根据某一条件过滤数据集

Groupby 将数据集按某一条件分组，并执行后续操作

Import 支持批量导入数据

Insert 支持数据插入

Join 支持数据集联合

Orderby 支持数据集排序

Update 用于数据更新

Upsert 存在即更新，不存在即插入

Validate 支持数据校验

基础组件具备以下三个特征：

·可组合性。基础组件输入输出接口的一致性保证了其可组合性，基础组件的可组合性是实现复杂数

据处理逻辑的基础。

·可复用性。单个基础组件是对一类数据操作的抽象和提炼，实际使用时根据具体场景对其实例化。

表 2.1 ：基础组件及其功能

交易技术前沿

27

基础组件具备以下三个特征 ：

• 可组合性。基础组件输入输出接口的一致

性保证了其可组合性，基础组件的可组合性是实

现复杂数据处理逻辑的基础。

• 可复用性。单个基础组件是对一类数据操

作的抽象和提炼，实际使用时根据具体场景对其

实例化。

• 可扩展性。新的数据处理模式可以通过开

发新的基础组件来支持，且由于组件的可组合性，

新组件可获得更广的应用范围。

2.3.2 功能组件

功能组件以具体的数据转换模式为基础，统

一代码模式，内化实现细节，仅表达数据转换关

键信息，清晰地表达数据的变更方向和变更方式，

使代码的业务表达能力更精练。组件的标准化和

可复用性有效提高了代码的利用率，减少了应用

代码的冗余度，对提高开发效率具有积极意义。

功能组件一般描述了数据从一个载体到另一

个载体的转换过程。组件并不关心载体具体是什

么，重点是转换过程。比如同一个组件既可以处

理文件数据经过过滤后导入 Map 的过程，又可以

处理表数据经过过滤后导入文件的过程。如前所

述，功能组件都是由一系列基础组件组合而成。

图 2.3 展例了两个功能组件实现。

• 功能组件 1 ：适用于需要过滤源头数据集

图 2.3 功能组件示例

·功能组件 1：适用于需要过滤源头数据集的场景。如筛选出输入产品全量数据中的所有股票产品并

插入数据库表。

·功能组件 2：适用于目标数据集为源数据集和中间数据集联合的场景。如在展开账户对所有产品子

类型的权限并插入到进程 map 的需求中，使用 cross join 操作。

根据实际业务场景，选择合适的功能组件是实现应用业务处理的关键点。当功能组件不满足业务场景

时，可通过组合基础组件开发新的功能组件。以具体业务场景为示例，图 2.4 展示了具体的业务场景衍生

出的功能组件和基础组件的关系。

图 2.4 业务场景与组件关系

功能组件根据执行模式可分为两种。一种是在内存中迭代执行，另一种是转换成 SQL 后在数据库内执

行。下面分别介绍两种执行模式的执行步骤。

迭代执行模式图 2.3 功能组件示例

·功能组件 1：适用于需要过滤源头数据集的场景。如筛选出输入产品全量数据中的所有股票产品并

插入数据库表。

·功能组件 2：适用于目标数据集为源数据集和中间数据集联合的场景。如在展开账户对所有产品子

类型的权限并插入到进程 map 的需求中，使用 cross join 操作。

根据实际业务场景，选择合适的功能组件是实现应用业务处理的关键点。当功能组件不满足业务场景

时，可通过组合基础组件开发新的功能组件。以具体业务场景为示例，图 2.4 展示了具体的业务场景衍生

出的功能组件和基础组件的关系。

图 2.3 ：功能组件示例

图 2.4 ：业务场景与组件关系

本期热点

28

的场景。如筛选出输入产品全量数据中的所有股

票产品并插入数据库表。

• 功能组件 2 ：适用于目标数据集为源数据

集和中间数据集联合的场景。如在展开账户对所

有产品子类型的权限并插入到进程 map 的需求

中，使用 cross join 操作。

根据实际业务场景，选择合适的功能组件是

实现应用业务处理的关键点。当功能组件不满足

业务场景时，可通过组合基础组件开发新的功能

组件。以具体业务场景为示例，图 2.4 展示了具体

的业务场景衍生出的功能组件和基础组件的关系。

功能组件根据执行模式可分为两种。一种是

在内存中迭代执行，另一种是转换成 SQL 后在数

据库内执行。下面分别介绍两种执行模式的执行

步骤。

一、迭代执行模式

下面以图 2.3 中的功能组件 2 为例展示迭代

执行的机制。

图 2.5 迭代执行模式

引用关系，箭头表示下游节点对上游节点的引用；蓝线是函数调用执行的顺序

载IterateExecute 函数（如图 2.3），且都由 save() 接口触发。执行规则是下游节

数据（query），直到最上游的算子节点直接从源数据集中取到数据，然后数据经

turn）最下游的算子节点。为避免对内存过多的占用，数据以分批的形式在各节图 2.5 ：迭代执行模式

红线表示节点引用关系，箭头表示下游节点

对上游节点的引用 ；蓝线是函数调用执行的顺序

迭代执行的组件都重载 IterateExecute 函数

（如图 2.3），且都由 save() 接口触发。执行规则

是下游节点递归的向上游节点请求数据（query），

直到最上游的算子节点直接从源数据集中取到数

据，然后数据经过各级节点处理后返回（return）

最下游的算子节点。为避免对内存过多的占用，

数据以分批的形式在各节点间传递。同时，为避

免数据在各节点间过多拷贝，节点间传递的是数

据指针，且多数节点不缓存数据。例外的是映射

节点（project），因为涉及到数据结构的变动，映

射节点将缓存新结构的数据，并向下游传递新数

据的指针。

二、数据库执行模式

与迭代执行不同，数据库执行的组件都重载

DbExecute，且都由 doDbExecute 触发，如组件 3

所示（图 2.6）。

图 2.7 展示数据库执行的机制。

数据库执行组件先将数据处理流程编译成

SQL 语句，然后在数据库中执行对应 SQL。SQL

的编译过程借鉴 SQLAchemy 项目的思路，主

要应用了 Visitor 设计模式。每个算子节点可接

收一个 Visitor 对象，并把其参数传给 Visitor 对

象。在上图的例子中，Insert 算子通过 visit_insert

接口把目的表信息传递给 SqlVisitor ；Project 算

子把字段映射关系通过 visit_project 接口传递给

SqlVisitor ；Join 算子把关联的左表和右表以及关

联条件传递给 SqlVisitor。通过遍历整个数据流中

的节点，SqlVisitor 收集到所有的表操作要素并放

在其内部的 SqlBuilder 中，最后由 SqlBuilder 将

表操作要素编译成 SQL 语句。

2.4 应用示例

对于实际的盘后批处理应用，可将一个批

（Job）的业务功能拆分成多个步骤的数据集转换

（Stage），每个 Stage 由单个功能组件实现，完成

一次数据集的转换。多个 Stage 顺序执行最终完

成目的数据集的生成。

Step1 ：为 DatasetContext 对 象 提 供 上 下 文

参数，构造初始数据集对象（Dataset）。构造

Dataset 时需指定其存储类型、存储资源 ID、数

据结构（C-Struct）等信息。这些数据集既包含

交易技术前沿

29

二、数据库执行模式

与迭代执行不同，数据库执行的组件都重载 DbExecute，且都由 doDbExecute 触发，如组件 3 所示（图

2.6）。

图 2.6 数据库功能组件

下图 2.7 展示数据库执行的机制。

例外的是映射节点（project），因为涉及到数据结构的变动，映射节点将缓存新结构的数据，并向下游传递

新数据的指针。

二、数据库执行模式

与迭代执行不同，数据库执行的组件都重载 DbExecute，且都由 doDbExecute 触发，如组件 3 所示（图

2.6）。

图 2.6 数据库功能组件

下图 2.7 展示数据库执行的机制。

图 2.6 ：数据库功能组件

图 2.7 ：数据库执行模式

红线表示节点引用关系，箭头表示下游节点对上游节点的引用；蓝线是函数调用

执行的顺序

图 2.7 数据库执行模式

红线表示节点引用关系，箭头表示下游节点对上游节点的引用；蓝线是函数调用执行的顺序

数据库执行组件先将数据处理流程编译成 SQL 语句，然后在数据库中执行对应 SQL。SQL 的编译过

程借鉴 SQLAchemy 项目的思路，主要应用了 Visitor 设计模式。每个算子节点可接收一个 Visitor 对象，并

把其参数传给 Visitor 对象。在上图的例子中，Insert 算子通过 visit_insert 接口把目的表信息传递给 SqlVisitor；

Project 算子把字段映射关系通过 visit_project 接口传递给 SqlVisitor；Join 算子把关联的左表和右表以及关

联条件传递给 SqlVisitor。通过遍历整个数据流中的节点，SqlVisitor 收集到所有的表操作要素并放在其内部

的 SqlBuilder 中，最后由 SqlBuilder 将表操作要素编译成 SQL 语句。

2.4 B#CD

对于实际的盘后批处理应用，可将一个批（Job）的业务功能拆分成多个步骤的数据集转换（Stage），

每个 Stage 由单个功能组件实现，完成一次数据集的转换。多个 Stage 顺序执行最终完成目的数据集的生成。

图 2.8 应用示例解析

Step1：为 DatasetContext 对象提供上下文参数，构造初始数据集对象（Dataset）。构造 Dataset 时需指

定其存储类型、存储资源 ID、数据结构（C-Struct）等信息。这些数据集既包含输入数据集也包含输出数

据集图 2.8 ：应用示例解析

本期热点

30

输入数据集也包含输出数据集。

Step2 ：按顺序执行每个 Stage 的功能组件。

每个功能组件完成一个目标数据集数据的生成。

前面 Stage 的目标数据集可作为后续 Stage 的源数

据集。数据集的读写均通过Storage接口统一完成。

2.5 代码生成

由于批任务代码基于预定义的组件，且代码

结构有较强的规律性，我们在此基础上设计了一

套 Yaml 配置规则，并开发了配套的代码生成程

序，支持将 Yaml 配置翻译成批任务代码。其收

益包括 ：一方面进一步提高了业务开发人员的编

码效率 ；另一方面在于将业务逻辑结构化处理，

支持后续对业务逻辑的进一步解析与应用，生成

数据的血缘关系。如图 2.9 所示，左边为 Yaml

配置，右边为生成的批任务代码。

3、元数据管理

3.1 数据模型构建

批处理系统承载交易系统文件聚合、转发等

业务功能，具有数据量大、数据结构复杂等特点。

批处理系统强化数据标准体系建设工作，在业务

层面，有助于明确业务含义，明确业务与业务间、

业务与技术间统一口径与认识 ；在技术层面，有

助于构建规范的物理数据模型，提供对数据元的

格式规范，进而提高数据质量水平 ；此外，有助

于配合与对接所级别数据标准的建设。

目前，批处理中心使用数据元定义、字段定

义、模型定义、文件 / 数据表定义的递进引用结

构（如图 3.1），对系统所使用的元数据进行管理

与维护。

图 2.9 业务配置与代码生成

3 I$%J'

3.1 $%KL:M

批处理系统承载交易系统文件聚合、转发等业务功能，具有数据量大、数据结构复杂等特点。批系统强化数据标准体系建设工作，在业务层面，有助于明确业务含义，明确业务与业务间、业务与技统一口径与认识；在技术层面，有助于构建规范的物理数据模型，提供对数据元的格式规范，进而提据质量水平；此外，有助于配合与对接所级别数据标准的建设。

目前，批处理中心使用数据元定义、字段定义、模型定义、文件/数据表定义的递进引用结构（如图 对系统所使用的元数据进行管理与维护。

图 3.1 递进引用结构

其中，数据元是数据标准定义的基本单位。以标准数据类型为基准，建立数据标准体系。数据元主题大类、主题子类划分类别（详见表 3.1）。

字段在数据元基础上进行定义，同一个数据元可拥有多个字段，多个字段可指向同一数据元。同图 3.1 ：递进引用结构

图 2.9 业务配置与代码生成

3 I$%J'

图 2.9 ：业务配置与代码生成

交易技术前沿

31

其中，数据元是数据标准定义的基本单位。

以标准数据类型为基准，建立数据标准体系。数

据元按照主题大类、主题子类划分类别（详见表

3.1）。

字段在数据元基础上进行定义，同一个数据

元可拥有多个字段，多个字段可指向同一数据元。

同一数据元仅有一个标准格式字段 ；可拥有多个

扩展格式字段 ；其中，在模型设计规范中定义 ：

批处理系统内部维护的字段均为标准格式字段。

若输入接口中的字段非标准格式，其进入系统内

部模型前需转换为标准格式 ；若输出接口中的字

段为非标准格式，需将内部模型中的标准格式字

段转换为输出接口要求的格式。

模型是由字段组合形成的逻辑概念 ；文件、

数据表在逻辑模型的基础上定义，增加落地的物

理属性。同一个模型可被定义为多个文件 / 数据

表实体。

3.2 配置自动生成

数据元配置可自动化生成文件 / 数据表等

模型的接口文件。目前支持生成文件结构接口、

数据表结构接口、SQL 建表语句等。既减轻了

开发人员的工作量，另一方面保证了元数据与

代码结构的同源性，提升研发效率的同时有效

提高数据维护质量。配置自动生成说明如表 3.2

所示。

在后续工作中，批处理系统将持续加强对元

数据组织方式、标准及规范定义、评审流程等工

作的完善，形成高效可控的管理机制。

4、血缘关系提取

上交所批处理系统涉及的证券数据，主要有

以下特征 ：一、业务繁多，几乎所有业务均包含

盘后处理；二、相关方多，上下游交互系统较多，

主要包含外部对等机构、所内业务系统、市场这

三大类 ；三、业务规则变更、所内外接口变更较

频繁，影响评估工作量大 ；四、盘后批处理应急

场景多，亟需高效的影响评估手段。

基于以上交易系统盘后批处理数据及业务特

征，通过维护数据血缘关系，可有效提高数据变

更影响评估的效率和准确度 ；生产应急情况下，

应急时间窗口紧张，短时间内人工评估数据影响

容易错漏，提供自动化手段可提高运维效率 ；方

据元仅有一个标准格式字段；可拥有多个扩展格式字段；其中，在模型设计规范中定义：批处理系统内部

维护的字段均为标准格式字段。若输入接口中的字段非标准格式，其进入系统内部模型前需转换为标准格

式；若输出接口中的字段为非标准格式，需将内部模型中的标准格式字段转换为输出接口要求的格式。

模型是由字段组合形成的逻辑概念；文件、数据表在逻辑模型的基础上定义，增加落地的物理属性。

同一个模型可被定义为多个文件/数据表实体。

表 3.1 数据模型分级试图

逻辑主题 主题大类 主题子类

市场参与者

账户信息

账户基础信息

账户指定关系

账户权限

持有 账户持仓

机构

机构信息 机构基础信息

PBU 信息

PBU 基础信息

PBU 产品业务权限

产品

产品信息 基础信息

产品业务信息

产品业务交易参数

产品业务平台对应关系

业务 业务信息

业务基础信息

业务时间表

市场 市场信息

交易日历

全局交易时间表

3.2 NOPQGH

数据元配置可自动化生成文件/数据表等模型的接口文件目前支持生成文件结构接口数据表结构接表 3.1 ：数据模型分级试图

本期热点

32

便业务理解，提高需求分析、运维工作效率和工

作质量。

4.1 提取方式

常见的数据血缘关系提取主要以解析 SQL

为主。通过遍历 SQL 的抽象语法树（AST）分析

数据血缘关系。但是批处理系统除了有基于数据

库的数据处理，还有基于文件和内存的处理过程，

这些处理过程无法用 SQL 体现。因此通过解析体

现业务逻辑的 Yaml 配置可以获得更为完整的数

据血缘关系。

与代码生成逻辑类似，通过解析每个数据

处理流程的 From、Join、Insert、Update 等节点

的数据集信息可以获取文件和表级别的血缘关

系（粗粒度）。进一步解析 Insert 和 Update 等节

点的字段赋值关系可以收集字段级别的血缘关

系（细粒度）。

一、文件 / 表级别

任务包含多个输入和输出，通过建立文件 /

数据表的血缘关系，便于分析数据流向，了解数

据的重要程度，为相关业务决策提供参考基础。

特别对于上下游系统交互较多的多任务处理系

统，当生产环境上游文件未及时到达，能迅速进

行影响分析，为应急处置提供帮助。目前我们已

经完成粗粒度血缘关系提取工具的开发，并将血

缘关系导入到了 Apache Atlas 平台。下图 4.1 展

示了港股通限制产品导出功能的文件、表与批任

务的血缘关系。

二、字段级别

交易系统基于数据处理，海量交易数据分散

在多个系统，实际场景中经常会遇到分析字段变

更的影响范围、字段来源于哪里等问题。因此，

分析字段间的血缘关系变得尤为重要。通过分析

批业务配置中文件或表字段赋值的关系，可以生

成细粒度 column 级别的字段流向树。图 4.2 为

mem_code（会员代码）字段的血缘图谱分析结果。

后续将开发字段级别血缘关系的自动化的提取工

具，完善细粒度血缘关系的展示。

血缘关系的维护对后续构建交易系统业务画

像、优化系统业务架构和性能、分析数据变更对

系统造成的影响评估等方面起到更大应用。

5、总结与展望

在借鉴主流数据处理框架优秀设计的基础

上，结合上交所批处理系统特性自研了一套数据

处理框架。一方面可以与批处理系统现有的技术

更好的融合 ；另一方面无需独立的运行时环境，

避免额外的运维负担 ；数据处理框架同时支持内

存迭代执行和数据库 SQL 执行两种模式，统一了

数据库外和数据库内两种数据处理模式的表达方

式。最后，元数据管理不但统一了字段的业务含

表 3.2 ：配置自动生成说明

3.2 NOPQGH

数据元配置可自动化生成文件/数据表等模型的接口文件。目前支持生成文件结构接口、数据表结构接

口、SQL 建表语句等。既减轻了开发人员的工作量，另一方面保证了元数据与代码结构的同源性，提升研

发效率的同时有效提高数据维护质量。配置自动生成说明如表 3.2 所示。

在后续工作中，批处理系统将持续加强对元数据组织方式、标准及规范定义、评审流程等工作的完善，

形成高效可控的管理机制。

表 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

上交所批处理系统涉及的证券数据，主要有以下特征：一、业务繁多，几乎所有业务均包含盘后处理；

交易技术前沿

33

义和技术定义，也使接口代码可自动化生成，提

高了开发效率和准确度。

目前批处理系统已经使用新的开发模式投入

创新业务及交易系统升级建设的研发工作中，基

本实现代码复用、自动化的血缘关系提取以及提

高数据维护质量的目标。将在后续业务支持过程

中持续完善数据处理功能，并探索把数据处理框

架的应用范围扩展到其他处理场景。

集字段级别的血缘关系（细粒度）。

一、文件/表级别

任务包含多个输入和输出，通过建立文件/数据表的血缘关系，便于分析数据流向，了解数据的重要程

度，为相关业务决策提供参考基础。特别对于上下游系统交互较多的多任务处理系统，当生产环境上游文

件未及时到达，能迅速进行影响分析，为应急处置提供帮助。目前我们已经完成粗粒度血缘关系提取工具

的开发，并将血缘关系导入到了 Apache Atlas 平台。下图 4.1 展示了港股通限制产品导出功能的文件、表与

批任务的血缘关系。

图 4.1 文件级别血缘关系提取

二、字段级别

图 4.1 ：文件级别血缘关系提取

交易系统基于数据处理，海量交易数据分散在多个系统，实际场景中经常会遇到分析字段变更的影响

范围、字段来源于哪里等问题。因此，分析字段间的血缘关系变得尤为重要。通过分析批业务配置中文件

或表字段赋值的关系，可以生成细粒度 column 级别的字段流向树。图 4.2 为 mem_code（会员代码）字段

的血缘图谱分析结果。后续将开发字段级别血缘关系的自动化的提取工具，完善细粒度血缘关系的展示。

图 4.2 字段级别血缘关系提取

血缘关系的维护对后续构建交易系统业务画像、优化系统业务架构和性能、分析数据变更对系统造成

的影响评估等方面起到更大应用。

5 Z[\\]^

在借鉴主流数据处理框架优秀设计的基础上，结合上交所批处理系统特性自研了一套数据处理框架。

一方面可以与批处理系统现有的技术更好的融合；另一方面无需独立的运行时环境，避免额外的运维负担；

数据处理框架同时支持内存迭代执行和数据库 SQL 执行两种模式，统一了数据库外和数据库内两种数据处

理模式的表达方式。最后，元数据管理不但统一了字段的业务含义和技术定义，也使接口代码可自动化生

成，提高了开发效率和准确度。

前批系统经使新的发模式投创新务交易系统升级建的发作中基本实代图 4.2 ：字段级别血缘关系提取

本期热点

34

目前，沪深市场上的普通期权产品以及国泰君安的场外期权产品的定价方式均是采用

基于蒙特卡罗模拟，通过软件计算来实现。由于蒙特卡罗模拟往往需要模拟十万条以上的路

径，传统的期权定价方法面临着处理时间过长，计算效率过低等问题。本文基于此类问题，

提出并通过 oneAPI 实现了一种基于 FPGA 的并行流水线期权价格计算方案，能够完成对

欧式香草期权与雪球期权的定价。经过对比与测试，相比于 CPU 通过 C++ 软件实现的方式，

通过 oneAPI 设计，并通过 FPGA 来实现的定价方式在性能上有显著的提升。

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

马辉1

、邹经纬1

、白君洁1

、钟浪辉2

、韩大伟2

、黄琦3

、余洋洋3

、李彪3 / 1 国泰君安证券股份有限公

司 上海 2 上交所技术有限责任公司 上海 3 英特尔移动通信技术 ( 上海 ) 有限公司 上海

E-mail :baijunjie026611@gtjas.com

引言

期权作为最基础的金融衍生产品之一，为其定

价一直是金融工程的重要研究领域，主要使用的定

价方法有偏微分方程法、鞅方法和数值方法。而数

值方法又包括了二叉树方法、有限差分法和蒙特卡

罗模拟方法。蒙特卡罗模拟方法的理论基础是概率

论和数理统计，其实质是通过模拟标的资产价格路

径预测期权的平均回报并得到期权价格估计值。

蒙特卡罗方法的最大优势是误差收敛率不依

赖于问题的维数，从而非常适宜为高维期权定价。

当期权定价模型维数增大时，如多资产的期权模

型，无论是理论还是实际中，不会采用确定性方

法。因此，业内最普遍采用的方法还是蒙特卡罗

方法，特别是对 Path-Dependent（路径依赖）的

各类奇异期权以及 Multi-Asset（多资产）期权模

型，蒙特卡罗方法直观有效。理论上，随机模拟

方法效率和精度很低，但蒙特卡罗算法的模拟路

径部分相互独立，可以并行计算。但是，蒙特卡

罗模拟的缺点就是速率很慢，数值解误差与随机

次数开根号分之一同阶，也就是说，若数值解要

精确到小数点后面 1 位，需要试验 100 次 ；要精

确到小数点后面 2 位，则需要试验 10000 次 ；要

精确到小数点后面 3 位，需要试验 10 的 6 次方次。

使用 CPU 通过软件计算的传统期权定价

会相当耗时，相比，FPGA（Field Programmable

Gate Array，现场可编程门阵列）具有良好的并

行计算特性，使用 FPGA 通过蒙特卡罗模拟进

行期权定价能获得很好的性能提升。本文使用

Intel 公司的 oneAPI 开发工具，通过 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，方差为????的正态分布随机变量，使用欧式香草期权的价格作为最终现货

收益的贴现期望，到期时间为??：

??,-.?? ?? ?? ?? 2

望是在适当的风险中性度量下得到的，该度量使漂移量??等于无风险利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

藤引理得到：

?? ?????? ?? ?? = ?? − 1

2 ??8 ???? + ?????? ?? 4

个常系数随机微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? − 1

2 ??8 ?? + ?? ???? 0,1 5

于??(??)为布朗运动，因此满足均值为 0，方差为??的正态分布，可以改写为：??(??) = ????(0,1)。

(1)

其中，S 为资产价格，μ 为股票的漂移量（瞬

时期望收益率），σ 为股票的波动率，B 为布朗

运行（维纳过程）。

可以认为 dB 是一个均值为 0，方差为 dt 的

正态分布随机变量，使用欧式香草期权的价格作

为最终现货价格的期权收益的贴现期望，到期时

间为 T ：

为看涨和看跌期权，是指在将来的某个特定的时间（到期日），期权的持有者有权力以

敲定价）向期权出售者购买/出卖约定数量的货币，并支付购买该项权力的权力金。欧式

通过 Black-Scholes(BS)模型实现，其随机微分方程（SDE）由下面公式给出：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 1

产价格，??为股票的漂移量（瞬时期望收益率），??为股票的波动率，??为布朗运行（维

一个均值为 0，方差为????的正态分布随机变量，使用欧式香草期权的价格作为最终现货

贴现期望，到期时间为??：

??,-.?? ?? ?? ?? 2

适当的风险中性度量下得到的，该度量使漂移量??等于无风险利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

得到：

?? ?????? ?? ?? = ?? − 1

2 ??8 ???? + ?????? ?? 4

数机微分由式解 (2)

这个期望是在适当的风险中性度量下得到

的，该度量使漂移量μ等于无风险利率r，可得到:

纳过程）。

可以认为????是一个均值为 0，方差为????的正态分布随机变量，使用欧式香草期权的价格作为最终现价格的期权收益的贴现期望，到期时间为??：

??,-.?? ?? ?? ?? 这个期望是在适当的风险中性度量下得到的，该度量使漂移量??等于无风险利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通过伊藤引理得到：

?? ?????? ?? ?? = ?? − 1

2 ??8 ???? + ?????? ?? 这是一个常系数随机微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? − 1

2 ??8 ?? + ?? ???? 0,1 这里由于??(??)为布朗运动，因此满足均值为 0，方差为??的正态分布，可以改写为：??(??) = ????(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，方差为????的正态分布随机变量，使用欧式香草期权的价格作为最终价格的期权收益的贴现期望，到期时间为??：

??,-.?? ?? ?? ?? 这个期望是在适当的风险中性度量下得到的，该度量使漂移量??等于无风险利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通过伊藤引理得到：

?? ?????? ?? ?? = ?? − 1

2 ??8 ???? + ?????? ?? 这是一个常系数随机微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? − 1

2 ??8 ?? + ?? ???? 0,1 这里由于??(??)为布朗运动，因此满足均值为 0，方差为??的正态分布，可以改写为：??(??) = ????(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，方差为????的正态分布随机变量，使用欧式香草期权的价格作为最价格的期权收益的贴现期望，到期时间为??：

??,-.?? ?? ?? ?? 这个期望是在适当的风险中性度量下得到的，该度量使漂移量??等于无风险利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通过伊藤引理得到：

?? ?????? ?? ?? = ?? − 1

2 ??8 ???? + ?????? ?? 这是一个常系数随机微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? − 1

2 ??8 ?? + ?? ???? 0,1 这里由于??(??)为布朗运动，因此满足均值为 0，方差为??的正态分布，可以改写为：??(??) = ??将上式使用??(??)的指数形式改写为：

?? ?? = ?? 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 的 正 态 分 布， 可 以 改 写 为 ：

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 1

其中，??为资产价格，??为股票的漂移量（瞬时期望收益率），??为股票的波动率，??为布朗运行（维

程）。

可以认为????是一个均值为 0，方差为????的正态分布随机变量，使用欧式香草期权的价格作为最终现货

的期权收益的贴现期望，到期时间为??：

??,-.?? ?? ?? ?? 2

这个期望是在适当的风险中性度量下得到的，该度量使漂移量??等于无风险利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 3

通过伊藤引理得到：

?? ?????? ?? ?? = ?? − 1

2 ??8 ???? + ?????? ?? 4

这是一个常系数随机微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? − 1

2 ??8 ?? + ?? ???? 0,1 5

这里由于??(??)为布朗运动，因此满足均值为 0，方差为??的正态分布，可以改写为：??(??) = ????(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，方差为????的正态分布随机变量，使用欧式香草期权的价格作为最终现价格的期权收益的贴现期望，到期时间为??：

??,-.?? ?? ?? ?? 这个期望是在适当的风险中性度量下得到的，该度量使漂移量??等于无风险利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通过伊藤引理得到：

?? ?????? ?? ?? = ?? − 1

2 ??8 ???? + ?????? ?? 这是一个常系数随机微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? − 1

2 ??8 ?? + ?? ???? 0,1 这里由于??(??)为布朗运动，因此满足均值为 0，方差为??的正态分布，可以改写为：??(??) = ????(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，方差为????的正态分布随机变量，使用欧式香草期权的价格作为最终价格的期权收益的贴现期望，到期时间为??：

??,-.?? ?? ?? ?? 这个期望是在适当的风险中性度量下得到的，该度量使漂移量??等于无风险利率??，可得到:

???? ?? = ???? ?? ???? + ???? ?? ???? ?? 通过伊藤引理得到：

?? ?????? ?? ?? = ?? − 1

2 ??8 ???? + ?????? ?? 这是一个常系数随机微分方程，可由下式解出：

?????? ?? ?? = ?????? ?? 0 + ?? − 1

2 ??8 ?? + ?? ???? 0,1 这里由于??(??)为布朗运动，因此满足均值为 0，方差为??的正态分布，可以改写为：??(??) = ????(将上式使用??(??)的指数形式改写为：

?? ?? = ?? 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 雪球期权与标的价格关系

雪球期权最主要的特点是具有敲出水平和与敲入水平两个门限，敲出水平每月观测一次，敲入水平每

日观测一次，如果发生敲出事件，产品终止并兑付收益；如果发生敲入事件，保护失效，若期末未敲出，

则相当于持有该股票。因此截止期末可分为三种情况：第一种情况为敲出，可获得票息为：年化票息×名义

本金×存续月数/12，如图 2 所示，第二个月虽然发生了敲入事件，但第三个月底敲出观察日时发生了敲出

事件，因此可本金无损外加 3 个月的票息收益。

图 1 ：雪球期权与标的价格关系

雪球期权最主要的特点是具有敲出水平和与

本期热点

36

敲入水平两个门限，敲出水平每月观测一次，敲

入水平每日观测一次，如果发生敲出事件，产品

终止并兑付收益；如果发生敲入事件，保护失效，

若期末未敲出，则相当于持有该股票。因此截

止期末可分为三种情况 ：第一种情况为敲出，可

获得票息为 ：年化票息 × 名义本金 × 存续月数

/12，如图 2 所示，第二个月虽然发生了敲入事件，

但第三个月底敲出观察日时发生了敲出事件，因

此可本金无损外加 3 个月的票息收益。

其年化收益率与挂钩标的价格变化的关系如图 1 所示。

图 1 雪球期权与标的价格关系

雪球期权最主要的特点是具有敲出水平和与敲入水平两个门限，敲出水平每月观测一次，敲入水平每

观测一次，如果发生敲出事件，产品终止并兑付收益；如果发生敲入事件，保护失效，若期末未敲出，

相当于持有该股票。因此截止期末可分为三种情况：第一种情况为敲出，可获得票息为：年化票息×名义

金×存续月数/12，如图 2 所示，第二个月虽然发生了敲入事件，但第三个月底敲出观察日时发生了敲出

件，因此可本金无损外加 3 个月的票息收益。

图 2 敲出

第二种情况为敲入未敲出，结算金额为：名义本金×MAX（0，期初价格-期末价格）/期初价格，如图

所示，在第三个月发生了敲入事件，产品存续期间未发生敲出事件，因此本金受损，无票息收益。

图 3 敲入未敲出

第三种情况为未敲入未敲出，可获得票息为：年化票息×名义本金×存续月数/12，如图 4 所示，存续

图 2 ：敲出

第二种情况为敲入未敲出，结算金额为 ：名

义本金 ×MAX（0，期初价格 - 期末价格）/ 期

初价格，如图 3 所示，在第三个月发生了敲入事

件，产品存续期间未发生敲出事件，因此本金受

损，无票息收益。

其年化收益率与挂钩标的价格变化的关系如图 1 所示。

图 1 雪球期权与标的价格关系

雪球期权最主要的特点是具有敲出水平和与敲入水平两个门限，敲出水平每月观测一次，敲入水平每

日观测一次，如果发生敲出事件，产品终止并兑付收益；如果发生敲入事件，保护失效，若期末未敲出，

则相当于持有该股票。因此截止期末可分为三种情况：第一种情况为敲出，可获得票息为：年化票息×名义

本金×存续月数/12，如图 2 所示，第二个月虽然发生了敲入事件，但第三个月底敲出观察日时发生了敲出

事件，因此可本金无损外加 3 个月的票息收益。

图 2 敲出

第二种情况为敲入未敲出，结算金额为：名义本金×MAX（0，期初价格-期末价格）/期初价格，如图

所示，在第三个月发生了敲入事件，产品存续期间未发生敲出事件，因此本金受损，无票息收益。

图 3 敲入未敲出

第三种情况为未敲入未敲出，可获得票息为：年化票息×名义本金×存续月数/12，如图 4 所示，存续

图 3 ：敲入未敲出

第三种情况为未敲入未敲出，可获得票息为：

年化票息 × 名义本金 × 存续月数 /12，如图 4

所示，存续期间期间未发生敲入事件与敲出事件，

期间期间未发生敲入事可获得满期 6 个月的票息收益。 件与敲出事件，可获得满期 6 个月的票息收益。

图 4 未敲入未敲出

图 4 ：未敲入未敲出

2、FPGA 与 oneAPI 的优势

CPU（Central Processing Unit， 中 央 处 理

器）的摩尔定律已入暮年，在高性能计算领域，

CPU 的表现已经渐渐被 GPU（Graphics Processing

Unit，图形处理器）、ASIC（Application Specific

Integrated Circuit，专用集成电路）和 FPGA 等硬

件超越。FPGA 常年来被用于 ASIC 的小批量替

代品，以同时提供强大的计算能力和足够的灵活

性，如图 5 所示。

CPU、GPU 都属于冯·诺依曼结构，指令

译码执行、共享内存。FPGA 之所以比 CPU 甚至

GPU 能效高，本质上是无指令、无需共享内存的

体系结构带来的福利。冯氏结构中，由于执行单

元（如 CPU 核）可能执行任意指令，就需要有指

令存储器、译码器、各种指令的运算器、分支跳

转处理逻辑。由于指令流的控制逻辑复杂，不可

能有太多条独立的指令流，因此 GPU 使用 SIMD

（Single Instruction Multiple Data)，单指令流多数据

流）来让多个执行单元以同样的步调处理不同的

数据，CPU 也支持 SIMD 指令。而 FPGA 每个逻

辑单元的功能在重编程（烧写）时就已经确定，

不需要指令。冯氏结构中使用内存有两种作用。

一是保存状态，二是在执行单元间通信。由于内

存是共享的，就需要做访问仲裁 ；为了利用访问

局部性，每个执行单元有一个私有的缓存，这就

要维持执行部件间缓存的一致性。对于保存状态

的需求，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 个计算单元，

每个计算单元也在处理不同的数据包，然而所有

的计算单元必须按照统一的步调，做相同的事情，

这就要求 10 个数据包必须一起输入、一起输出，

输入输出的延迟增加了。

当任务是逐个而非成批到达的时候，流水线

并行比数据并行可实现更低的延迟。因此对流式

计算的任务，FPGA 比 GPU 天生有延迟方面的优

势，如图 6 所示。

执行单元有一个私有的缓存，这就要维持执行部件间缓存的一致性。对于保存状态的需求，FPGA 中的寄

存器和 BRAM（Block RAM，片上内存）是属于各自的控制逻辑的，无需不必要的仲裁和缓存。对于通信

的需求，FPGA 每个逻辑单元与周围逻辑单元的连接在重编程（烧写）时就已经确定，并不需要通过共享

内存来通信。

FPGA 同时拥有流水线并行和数据并行，而 GPU 几乎只有数据并行（流水线深度受限）。

例如处理一个数据包有 10 个步骤，FPGA 可以搭建一个 10 级流水线，流水线的不同级在处理不同的

数据包，每个数据包流经 10 级之后处理完成，每处理完成一个数据包，就能马上输出；而 GPU 的数据并

行方法是做 10 个计算单元，每个计算单元也在处理不同的数据包，然而所有的计算单元必须按照统一的步

调，做相同的事情，这就要求 10 个数据包必须一起输入、一起输出，输入输出的延迟增加了。

当任务是逐个而非成批到达的时候，流水线并行比数据并行可实现更低的延迟。因此对流式计算的任

务，FPGA 比 GPU 天生有延迟方面的优势，如图 6 所示。

图 6 并行流水线

各体系架构性能数量级比较（以 16 位整数乘法为例）如表 2 所示。

表 2 各体系架构性能数量级比较

体系架构 吞吐量 延迟 功耗 灵活性

CPU ~1T N/A ~100W 很高

GPU ~10T ~1ms ~300W 高

FPGA(Stratix 10) ~10T ~1us ~30W 高

ASIC ~10T ~1us ~30W 低

期权计算不可能有闭合形式的解，而是通过用蒙特卡罗方法模拟了许多可能的路径，最终得到了一个

预期的收益值。使用蒙特卡罗模拟需要生成高质量的随机数，并进行上千万点的模拟，传统的使用 CPU 来

进行计算，耗时非常巨大，而 FPGA 通过使用通道以及循环流水线的排布，能够有效提升性能，减小计算

延迟。

而传统的 FPGA 开发一般选择硬件描述语言（如 VHDL/Verilog HDL），开发周期长、难度大，对于

使用高级语言进行开发的软件工程师而言，进入的门槛非常高。在开发 FPGA 时，需要硬件理解深刻，重

点是需要非常详细的设计工作，合理规划硬件资源进行任务并行和数据并行的处理业务，包括处理的时序、

RAM 的分配,还要经过一系列的仿真、综合等。

Intel FPGA SDK 提供了高效的使用高级语言开发 FPGA 的方式，通过 OpenCL 或 oneAPI 工具来进行

FPGA 开发。相比于 OpenCL，作为升级版，oneAPI 真正意义上实现了天下大同。oneAPI 编程模型简化了

CPU 和加速器的编程，基于 C++特性与 SYCL 并行性的标准跨体系结构语言 DPC++。DPC++支持主机和

加速器的代码复用，使用单一的源语言，执行和内存依赖清晰地沟通。DPC++代码内的映射可用于将应用

图 6 ：并行流水线

各体系架构性能数量级比较（以 16 位整数

乘法为例）如表 2 所示。

期权计算不可能有闭合形式的解，而是通过

用蒙特卡罗方法模拟了许多可能的路径，最终得

到了一个预期的收益值。使用蒙特卡罗模拟需要

生成高质量的随机数，并进行上千万点的模拟，

传统的使用 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 都属于冯·诺依曼结构，指令译码执行、共享内存。FPGA 之所以比 CPU 甚至 GPU 能效

高，本质上是无指令、无需共享内存的体系结构带来的福利。冯氏结构中，由于执行单元（如 CPU 核）可

能执行任意指令，就需要有指令存储器、译码器、各种指令的运算器、分支跳转处理逻辑。由于指令流的

控制逻辑复杂，不可能有太多条独立的指令流，因此 GPU 使用 SIMD（Single Instruction Multiple Data)，单

指令流多数据流）来让多个执行单元以同样的步调处理不同的数据，CPU 也支持 SIMD 指令。而 FPGA 每

个逻辑单元的功能在重编程（烧写）时就已经确定，不需要指令。冯氏结构中使用内存有两种作用。一是

保存状态，二是在执行单元间通信。由于内存是共享的，就需要做访问仲裁；为了利用访问局部性，每个

图 5 ：不同体系结构性能和灵活性的比较

执行单元有一个私有的缓存，这就要维持执行部件间缓存的一致性。对于保存状态的需求，FPGA 中的寄

存器和 BRAM（Block RAM，片上内存）是属于各自的控制逻辑的，无需不必要的仲裁和缓存。对于通信

的需求，FPGA 每个逻辑单元与周围逻辑单元的连接在重编程（烧写）时就已经确定，并不需要通过共享

内存来通信。

FPGA 同时拥有流水线并行和数据并行，而 GPU 几乎只有数据并行（流水线深度受限）。

例如处理一个数据包有 10 个步骤，FPGA 可以搭建一个 10 级流水线，流水线的不同级在处理不同的

数据包，每个数据包流经 10 级之后处理完成，每处理完成一个数据包，就能马上输出；而 GPU 的数据并

行方法是做 10 个计算单元，每个计算单元也在处理不同的数据包，然而所有的计算单元必须按照统一的步

调，做相同的事情，这就要求 10 个数据包必须一起输入、一起输出，输入输出的延迟增加了。

当任务是逐个而非成批到达的时候，流水线并行比数据并行可实现更低的延迟。因此对流式计算的任

务，FPGA 比 GPU 天生有延迟方面的优势，如图 6 所示。

图 6 并行流水线

各体系架构性能数量级比较（以 16 位整数乘法为例）如表 2 所示。

表 2 各体系架构性能数量级比较

体系架构 吞吐量 延迟 功耗 灵活性

CPU ~1T N/A ~100W 很高

GPU ~10T ~1ms ~300W 高

FPGA(Stratix 10) ~10T ~1us ~30W 高

ASIC ~10T ~1us ~30W 低

期权计算不可能有闭合形式的解，而是通过用蒙特卡罗方法模拟了许多可能的路径，最终得到了一个

预期的收益值。使用蒙特卡罗模拟需要生成高质量的随机数，并进行上千万点的模拟，传统的使用 CPU 来

进行计算，耗时非常巨大，而 FPGA 通过使用通道以及循环流水线的排布，能够有效提升性能，减小计算

延迟。

表 2 ：各体系架构性能数量级比较

本期热点

38

而 FPGA 通过使用通道以及循环流水线的排布，

能够有效提升性能，减小计算延迟。

而传统的 FPGA 开发一般选择硬件描述语言

（如 VHDL/Verilog HDL），开发周期长、难度大，

对于使用高级语言进行开发的软件工程师而言，

进入的门槛非常高。在开发 FPGA 时，需要硬件

理解深刻，重点是需要非常详细的设计工作，合

理规划硬件资源进行任务并行和数据并行的处理

业务，包括处理的时序、RAM 的分配 , 还要经过

一系列的仿真、综合等。

Intel FPGA SDK 提供了高效的使用高级语言

开发 FPGA 的方式，通过 OpenCL 或 oneAPI 工具

来进行 FPGA 开发。相比于 OpenCL，作为升级

版，oneAPI 真正意义上实现了天下大同。oneAPI

编程模型简化了 CPU 和加速器的编程，基于

C++ 特性与 SYCL 并行性的标准跨体系结构语言

DPC++。DPC++ 支持主机和加速器的代码复用，

使用单一的源语言，执行和内存依赖清晰地沟通。

DPC++ 代码内的映射可用于将应用程序转换为在

硬件 ( 或一组硬件 ) 上运行，从而最大程度地加

速工作负载。主机可以简化设备代码的开发和调

试，甚至在没有加速器的平台上也是如此。

图 7 所示为一个通过 DPC++ 语言开发的

oneAPI 简单应用，用来将数组的每个元素设置

为其下标的值。可以看出，主机代码和加速器代

码都组合在一个源文件中，使用的语法是标准的

C++，并通过 C++ 类来实现并行性。该示例的逻

辑为 ：第 8 行和第 9 行创建了一个包含 16 个 int

元素的 buffer，第 11 行构造一个队列来表示主机

到加速器之间的连接。创建队列后，调用形参为

lambda 函数的 submit() 成员函数向加速器提交工

作，它在第 12 行创建一个访问器，使得可以在

buffer 中写入元素，在第 13 行调用 parallel_for()

函数来执行加速器上的代码。调用的 parallel_

for() 函数有两个参数，一个参数是 lambda 函数，

另一个是表示 buffer 中元素数量的范围对象“r”，

lambda 在加速器上被该范围内的每个索引调用一

次，通过使用在第 12 行创建的 out 访问器将一

个值赋给 buffer。在调用 parallel_for() 之后，代码

的主机部分将继续运行，而无需等待加速器上的

工作完成，并在第 18 行创建一个构造函数 host_

accessor 来读取 buffer 中的元素，这里 buffer 中的

元素是由加速器写入的，所以在 parallel_for() 的

数据传递完成之前，host_accessor 将被阻塞，加

速器工作完成后，主机开始执行第 18 行之后的

代码。

程序转换为在硬件(或一组硬件)上运行，从而最大程度地加速工作负载。主机可以简化设备代码的开发和调试，甚至在没有加速器的平台上也是如此。

图7所示为一个通过DPC++语言开发的oneAPI简单应用，用来将数组的每个元素设置为其下标的值可以看出，主机代码和加速器代码都组合在一个源文件中，使用的语法是标准的 C++，并通过 C++类来现并行性。该示例的逻辑为：第 8 行和第 9 行创建了一个包含 16 个 int 元素的 buffer，第 11 行构造一个列来表示主机到加速器之间的连接。创建队列后，调用形参为 lambda 函数的 submit()成员函数向加速器交工作，它在第 12 行创建一个访问器，使得可以在 buffer 中写入元素，在第 13 行调用 parallel_for()函数执行加速器上的代码。调用的 parallel_for()函数有两个参数，一个参数是 lambda 函数，另一个是表示 bu中元素数量的范围对象“r”，lambda 在加速器上被该范围内的每个索引调用一次，通过使用在第 12 行建的 out 访问器将一个值赋给 buffer。在调用 parallel_for()之后，代码的主机部分将继续运行，而无需等加速器上的工作完成，并在第 18 行创建一个构造函数 host_accessor 来读取 buffer 中的元素，这里 buffer 的元素是由加速器写入的，所以在 parallel_for()的数据传递完成之前，host_accessor 将被阻塞，加速器工完成后，主机开始执行第 18 行之后的代码。

图 7 oneAPI 开发示例

此外，oneAPI 编程模型提供了可以跨硬件目标使用的全面统一的开发人员工具组合，包括跨越多个作负载域的一系列性能库。这些库包括为每个目标体系结构定制编码的函数，因此相同的函数调用可以受支持的体系结构之间提供优化的性能，如图 8 所示，利用 oneAPI 编程模型的应用程序可以在从 CPU FPGA 的多个目标硬件平台上运行。

图 7 ：oneAPI 开发示例

此外，oneAPI 编程模型提供了可以跨硬件

目标使用的全面统一的开发人员工具组合，包括

跨越多个工作负载域的一系列性能库。这些库包

括为每个目标体系结构定制编码的函数，因此相

同的函数调用可以在受支持的体系结构之间提供

优化的性能，如图 8 所示，利用 oneAPI 编程模

型的应用程序可以在从 CPU 到 FPGA 的多个目

标硬件平台上运行。

与此同时，Intel 也在大力投入对 oneAPI 的

研发，使其开发效率，编译性能，以及运算性能

都在不断提高，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 的梅森旋转链。因

为旋转链上的后一个数据需要对前一个数据进行

计算才能得到，所以旋转链的生成无法数据并行，

可以选择流水线的方式进行优化。MT Initial 和

MT Generation 之间通过 Channel 0 传输梅森旋转

链数据。一般在选择 Channel 数据大小和深度时，

选择 2 的整数次幂。MT Initial 生成的旋转链长

度为 624，可以选择每次传输旋转链中的 64 个或

128 个数据给 MT Generation。

MT Generation 的计算逻辑是 ：取出初始化

的 624 长度的初始化旋转链，然后执行旋转算

法（针对整个链），以后以 624 为周期，用梅森

状态链每生成 624 个随机数，旋转一次，随后生

成下一组 624 个随机数。同样，将生成的随机数

通过大小为 64 或 128 的 Channel 1 传入到下一个

kernel 进行计算。欧式期权和雪球期权随机数生

图 8 oneAPI 跨工作域

与此同时，Intel 也在大力投入对 oneAPI 的研发，使其开发效率，编译性能，以及运算性能都在不断

提高，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 的梅森旋转链。因为旋转链

上的后一个数据需要对前一个数据进行计算才能得到，所以旋转链的生成无法数据并行，可以选择流水线

的方式进行优化。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 的研发，使其开发效率，编译性能，以及运算性能都在不断

提高，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 的梅森旋转链。因为旋转链

上的后一个数据需要对前一个数据进行计算才能得到，所以旋转链的生成无法数据并行，可以选择流水线

的方式进行优化。MT Initial 和 MT Generation 之间通过 Channel 0 传输梅森旋转链数据。一般在选择 Channel

数据大小和深度时，选择 2 的整数次幂。MT Initial 生成的旋转链长度为 624，可以选择每次传输旋转链中

的 64 个或 128 个数据给 MT Generation。

MT Generation 的计算逻辑是：取出初始化的 624 长度的初始化旋转链，然后执行旋转算法（针对整

个链），以后以 624 为周期，用梅森状态链每生成 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）上的均匀分布

转化为标准正态分布，进行下面的计算。对于欧

式期权，可直接使用 BS 公式进行定价，将结果

写入 Channel 2 中，由于运算逻辑简单，可使用

NDRange 提升计算性能，每次下发 8192 个计算

任务，充分使用流水线计算。对于雪球期权，在

BS 公式的基础上，还需要进行复杂的向量运算，

来模拟三种不同的情景，所以每次展开一条蒙特

卡罗路径进行模拟，将每条路径的模拟价格写入

Channel 2 中，每条路径内部的 for 循环可以使用

数据并行来提高计算性能。

最 后 Partial Accumulation 部 分 为 累 加 求

和 , 从 Channel ２中读取出期权价格之和，写回

Buffer 中。对于欧式期权，每次发送 8192 个线

程，所以需要读取完 8192 个数据；对于雪球期权，

进行了 mc 条蒙特卡罗路径的模拟，所以需要读

取完 mc 个数据。将和写回主机的 Result Buffer

中求取平均值完成最终的期权定价。

4、结果验证与分析

CPU 和 FPGA 在期权定价流程中有各自擅长

的模块，本次验证对欧式期权和雪球期权定价最

终性能在 CPU 和 FPGA 上进行综合对比。

测试验证对比环境 ：

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）上的均匀分布转化为标准正态分布，进行下面的计算。对于欧式期权，可直接使用 BS 公

式进行定价，将结果写入 Channel 2 中，由于运算逻辑简单，可使用 NDRange 提升计算性能，每次下发 8192

个计算任务，充分使用流水线计算。对于雪球期权，在 BS 公式的基础上，还需要进行复杂的向量运算，

来模拟三种不同的情景，所以每次展开一条蒙特卡罗路径进行模拟，将每条路径的模拟价格写入 Channel 2

中，每条路径内部的 for 循环可以使用数据并行来提高计算性能。

最后 Partial Accumulation 部分为累加求和,从 Channel ２中读取出期权价格之和，写回 Buffer 中。对

于欧式期权，每次发送 8192 个线程，所以需要读取完 8192 个数据；对于雪球期权，进行了 mc 条蒙特卡

罗路径的模拟，所以需要读取完 mc 个数据。将和写回主机的 Result Buffer 中求取平均值完成最终的期权定

价。

4 CDEF>GH

CPU 和 FPGA 在期权定价流程中有各自擅长的模块，本次验证对欧式期权和雪球期权定价最终性能在

CPU 和 FPGA 上进行综合对比。

测试验证对比环境：

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）上的均匀分布转化为标准正态分布，进行下面的计算。对于欧式期权，可直接使用 BS 公

式进行定价，将结果写入 Channel 2 中，由于运算逻辑简单，可使用 NDRange 提升计算性能，每次下发 8192

个计算任务，充分使用流水线计算。对于雪球期权，在 BS 公式的基础上，还需要进行复杂的向量运算，

来模拟三种不同的情景，所以每次展开一条蒙特卡罗路径进行模拟，将每条路径的模拟价格写入 Channel 2

中，每条路径内部的 for 循环可以使用数据并行来提高计算性能。

最后 Partial Accumulation 部分为累加求和,从 Channel ２中读取出期权价格之和，写回 Buffer 中。对

于欧式期权，每次发送 8192 个线程，所以需要读取完 8192 个数据；对于雪球期权，进行了 mc 条蒙特卡

罗路径的模拟，所以需要读取完 mc 个数据。将和写回主机的 Result Buffer 中求取平均值完成最终的期权定

价。

4 CDEF>GH

CPU 和 FPGA 在期权定价流程中有各自擅长的模块，本次验证对欧式期权和雪球期权定价最终性能在

CPU 和 FPGA 上进行综合对比。

测试验证对比环境：

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++ 语言，采用流水线

并行与数据并行方式，设计出多种期权定价模

型，并分别通过对欧式期权定价与雪球期权定价

的对比分析，相比于传统软件处理方式，使用

FPGA 处理的综合性能均可获得较大的提升，并

且随着模拟次数的增加，获得更加精确的期权定

价结果的同时，FPGA 能够更大程度地释放性能，

在模拟 2M（2*1024*1024）条蒙特卡罗路径时，

分别可获得 20 倍左右与 30 倍左右的性能提升。

国泰君安在金融硬件加速领域深耕多年，后续将

继续精进，使用 oneAPI 与 FPGA 在金融硬件加

速领域进行更多的研究与探索，为业内持续输出

经验。

43

探索与应用

6 证券运维系统自动化代理平台建设实践

7 基于上证云的数据跨境流动管理方案研究与实现

8 安信证券网络系统自动化运维平台建设实践

9 兴业证券应用性能监控系统建设思路、方法和实践

10 一种可扩展的多因素访问控制方法及实践

11 证券公司智慧营销与服务平台建设

12 证券行业网站智能数据搜索服务的研究与实践

13 关于 ION GROUP 遭遇勒索病毒攻击事件的分析

思考报告

交易技术前沿

45

证券运维系统自动化代理平台

建设实践

肖钢、徐志彬、柴晨、王军、喻文强、张皓凌 / 中信建投证券股份有限公司

E-mail ：chaichen@csc.com.cn

1、概述

在智能运维时代，自动化代理平台是必不可

少的网络运维系统。面对众多运维子系统，系统

基本是“相互孤立、独自运行”的，并没有统一

的代理平台对接庞杂的服务器，各个运维子系统

在执行业务操作的时候，往往自研一套服务器交

互系统独自进行， 既造成了公司内部研发资源的

浪费，同时这些交互系统无论是系统架构可用性

还是稳定性，可扩展性上都差强人意。甚至有些

在全球数字化经济的大浪潮下，人工智能、区块链、云计算和大数据等技术的发展

不断冲击着证券行业的运维模式。随着运维体系的复杂化和服务器的差异化加剧，运维成

本不断增长，运维人员的技术要求更加苛刻，因此，智能化、高可靠、统一的自动化代理

平台成为证券运维体系的一项重点工作。

中信建投证券自动化代理平台通过构建统一的运维服务入口，将运维系统有机结合

在一起。近年来，微服务架构与异步通信技术快速发展，并逐渐成为系统建设的主流技术，

微服务架构与异步通信技术能够有效提高系统稳定性与可扩展性，为自动化代理平台建设

提供了成熟的解决方案。本文通过介绍自动化代理平台的探索和实践，针对运维体系数字

化转型中遇到的外部数据规范不统一、服务器差异化、运维系统复杂化等问题，分享解决

方案和实践经验，助力证券行业数字化发展。

探索与应用

46

业务场景下，还需要运维人员人为干预，手动的

在服务器上执行运维指令，无形增加了运维人员

的工作难度，加大了运维成本。

自动化代理平台将运维子系统和服务器有机

的连接在一起，通过自动化代理平台统一对服务

器进行动态管理，同时使用高效的异步接口为运

维子系统提供服务。自动化代理平台作为外部系

统和内部服务器之间通信的桥梁，我们设计了文

件传输、命令调用等基础功能，在此基础上，又

将扩展出信息采集、数据备份、应用部署和代理

节点状态监控等一系列功能。为了系统的稳定运

行，需要对代理的稳定性、安全性进行有效地把

握，所以对代理的性能的并发量、吞吐量、安全

性又有一定的要求。此外，还需要对代理的各个

客户端进行统一管理，实现代理状态监控和自动

修复。

目前，运维系统逐渐走向智能化、标准化，

自动化代理平台可节省大量人力运维成本，并且

可提供高效、稳定的运维服务。如何利用云计算

技术与微服务架构，构建高可用、可扩展的自动

化代理平台，成为证券公司亟需解决的问题。本

文将介绍中信建投证券对于自动化代理平台的架

构探索，并阐述架构探索中的实践与经验。

2、自动化代理平台架构

2.1 总体设计

自动化代理平台采用微服务架构，系统中的

各个微服务可被独立部署，各个微服务之间是松

耦合的。每个微服务仅关注某项独立的功能模块。

整体架构具有快速部署、高扩展性、高容错性和

去集中化等特点，主要由六个层级构成 ：

（1）用户层

用户层是自动化代理平台的操作入口，用户

可以通过将运维管理系统与自动化代理平台对接

来处理自身业务诉求，也可以通过访问自动化代

理平台的 Web 页面进行人机交互。为了便于用

户系统对接用户层，我们提供了可直接集成的自

动化代理平台工具包，用户通过 API 指令调用自

动化代理平台工具包，并由自动化代理平台工具

包来完成与自动化代理平台系统的交互。

（2）网关层

网关层可以对外暴露聚合 API，屏蔽内部微

服务的微小变动，保持整个系统的稳定性。

在运维体系中，通常会有众多终端服务器，

他们提供不同类型的服务，且通常分布在不同的

物理机房中。想要从用户层精准的操作某一个机

图 1 ：自动化代理平台层级结构图 图 1 自动化代理平台层级结构图

（1）用户层

用户层是自动化代理平台的操作入口，用户可以通过将运维管理系统与自动化代理平台对接来处理自

身业务诉求，也可以通过访问自动化代理平台的 Web 页面进行人机交互。为了便于用户系统对接用户层，

我们提供了可直接集成的自动化代理平台工具包，用户通过 API 指令调用自动化代理平台工具包，并由自

交易技术前沿

47

房的某一台服务器通常是很困难和繁琐的。自动

化代理平台采用了二级代理和动态路由的方案解

决了这个痛点问题，通过在物理机房部署二级代

理，将机房内的服务器使用 Netty 连接在一起，再

通过动态路由的方式将用户请求路由到各二级代

理，最终通过 Netty 完成指定服务器的业务操作。

当然这只是网关层众多功能中的一部分，它

还可以做负载均衡，统一鉴权，协议转换，监控

监测等一系列功能。

（3）熔断层

分布式系统环境下，服务间依赖非常常见，

一个业务调用通常依赖多个基础服务。对于同步

调用，当某服务不可用时，会导致上级服务的请

求线程被阻塞，当有大批量上级服务请求时，最

终可能导致整个系统资源耗尽，无法继续对外提

供服务。并且这种不可用可能沿请求调用链向上

传递，导致雪崩效应。因此，为了构建稳定、可

靠的分布式系统，熔断层必不可少，熔断层能够

对对来自依赖的故障进行隔离，当依赖服务不可

用时，当前服务启动自我保护功能，从而避免发

生雪崩效应。

（4）服务层

服务层负责提供可复用的服务，通过集群

方式实现高可用，用户层通过分布式服务调用框

架访问到服务层，分布式服务调用框架会在网关

层实现软件负载均衡，并通过服务注册中心服务

EurekaServer 对提供服务的服务器进行心跳检测，

发现有服务不可用，立即通知客户端程序修改服

务访问列表，剔除不可用的服务器。

AgentServer 在架构上充当了二级代理的角

色，通过 AgentServer 将用户层和逻辑层连接在

一起，AgentServer 在功能上是自动化代理平台的

核心服务，通过 Netty 服务端的形式与逻辑层的

服务器中的 Netty 客户端进行连接，将用户层请

求处理过后交由逻辑层进行执行。

AgentRegister 主要有两个作用，一是作为

Netty 客户端的注册中心，对 Netty 连接状态进行

监控管理，二是为网关层提供动态的 Netty 连接

信息，是实现动态路由的关键。

（5）逻辑层

逻辑层包含特定于业务领域的逻辑，是最终

进行业务操作的环节。各服务器通过 Netty 客户

端与服务层建立连接，接收服务层请求并完成相

应业务逻辑，对于耗费资源类操作部分通过服务

层运算完成后再交由逻辑层进一步处理，避免服

务器负载过高影响其他交易系统的操作。

（6）数据层

数据层是操作数据（数据库或者文本文件等）

的操作层，为业务逻辑层或控制层提供数据服务。

对于使用频率较低，数据量庞大的数据，例如审

计信息、历史数据等，使用关系型数据库 MySQL

进行管理，对于使用频率较高，同时对使用场景

的响应时间要求较为严格的关键数据，在存储

MySQL 的同时还运用到了缓存数据库 Redis，一

来提升数据查询的响应速度，二来对 MySQL 进

一步保护，避免出现缓存击穿和雪崩，三来提供

分布式锁，避免集群场景下的服务间状态不感知

导致的业务故障。

2.2 技术框架

自动化代理平台技术选型为 Spring Cloud 微

服务架构和 Netty 框架。

Spring Cloud 是一系列框架的有序集合。它

利用 Spring Boot 的开发便利性巧妙地简化了分

布式系统基础设施的开发，如服务发现注册、配

置中心、消息总线、负载均衡、断路器、数据监

控等。Spring Cloud 作为一套成熟的分布式服务

治理的框架，已得到了广泛的应用。

Netty 是一款用于开发高性能网络系统的

Java 框架，它封装了网络编程的复杂性，使得网

络编程更容易的实现，同时 Netty 作为高度可伸

缩的、异步的、事件驱动的网络编程框架，完美

契合了自动化代理平台对多服务器管理、快速响

应、异步调用的场景需要。

探索与应用

48

自动化代理平台采用网关加二级代理的通信

方式，用户侧请求进入网关后动态路由到对应物

理机房的二级代理，再通过二级代理与服务器之

间的 Netty 连接进行进一步业务操作。同时 Netty

的连接信息通过注册中心进行管理，并动态刷新

到网关，使得网关能将用户请求正确路由到对应

二级代理。如图 2 所示。

二级代理的方式解决不同物理机房间服务

器网络不互通的安全需求，机房中使用 Netty 架

构构建二级代理和服务器的连接。基于 Netty 无

连接数据报套接字支持和相较 Java 核心 API 更

高的吞吐量以及更低的延迟，使得二级代理能同

时处理成千上万的并发客户端。客户端创建消息

处理的入站处理器流和出站处理器流，并向服

务端发起建联请求。二级代理作为服务端创建

消息处理的入站处理器流和出站处理器流，并

通过 Channel 完成与客户端的对接。在业务处理

时，二级代理通过目标索引获取到对应服务器的

Channel，使用事件对服务器进行业务指令下发。

注册中心用于统筹全局的服务器信息，作为

特殊的 Netty 客户端与各物理机房的二级代理服

务端建连，实时同步服务器信息并将数据写入本

地数据库中。同时将二级代理与服务器之间的基

本信息存入缓存数据库，并将该缓存数据与网关

实时共享。

自动化代理平台为用户提供 Restful 和 API

两种类型的调用接口，Restful 接口主要用于操作

指令，如服务升级、信息采集等，API 接口提供

文件的上传下载。Restful 接口进入网关后，网关

根据指令的服务器信息从缓存中匹配对应的二级

代理，并负载均衡的将请求路由到指定二级代理。

API 接口需要用户系统导入自动化代理平台为用

AgentRegister 主要有两个作用，一是作为 Netty 客户端的注册中心，对 Netty 连接状态进行监控管理，

二是为网关层提供动态的 Netty 连接信息，是实现动态路由的关键。

（5）逻辑层

逻辑层包含特定于业务领域的逻辑，是最终进行业务操作的环节。各服务器通过 Netty 客户端与服务

层建立连接，接收服务层请求并完成相应业务逻辑，对于耗费资源类操作部分通过服务层运算完成后再交

由逻辑层进一步处理，避免服务器负载过高影响其他交易系统的操作。

（6）数据层

数据层是操作数据（数据库或者文本文件等）的操作层，为业务逻辑层或控制层提供数据服务。对于

使用频率较低，数据量庞大的数据，例如审计信息、历史数据等，使用关系型数据库 MySQL 进行管理，

对于使用频率较高，同时对使用场景的响应时间要求较为严格的关键数据，在存储 MySQL 的同时还运用

到了缓存数据库 Redis，一来提升数据查询的响应速度，二来对 MySQL 进一步保护，避免出现缓存击穿和

雪崩，三来提供分布式锁，避免集群场景下的服务间状态不感知导致的业务故障。

2.2 <=>7

自动化代理平台技术选型为 Spring Cloud 微服务架构和 Netty 框架。

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统

基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。Spring Cloud

作为一套成熟的分布式服务治理的框架，已得到了广泛的应用。

Netty 是一款用于开发高性能网络系统的 Java 框架，它封装了网络编程的复杂性，使得网络编程更容

易的实现，同时 Netty 作为高度可伸缩的、异步的、事件驱动的网络编程框架，完美契合了自动化代理平

台对多服务器管理、快速响应、异步调用的场景需要。

自动化代理平台采用网关加二级代理的通信方式，用户侧请求进入网关后动态路由到对应物理机房的

二级代理，再通过二级代理与服务器之间的 Netty 连接进行进一步业务操作。同时 Netty 的连接信息通过注

册中心进行管理，并动态刷新到网关，使得网关能将用户请求正确路由到对应二级代理。如下图所示：

图 2 自动化代理平台架构图

二级代理的方式解决不同物理机房间服务器网络不互通的安全需求，机房中使用 Netty 架构构建二级

代理和服务器的连接。基于 Netty 无连接数据报套接字支持和相较 Java 核心 API 更高的吞吐量以及更低的

延迟，使得二级代理能同时处理成千上万的并发客户端。客户端创建消息处理的入站处理器流和出站处理

器流，并向服务端发起建联请求。二级代理作为服务端创建消息处理的入站处理器流和出站处理器流，并

通过 Channel 完成与客户端的对接。在业务处理时，二级代理通过目标索引获取到对应服务器的 Channel，

图 2 ：自动化代理平台架构图 使用事件对服务器进行业务指令下发。

图 3 自动化代理平台消息流转图

注册中心用于统筹全局的服务器信息，作为特殊的 Netty 客户端与各物理机房的二级代理服务端建连，

实时同步服务器信息并将数据写入本地数据库中。同时将二级代理与服务器之间的基本信息存入缓存数据

库，并将该缓存数据与网关实时共享。

自动化代理平台为用户提供Restful和API两种类型的调用接口Restful接口主要用于操作指令如图 3 ：自动化代理平台消息流转图