主管：上海证券交易所

主办：上交所技术有限责任公司

总编：黄红元

副总编：徐毅林

执行主编：王泊、蒋凯、王东明

责任编辑：

黄俊杰、朱立、徐丹、孙增

上海市浦东南路 528 号

邮编：200120

电话：021-68813289 021-68800293

传真：021-68813188

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

内刊 2018 年第一期（总第 30 期）

准印证号 ：沪（K）0671

NO.1监管科技（RegTech）侧重“合规”，是金融机构利用新技术（大数据、云计算、人

工智能等）更加有效和高效地解决监管合规问题，减少不断上升的合规费用；监管科技

（SupTech）关注“监管”，是监管机构基于（大数据、云计算、人工智能等）新兴科技，

主要用于维护金融体系的安全稳定，实现金融机构的稳健经营以及保护金融消费者权利。

随着我国资本市场快速发展，规模不断扩大，传统的监管方式已无法满足日益变化

的监管需求；同时金融科技的快速发展带来的业务的融合，对监管模式提出了新的挑战；

加之金融开放的国际化程度日益提高，现有的金融监管一定程度上受到跨境金融科技运作

方式的冲击。在内外因素不断交织变化的背景下，由中国证监会统筹指导，证券期货行业

共同参与推进实施的监管科技建设，势在必行。

本季度《交易技术前沿》以监管科技为专刊，探索证券期货业监管科技方面的业务

场景和技术手段。感谢各位作者的观点和分享，希望在行业监管科技建设过程中，收获你

们在组织、技术、业务等层面更多的见解。

《交易技术前沿》编辑部

2018 年 4 月 18 日

篇首语

交易技术前沿THE FORELAND OF TRADING TECHNOLOGY

扫描在线浏览

内部资料 免费交流

“本刊物仅为内部交流只用，部分图片或文字来源于互联网等公开渠道，其版权归属原作者所有。如有版权相关事宜，请发邮件至 ftt.editor@see.com.cn”

本期热点Focus

本期热点Focus

1 面向证券交易结算的智能运维研究与实践

2 区块链技术在 OTC 柜台市场的创新应用

3 S-SDLC 在证券公司中的探索和实践

4 浅谈移动安全感知平台在证券行业的应用

4

10

17

24

目录

资讯I nformation12 监管科技全球追踪 72

行业观察observation

9 金融行业的舆情信息监测

10 证券行业大数据测试技术初探

11 基于事件驱动架构的企业级应用集成方法探究

57

61

67

实践探索Explore

5 商业银行数据中心基础设施云与防火墙、负载均衡集成实践的研究

6 分布式缓存 Redis Cluster 在华泰证券的探索与实践

7 基于 Kafka 的实时盯盘系统设计概述

8 OPENCL 开发 FPGA 应用的路径探索

34

41

45

51

1 面向证券交易结算的智能运维研究与实践

2 区块链技术在 OTC 柜台市场的创新应用

3 S-SDLC 在证券公司中的探索和实践

4 浅谈移动安全感知平台在证券行业的应用

智能运维架构。

2 智能运维发展简介

早期的运维工作大部分是由运

维人员手工完成，主要工作包括对

系统运行状态和性能指标的监控、

系统的上线及变更等。这种运维模

式不仅低效，也消耗了大量的人力

资源。

随着技术系统的发展和用户数

量的规模逐渐扩大，低效的手工运

维方式不能满足运维的需要，因此

出现了利用工具，比如自动化脚本

或程序，来完成重复性的运维工作。

自动化运维就是利用工具来实现大

规模和批量化的操作，其本质是基

于业领域知识和运维场景领域知识

的专家系统，比如利用脚本实现分

布式系统的监控，并对获取的日志

实施自动化处理。自动化运维极大

地减少了人力成本，降低了操作风

险，提高了运维效率。自动化运维

一方面提升了运维效率，但另一方

面将开发和运维分割，从而导致新

功能快速部署与异常之间的矛盾对

立，降低了技术系统整体效率。

为 了 解 决 开 发 与 运 维 矛

盾，开发运维一体化（DevOps，Development & Operations）应运而

生。DevOps 不再硬性区分开发和

运维，而是将开发运维工作合二为

一，开发人员亦是运维人员。如在

开发过程中，在代码中设置监控点，

以产生监控数据，由开发人员在系

统部署与运行过程中进行异常定位

和分析。DevOps 能有效提升研发

运维的效率，但随着互联网系统数

据规模的急剧膨胀，以及服务类型

的复杂多样，基于专家系统的自动

运维及 DevOps 对于大规模的运维

逐渐变得力不从心。

智 能 运 维（AIOps， Artificial Intelligence for IT Operations）是指

通过机器学习等人工智能算法，自

动地从海量运维数据中学习并总结

规则，并作出决策的运维方式。智

能运维能快速分析处理海量数据，

并得出有效的运维决策，执行自动

化脚本以实现对系统的整体运维，

因此能有效运维大规模系统。

3 智能运维典型的应用场景

智能运维作为近几年新生的运

维方向，其本质是用人工智能算法

在多个方面替代人为的行为，其所

面向的应用场景仍然与现有的运维

场景相似，都可以根据事件的不同

分为三大类，分别为针对历史事件、

针对当前事件以及针对未来事件的

智能运维。

针对历史事件的智能运维是

对已经发生的历史事件和历史日志

进行分析，实现对单系统行为或多

系统关联关系的刻画。针对当前事

件的智能运维是在已有的系统行为

特征的基础上，对实时异常事件进

行分析，以尽快确定异常事件的原

因及影响，并采取对应的决策以恢

复系统。针对未来事件的智能运维

则是在当前与历史事件分析的基础

上，对将来的功能异常或性能异常

进行概率性预测，并自主进行自适

应的控制，以规避可能发生的概率

性事件，保障系统安全稳定运行。

本节将分别从上述三个方面说明几

类典型的智能运维场景。

3.1 分析分析是对已经发生的历史事件

和历史日志进行处理的过程，分析

的结果是得到对系统个体行为的刻

画，或者多系统关联关系的刻画。

智能运维分析包括影响性能的 KPI指标瓶颈分析、故障失效传播链分

析等。

（1）KPI 指标瓶颈分析

关 键 性 能 指 标（Key Perfor-mance Indicator，KPI） 瓶 颈 分 析

是对影响系统性能的众多因素进行

分析，以期找出关键性因素，为后

续性能调优给出充分依据。在数据

规模较小的时候，运维人员可以通

过手动过滤和选择，发现影响关键

性能指标的因素组合。但在大规模

数据时，若某个关键性能指标有百

亿条数据，则可采用机器学习算法

来自动挖掘数据背后的主要影响因

素，以定位系统瓶颈。目前，可以

采用的机器学习算法有层次聚类算

法、决策树、聚类树（CLTree）等

方法。

（2）故障失效传播链分析

故障失效传播链分析是对现象

即失效进行回本溯源的分析，查找

引起该失效的可能的故障原因。单

系统的故障失效传播链可以通过对

程序方法的调用关系分析，得到可

能的故障或漏洞原因。但在分布式

系统中，各个系统都有相互依赖关

系，某个系统的异常会导致其他系

统甚至整个系统的失效，如分布式

系统中某一计算节点硬盘出现读写

异常，有可能导致整个分布式系统

服务变为不可用。而由于分布式系

统中软件模块依赖关系过于复杂，

利用人工方法构建故障失效传播链

异常困难。

一种用于故障失效传播链的

智能分析方法是基于故障树的分析

方法，通过模块调用链获得模块之

间逻辑调用关系，以及配置信息所

获得的物理模块的关联关系，构成

可能的故障树用以描述故障传播

面向证券交易结算的智能运维研究与实践

本期热点交易技术前沿Focus The Foreland of Trading Technology

4 5

陈林博 何支军 颜挺进 / 中国证券登记结算有限责任公司上海分公司技术开发部，上海 200120

1 背景

随着证券行业的发展，支撑业

务的技术系统也在逐渐壮大，各个

业务之间耦合度的增加，从而导致

上交所、深交所、港交所、结算公

司、证券公司、结算参与人等技术

系统内部及其相互之间的耦合度也

在逐渐增加，系统运维的要求在增

加，异常处理的时间窗口在减少。

常规的自动化运维也越来越难以为

继，而智能运维则是解决这一挑战

的必经途径。

运维是对系统所产生的海量检

测日志进行分析决策，并通过人工

或自动化维护手段，将系统从异常

的状态恢复到正常状态。运维从人

工、自动运维发展到开发运维一体

化，运维的发展过程其实也是分析

决策从纯手工发展到自动过程。而

近几年人工智能已经在计算机视

觉、自然语言理解识别等方面成功

商业化，将人工智能引入运维目前

仍是最新的研究动态。但在 Gartner相关报道中，在 2016 年智能运维

的部署率已达到 5%，预计 2019 年

智能运维的全球部署率可以达到

25%。

基于上述原因，本文在介绍

智能运维及其典型应用场景的基础

上，基于中国结算上海分公司现有

的自动化运维架构，结合人工智能

发展趋势，提出了面向证券结算的

链。利用机器学习的方法，对该故

障树进行联动分析与剪枝，形成最

终的子树，即故障失效传播链。其

他的算法，包括 FP-Growth、Apri-ori、随机森林、Pearson 关联分析，

J-Measure，Two-sample test 等。

3.2 检测检测是对当前的日志或事件进

行分析，以查找出异常并分析产生

异常的故障原因。在实时智能运维

中，首先是要检测出异常，其次是

分析异常所产生原因，定位故障。

因此智能运维检测可包含异常检

测、异常聚类、故障定位等。

（1）智能异常检测

人工异常检测是通过人类的后

天形成先验知识，对产生的异常行

为进行分析判断是否为异常。智能

异常检测通过对已有的异常事件进

行标注，用无监督异常检测及基于

算法的工具，在历史日志中自动搜

索匹配已标注的异常事件，以此训

练机器，最终实现机器对异常的自

动判断与检测。

一种典型的应用是 KPI 异常检

测。KPI 异常检测是检测系统中突

然出现的 KPI 性能指标的异常（如

突增、突降、抖动），这种持续时

间短的 KPI 抖动并不会立刻对系统

造成影响，但意味存在一些潜在的

故障，如网络故障、服务器故障、

配置错误、缺陷版本上线、网络过

载、服务器过载、外部攻击等。因

此需对这类异常进行检测，以避免

风险。常用的检测算法有基于窗口

的异常检测算法，例如奇异谱变换

(singular spectrum transform) ；基于

近似性的异常检测算法；基于预测

的异常检测算法，例如 Holt-Winters方法、时序分解方法、线性回归方

法、支持向量回归等；基于隐式马

尔科夫模型的异常检测算法；基于

分段的异常检测算法；基于机器学

习（集成学习）的异常检测算法等。

（2）异常报警聚合

在运维过程中，容易出现两个

极端的监控现象，一个极端是日志

较少，另一极端则是日志过多，导

致监控报警过多。由于目前所监控

的指标较多，粒度较细，因此容易

造成报警信息过多，异常报警冗余。

异常报警聚合是将冗余的报警信息

进行聚合，将其处理成精简的报警

信息，如将 100 个关联性较强异常

报警聚合成 5 个独立的报警信息。

聚合算法包括各个系统拓扑关系的

层次分析算法、基于挖掘的关系聚

合、基于故障传播链的报警聚合等。

（3）故障原因分析

故障原因分析是基于准确的异

常报警基础上，分析查找异常的发

生原因，定位故障并修复。它是对

前述故障失效传播链、智能异常检

测、异常报警聚合的综合运用，当

异常被检测时，通过异常报警聚合

缩小异常的范围，然后通过故障失

效传播链找到可能的发生故障原

因。在此过程中，也可以采用机器

学习的方法，将所有可能的故障进

行模拟，依据已有的失效传播链建

立学习模型，根据实际检测的异常

指标进一步缩小故障的范围。常用

的算法有随机森林，故障指纹构建，

逻辑回归，马尔科夫链，狄利克雷

过程等方法。

3.3 预测预测是基于历史经验的基础

上，使用多种模型或方法对现有的

系统状态进行分析，判断未来某一

段时间内发生失效的概率。预测是

一种主动异常管理的方式，准确度

高的预测能提高服务的稳定性。通

过智能预测的结果，运维人员可采

用多种运维手段，如切换流量、替

换设备等方式规避系统失效。目前，

学术界和工业界已经提出了大量的

预测方法，典型的方法有基于故障

特征的预测、基于旁路异常的预测，

两种方法都由离线学习和在线预测

两个阶段组成。

基于故障特征的预测是在离线

状态下从历史系统日志中通过机器

学习算法提取出异常特征，对模型

进行训练。在在线预测阶段，将实

时的运行状态信息与模型中的异常

特征进行匹配，从而确定未来某时

间段系统失效的概率。基于旁路异

常预测方法与基于故障特征大体相

似，都需通过离线阶段的训练，但

不同的是，前者训练的数据集是系

统非关键性异常，如异常的内存利

用率、CPU 使用率、磁盘 I/O 甚至

是错误的系统调用等，这些异常并

不会直接导致系统失效，但通过故

障传播在系统运行一段时间后可能

导致系统失效，如内存泄露最终导

致系统不可用。上述预测方法所采

用机器学习算法有随机森林算法、

隐式马尔科夫模型、支持向量机等。

3.4 运维闭环理想中的智能运维应用闭环包

括离线和在线两个阶段。在离线状

态下，对历史日志进行分析，得到

基础的运维数据，比如 KPI 瓶颈、

故障失效传播链，并训练检测模型。

在在线检测阶段，利用模型分析处

理实时的日志信息，检测异常并定

位异常，提前预测性能瓶颈、预测

异常发生，给运维人员提供止损的

建议。运维人员通过智能运维提供

的建议，执行自动化脚本将系统恢

复到正常状态。智能运维应用闭环

如下图所示。

本期热点交易技术前沿Focus The Foreland of Trading Technology

6 7

4 面向证券结算的智能运维架构

目前我司已经基本建成自动化

运维体系，但随着创新业务的发展，

各业务之间耦合度增减，市场参与

机构（如上交所、深交所、港交所、

结算公司、证券公司、结算参与人

等）的技术系统内部及其相互之间

的耦合度也在逐渐增加，异常处理

的时间窗口在减少，运维难度逐渐

增大。常规的自动化运维也越来越

难以为继，而智能运维则是解决这

一挑战的有效途径。

考虑到开发与运维成本，智能

运维的建成需循序渐进。目前可行

的技术路线是在已有的自动化运维

基础上，加入人工智能，改变部分

运维场景。智能运维主要用于辅助

运维人员，向运维人员提供参考性

建议，最终仍由运维人员来决策。

4.1 智能运维架构基于智能运维主要用于辅助运

维的设计理念，本文在基于现有的

自动运维架构基础上部分采用了智

能运维的思想，提出面向证券结算

的智能运维，其体系架构如下图所

示：

在上述架构中，两个数据库分

别为实时日志信息库和软件资源管

理（Software System Management, SCM）数据库。其中实时日志信

息库保存软硬件实时产生的日志信

息，SCM 不仅保存所有的软件资产

信息，也保存故障传播失效链，用

以描述软件的依赖关系。智能运维

架构是在已有的自动化运维架构上

增加了智能分析、智能检测及智能

预测的功能模块。智能分析用于在

离线情况下获取故障传播失效链，

智能检测及智能预测则是在线阶段

对外提供检测预测服务，该服务能

被软硬件集中监控所调用，辅助运

维人员作出决策。

4.2 离线智能分析智能分析是对软件源码进行

智能分析，软件各个组件甚至各个

函数之间的依赖关系进行分析，构

建故障失效传播链，因此故障失

效传播链可以作为技术系统的基础

数据，纳入 SCM 中统一管理。当

某一失效发生后，不仅可以根据传

播链回溯查找可能的故障或漏洞原

因，也可以判断该失效对其他相关

组件或系统的影响。如分布式系统

中用于注册服务的定时任务发生了

异常，导致该服务无法正常使用。

可以通过故障失效传播链，既能判

断该异常的起因，也能推断该异常

对其他系统所带来的影响。

智能分析所获取的故障失效传

播链将存储在 SCM 数据库中，不

仅可以在在线阶段用于智能检测及

预测，也能用于自动化测试中。自

动化测试不仅有功能性测试，也包

含了性能测试、可靠性测试等。其

中可靠性测试用于获取系统的可靠

性、可用性、健壮性、安全性等指标。

一种利用故障失效传播链的测试方

本期热点交易技术前沿Focus The Foreland of Trading Technology

8 9

法是基于故障注入的测试方法，它

可根据失效传播链，构造故障用以

测试系统的可靠性。

4.3 智能异常检测智能异常检测一般分为两个阶

段，离线的模型训练阶段和在线的

实时检测阶段，如右图所示。

在模型训练阶段中，以一个

时间段的日志信息为单位，运维人

员对历史及最新的日志数据进行分

析，标注异常的信息。检测器处理

日志数据并提取出多个特征值，由

于提取出的特征值可能存在无关特

征或冗余特征，因此可以通过机器

学习算法，如随机森林，对提取出

的多个特征值进行优化。最后将提

取出的特征以及运维人员标注的异

常数据训练出异常分类器。

在实施检测阶段，利用检测器

提取实时日志信息中特征，并用训

练出的异常分类器根据特征判断是

否为异常。将可能的异常报送运维

人员，并由运维人员最终确定是否

为异常。新的日志信息中出现新的

异常类型，将被运维人员添加到故

障案例中，并重新生成新的异常分

类器，以提高分类器识别能力。

4.4 智能异常预测智能异常预测服务是基于历史

日志信息、故障失效传播链以及当

前实时日志信息的分析与判断上，

预测未来某时间段内发生异常或者

失效的概率。智能异常预测也分为

两个阶段，离线的模型训练阶段和

在线的异常预测阶段，如右图所示。

由于预测是针对未来某个时间

段内的出现异常的概率，因此需将

连续的时间分割成较小的时间片，

转换为离散的时间序列，将异常预

测问题转换成时间片分类问题。即

根据时间片的关联消息序列，判断

该时间片是否会出现异常。

在离线模型训练阶段，从历史

日志中根据时间片进行分类，选择

合适的消息模板，构建模板集。如

可构建高频时间窗口（5 秒、10 秒、

30 秒时间片）或低频时间窗口（1分钟、5 分钟、10 分钟等），以不

同的时间片构造多个消息模板。将

历史日志，根据不同的消息模板，

转换成离散的日志片段，并从中提

取出特征值。同时，基于历史的故

障案列，采用机器学习算法（如随

机森林）训练模型。

在异常预测阶段，从实时日

志中根据模板集提取不同的模板参

数，用于获取不同时间片的特征值，

使用训练后的预测模型确定在未来

不同的时间片段内发生异常的可能

性。

5 总结

本文阐述了运维发展历程，介

绍了智能运维的定义与特点，并分

析研究了智能运维典型应用场景，

在此基础上，结合证券结算系统的

自身特点，提出面向证券结算的智

能运维架构，指出了智能运维落地

方向。

在基于机器学习的智能运维框

架下，人工智能将逐渐成为运维人

员的高效可靠助手。但在技术系统

运维中，人的作用仍然处于主导地

位。随着智能运维的发展与普及，

运维工程师逐渐转型为大数据工程

师，负责搭建大数据基础架构，开

发和集成数据采集程序和自动化执

行脚本，并高效实现人工智能算法。

不只是人员的转型，智能运维的引

入同时也会带来运维流程、规范、

组织架构等多方面的运维体系转

型。虽然转型期间的困难较多，但

机遇也同样存在。智能运维的应用

不仅能使企业的技术系统解决大数

据、多业务等现实运维压力，也会

使极大减少运维成本，并使运维人

员从繁琐的重复性工作中解脱。因

此，智能运维在证券结算系统，乃

至在证券技术行业都有可以预见的

光明前景。

参考文献 :

[1] 裴丹，基于机器学习的智能运维，APMCon，2016

[2] Liu D, Zhao Y, Xu H, et al.Opprentice: Towards Practical and Automatic Anomaly Detection Through Machine

Learning, 2015

[3] Liu D, Zhao Y, Sui K, et al. FOCUS: Shedding Light on the High Search Response Time in the Wild, 2016

[4] R Ding, Q Wang, Y Dang, et al. YADING: Fast Clustering of Large-Scale Time Series Data, 2015

[5] N Laptev, S Amizadeh, I Flint. Generic and Scalable Framework for Automated Time-series Anomaly Detection,

2015

本期热点交易技术前沿Focus The Foreland of Trading Technology

10 11

区块链技术在OTC柜台市场的创新应用陈杰 吴鑫涛 / 国泰君安证券股份有限公司 邮箱：chenjie016803@gtjas.com

一、区块链在金融领域的快速发展

近年来，区块链技术在金融

业界受到高度关注。早在 2015 年，

Nasdaq 便推出基于区块链的私募

股权市场 Linq。此后英国、新加

坡、马来西亚等国相继推出“监管

沙盒”，为业务创新提供安全测试

环境。国内，央行率先进行了区块

链相关探索并成功测试基于区块链

的数字票据交易平台。中国邮储携

手 IBM 成功上线基于区块链技术

的资产托管系统。百度金融联合长

安新生、天风证券发行首单基于区

块链的场内 ABS。贵阳启动国内首

个区块链金融沙盒计划，青岛上线

首个区块链产业沙盒“泰山沙盒”。

埃森哲在《银行区块链投资价值分

析报告》中提到，使用区块链技术

预计可将基础设施成本平均降低约

30%。在证券交易领域，区块链有

望降低清算和结算成本。此外根据

麦肯锡区块链发展报告预计，在贸

易金融、跨境支付、OTC 衍生品

市场、KYC/AML 管理、身份欺诈

等案例中区块链将产生 800 到 1100亿美元的收益，报告同时指出银行

业正迅速向区块链技术领域注入资

金，预计在 2019 年达 4 亿美元。

二、区块链在 OTC 柜台交易市场的应用

2.1 OTC 柜台交易流程现状及痛点

OTC 柜台市场是我国多层次场

外交易市场的重要组成部分，对加

快完善资本市场体系建设具有重要

意义。OTC 柜台市场是证券公司为

与特定交易对手方或投资者在集中

交易场所之外进行交易所提供服务

的场所或平台。OTC 柜台业务流程

主要包括产品注册、份额登记、产

品认购、资产转让、清算与交收等。

1）产品注册

OTC 金融产品属性通常包含

产品代码、产品净值、产品收益

率、产品期限、产品风险等级、产

品合同附件等，业务人员需要在产

品发行前期将相关材料分发至各部

门，并在 OTC 交易系统、产品中心、

CA 管理中心等多个系统进行录入

和维护，容易出现各方材料维护不

一致情况。同时由于产品信息手工

录入，工作量较大时易出现录入错

误。此外产品数据从源系统同步至

销售平台过程中，中间往往经过多

个系统加工和处理，数据同步效率

较低、延迟较大，且增加了故障发

生概率。

2）产品认购

客户通过网上销售平台进入系

统，认购前需先进行资金账户、柜

台市场产品账户等相关账户的开

通，然后签署产品合同、认购协议

等相关文件，并完成适当性要求相

关的操作流程。系统最后对客户进

行条件检查与确认，通过后客户方

可对产品实行认购。客户完成缴款

后，上传认购凭证等文件至系统保

存，同时系统将柜台产品资产份额

登记至该客户名下。由于当前 OTC交易系统多与其他系统存在关联，

客户无法在单个系统集中办理所有

业务，而购买产品需预先在各个系

统签署协议并开通账户。如在集中

交易系统开通资金账户，在 OTC系统开通 OTC 账户，客户信息散

落在各系统难以有效维护，当出现

客户信息在各系统维护不一致时将

可能会导致客户购买流程中断。

3）资产转让

客户在满足相关转让条件情况

下，可将持有的 OTC 柜台产品进

行转让。客户需签署相关协议，在

系统进行委托操作，通过申报行情

配对或互报配对进行匹配成交。目

前资产转让中通过中心化交易系统

完成，交易双方都需先将请求发送

至交易系统进行后续处理，相比买

卖双方直接交易效率较低，同时在

高并发交易情况下中心化交易系统

压力较大，一旦系统不可用，将带

来巨大损失。

4）清算与交收

清算和证券交收是根据成交结

果确定和履行交易各方权利义务的

过程，属于证券交易后环节，清算

与交收统称为结算。客户的 OTC金融产品资产需进行资金清算，在

完成清算后根据清算结果，交易双

方通过转移证券和资金来履行相关

的债权债务。只有完成交收之后，

一笔证券交易才算真正完成。目前

结算效率较低、耗时较长，并且账

户信息和结算指令时常变化，沟通

和人工干预成本较大，此外在交易

结算过程中还面临着因额外操作带

来的风险。

5）互联互通

柜台市场的互联互通目前主

要通过机构间私募产品报价与服务

系统完成，中证报价提供了机构间

私募产品报价与服务系统（报价系

统），为报价系统参与人提供私募

产品报价、发行、转让等相关服务，

实现机构间资源共享。但这种中心

化模式不仅给中心系统带来压力，

同时也降低了柜台市场间协作的效

率，无法实现券商间资源的高效共

享。

6）合规监管

交易留痕，对于周期性的合规

审查，各系统在业务协作过程中易

出现数据丢失，如销售平台的合规

本期热点交易技术前沿Focus The Foreland of Trading Technology

12 13

性操作数据未及时传送后台保存。

此外各证券公司 OTC 柜台往往自

成体系，结构分散不利于监管，出

现问题往往只能事后报备。

7）其他

证券公司各分支营业部分布

在各地，现有中心化系统使得部分

现场办理的业务存在较多延迟或故

障。

2.2 区块链技术在 OTC 柜台交易中的创新应用

区块链按开放程度通常可分为

三类：公有链、联盟链和私有链，

联盟链和私有链同属于许可制区块

链，与公有链一个主要区别在于具

有准入准出机制。区块链在金融行

业应用需结合金融生态、客户行为、

监管要求等。利用区块链技术改进

OTC 柜台交易业务流程，必须由联

盟内成员实现对区块链的业务治理

与技术治理，包括联盟链成员的准

入准出、角色管理、隐私保护等，

技术选型上我们推荐使用联盟链或

私有链。

考虑目前 OTC 柜台交易系统

大多都关联其他业务系统，如账户

系统、登记托管系统、清算交收系

统、销售平台等。摒弃原有系统而

选择在区块链上重建所有业务流

程，代价较高且风险较大。故推荐

结合现有系统，分析业务痛点并结

合区块链特性，将部分业务环节迁

移至区块链上，实现使用区块链技

术对 OTC 柜台业务流程进行改进

与创新。

OTC 柜台交易主要业务环节

包括产品注册、份额登记、产品认

购、资产转让、清算等，多数环节

在券商内部协作完成。券商内部可

选择私有链搭建内部区块链平台，

协作各方作为私有链节点接入进行

协作，私有链运营管理由内部相关

部门负责。私有链平台除业务协作

外，风控合规等部门可通过接入节

点进行业务监测与控制。 此外，基

于特定的联盟链平台，包括券商在

内的各金融机构可组建并加入联盟

链，基于联盟链实现互联互通的

OTC 场外金融产品交易平台。各金

融机构可将私有链或自有柜台发行

的金融产品导入联盟链平台，通过

联盟链共识后在联盟成员间共享所

发行的产品。对于联盟链的运营管

理，可由联盟委员会发起成立运营

管理组织，负责联盟链准入准出、

权限管理、日常管理等。根据各机

构在联盟链协作中承担的权利与义

务，运营管理组织确定其角色并分

配相应的权限。此外对节点准入准

出安全性，运营管理组织除进行审

核外，还应采用 CA 签发 UKEY 或

高级数字证书等形式予以保证。 联盟链上，监管机构等作为特

权节点接入联盟链网络，特权节点

可不参与具体业务，但具备看穿与

介入联盟链的能力，从而满足穿透

式审查与监管的要求。联盟链上其

他机构如评级机构负责对上链资产

出具信用评级报告，登记机构负责

完成账户开立、份额登记等。此外

联盟链上应接入公证、仲裁、法院

等机构的节点，按照证监会发布《证

券期货投资者适当性管理办法》规

定，客户在金融机构办理业务或购

买产品过程中，需要以电子合同方

式进行确认，且金融机构有义务在

纠纷发生时，提供相关举证材料。

故增加以上司法相关节点，客户在

签署完电子合同后，即可将哈希后

的数据同步到上述节点中，做到事

前监管，在线举证。

对区块链在企业应用中，可

考虑进行适当分层，本文主要分为

应用层、区块链中间件、区块链核

心系统。其中应用层涵盖现有业务

系统，通过区块链中间件与区块链

核心系统进行交互，区块链中间件

作为通用组件向上提供统一接入规

范，包含注册、认证、授权、监控

和审计等应用接入的管理。同时通

过路由功能，向下兼容多种异构区

块链账本，为区块链账本的演进提

供可扩展性。区块链核心系统主要

包括平台层和基础层，其中平台层

包括智能合约、合约容器或虚拟机、

共识引擎、区块链管理以及分布式

账本。基础层提供分布式存储、分

布式计算、分布式网络等基础服务。

结合 OTC 柜台通用业务流程

及现有业务痛点，使用区块链技术

进行改进与创新。为避免应用过于

复杂，采用资金在链下，资产在链

上的方案。资金系统在区块链上设图 1 区块链应用示意图

立代理节点，开设“虚拟头寸”进

行链上记账管理。通过“虚拟头寸”

实现链上资产与链下资金关联。当

发生实际支付请求时，通过代理节

点作为“支付网关”调用资金系统

进行支付。

1）产品注册

注册发行前，产品在链下完成

确权后将相应资产份额以及确权电

子资料上传区块链进行登记托管，

实现在区块链上建立对应产品的数

字资产。由于数字资产登记托管在

区块链上，业务协作各方维护同一

份数字资产，解决了原先各方维护

不一致问题。同时产品维护的数据

由于在区块链上，链上各方可及时

校验并发现问题。对于产品数据同

步，由于各方可直接从区块链上获

取共识后的数据，相比原先效率显

著提升，同时有利于减少延迟和故

障。

2）产品认购

客户通过客户端口（需密钥验

证）链入系统，进行产品合同、认

购协议等相关文件签署，完成产品

适当性要求流程后，系统对客户进

行条件检查与确认，随后创建认购

类型智能合约并执行。在执行结果

经全网共识后，系统将客户认购资

产转移至客户账户下，同时调用“支

付网关”完成链下资金支付。OTC业务关联系统通过在区块链上设立

代理节点，认购时客户可在区块链

上集中办理业务。如账户开通通过

链上代理节点开通，账户相关信息

经区块链共识并记账，并同步至链

下业务系统。通过链上集中办理，

原先因业务分散办理，客户信息散

落各系统导致维护不一致问题得到

有效改善。

3）产品转让

客户进行 OTC 产品的转让，

在区块链上签署相关协议后、确定

相关要素后，系统创建转让类型智

能合约，合约内容包括产品转让要

素、双方账户、转让规则等。系统

实时显示所有合约，买方选择并确

认合约后提交，合约被触发并立即

执行。合约执行中通过链上“虚拟

头寸”更新记账，并调用“支付网

关”完成链下资金支付。同时链上

资产份额的登记托管信息通过链上

职能机构的代理节点同步至链下系

统，完成链下确权。链上智能合约

实现了买卖双方直接交易，简化了

原先转让操作流程，在提升效率的

同时也避免了原先中心化系统可能

发生的延迟与故障。

4）清算与交收

现阶段采用资产交易在链上完

成，清算在链下完成的方案。清算

与交收最理想状态为区块链上完成

清算与交收，即各方维护同一个账

本，完成各方账户资产相应增减，

然后结算将资金划转。若清算与交

收直接在链上完成，将有效降低清

算交收延迟，减少操作与存管风险，

实现效率提升。

5）交易留痕

按证监会代销金融产品适当性

要求，客户在购买产品过程中，需

进行客户身份验证，产品适当性匹

配等流程。客户可能需要签署包括

《金融产品不适当及适当警示涵》，

《开放式基金风险揭示书及投资者

权益须知》，《合格投资者承诺书》，

《代销金融产品风险揭示书》，《代

销金融产品说明书》等一系列文件。

使用区块链记录和保存交易过程中

签署的电子合同及操作流水，利用

区块链不可篡改特性维护和保护投

资者合法权益。

图 2 区块链架构示意图

本期热点交易技术前沿Focus The Foreland of Trading Technology

14 15

6）交易溯源

利用区块链可溯源特性，通

过区块链对客户 OTC 产品交易记

录进行溯源，各方通过查询自身控

制节点的账本信息完成产品溯源工

作，无需再向中心化系统发起查询

请求，提升溯源效率。

7）互联互通

除机构间报价转让系统，各机

构可通过将经私有链改造或传统自

建的柜台交易系统接入联盟链，实

现柜台市场互联互通。相比前者的

中心化模式，基于区块链特性可实

现券商柜台间点对点的资源互享，

从而进一步提高产品报价等数据信

息的共享效率，降低信息和交易的

中间环节，提升柜台市场整体协作

效率。

上述实施中面临的难点包括业

务和技术两方面。业务主要包括准

入准出、权限管理、隐私监管等问

题。技术主要包括证券为满足合规

监管需要特有的大数据量存储，以

及系统性能等。针对难点将讨论一

些可供选择的方案。

1）业务难点

1.1）准入准出和权限管理

联盟链上，成员加入或退出

区块链网络需运营管理组织进行审

核，审核过程可参与成员投票表决，

同时监管具有一票否决权。准入准

出控制中，成员身份通过证书、加

密、签名等保证安全。对于权限控

制需先确定角色职责，然后分配对

应权限。除合规监管等特权节点，

其余普通成员节点均需向管理组织

提交材料，由运营管理组织确定其

角色并分配权限。申请方在获得角

色和权限后可在内部进一步细分。

同时将开发与运维等不同岗位技术

人员进行权限隔离，开发人员可查

看应用层数据统计的权限，方便问

题的定位处理，但限制其直接操作

生产环境操作的权限。运维人员负

责实施区块链生产节点的部署和系

统运维，管理链上系统资源，但不

具有获取应用层数据、参与业务交

易的权限。

1.2）隐私

隐私问题主要涉及交易对手方

信息和交易内容的隐私保护。由于

区块链需要共识记账，各节点需要

对交易进行见证，交易的见证又涉

及交易隐私，如某分支机构客户购

买 OTC 产品，不希望该客户信息

及交易内容被分享或泄露。一种可

选择的方案是对交易进行加密，通

过对客户和交易的关键信息加密，

将进行网络广播和共识，然后记入

区块链账本，后续账本数据的使用

再通过线下分发密钥进行解密。

1.3）运维监控

通过区块链系统日志，获取区

块链系统运行过程中关键数据。日

志应涵盖数据库、共识、交易和区

块等多个维度，从而实现对系统运

行状况的全面评估。同时每个维度

应尽可能包含完整过程，例如共识

的日志监控应包括从区块打包、签

名、校验、写入账本的整个过程，

实现交易发起至结束的全程监控。

同时再借助区块链浏览器，实现交

易全景可视化监测。此外区块链系

统还需对日志中的交易信息进行抽

取和分析，对于异常指标的交易数

据进行告警并导入风控系统。为方

便区块链节点日志的管理，可搭建

集中式日志管理平台，进行区块链

日志集中统一管理，并提供设备日

志查询、系统报错信息查询等日志

查询服务。

2）技术难点

2.1）存储

开展 OTC 业务有着较严格的

规定，业务环节涉及客户签署大量

合规性协议文件。此类文件所占存

储空间较大，推荐采用链上只存储

文件哈希值，链下存储文件原文的

方案。对于文件哈希值，采用多种

哈希算法混合并将哈希值与客户关

联。同时在计算文件哈希值中加入

时间戳，以支持客户重复签署文件

的存储。为有效利用链上区块空间，

可建立交易池对交易进行集中区块

打包，避免交易负载量较少或空交

易量的区块。对于链下存储原文件，

可采用基于 IPFS 协议的分布式存储

网络。由于 IPFS 属于新型分布式超

媒体分布协议，对合同、图片、视

频等大文件相对传统集中式文件存

储更加高效可靠，各机构的存储节

点事先安装 IPFS 协议，将存储挂载

至 IPFS 存储网络，通过简洁操作便

可实现文件的快速存储与获取。

2.2）性能

性能关注的主要指标为区块

链交易吞吐量，性能瓶颈通常在共

识和加解密环节。具有准入准出

机制的区块链共识以 BFT 类算法

为主，该类算法消息传播复杂度

较高，共识过程需耗费大量时间

以及网络资源。以 PBFT 算法为例

进行改进，简化 PBFT 流程并采用

DOPS+PBFT 作为改进后的共识机

制，可有效降低消息传播复杂度，

节省网络资源与时间。还可通过每

个节点只处理交易的子集，实现区

块链网络中节点分组与并行记账，

但需处理额外的数据一致性、交易

时序等问题。多通道共识记账是另

一种方案，通道对应一条子区块链，

可根据不同业务将节点加入不同通

道，各通道独立开展业务。分片和

多通道使得节点只处理全网交易子

集，减轻了单节点负担。同时处理

不同交易子集的节点可并行共识、

记账等工作，实现效率的提升。此

外还有侧链技术、内存数据库、内

存撮合等性能提升方案。侧链与多

通道主要区块在于侧链与所属主链

存在业务协作，而后者通常在通道

内独立开展业务。内存数据库即将

数据放在内存中进行直接操作的数

据库，包括内存撮合在内，可降低

I/O 访问频次，提升数据处理速度。

加解密环节上，诸如非对称加解密

等消耗大量计算资源，从而影响交

易吞吐量。处理方案一方面可根据

业务特性减少加解密操作频度。如

业务流程中多个协议的签署，可集

中打包进行加密签名。另一方面可

采购 CPU、FPGA 等硬件进行加解

密计算能力的提升。

此外在实践中还会有许多细节

以及其他问题，如组织的角色权限

如何进一步细分，以满足组织内部

分工管理的需要。又如系统安全问

题，区块链系统自身安全设计达到

要求，但业务流程通常贯穿链上链

下的多个环节，与之关联的链下环

节、链上链下接入点如何保障安全，

需要从整体去考虑和设计。

区块链本质是一个基于 P2P 的

价值传输协议，基于区块链的网络

实现价值的传输，免去了资本市场

的交割清算过程，资产不再是写入

数据库的数值（可串改），而是天

然可信任的虚拟资产且带有可转让

属性。客户掌握的密码成为对资产

行使权利的唯一凭证，相较以往中

心化系统更具有可信任性。结合区

块链改进 OTC 交易流程，通过维

护一致认可的共同账本，使原先需

花费大量成本进行协作的流程变得

简化，金融效率得到提高。联盟链

平台的组织与搭建，各机构在联盟

链平台进行合作，实现券商间信息

的互通共享，为柜台市场间互联互

通提供了新的方案。通过共同维护

的联盟链账本，可方便地实现金融

机构间信息的高效共享，基于区块

链点对点网络，机构间可直接开展

业务合作，弱化或直接绕开中介方，

降低信息和交易的中间环节，实现

金融机构间资源的高效整合，提高

场外市场效率。此外，区块链的不

可篡改、永久有效、可溯源等特性，

使得区块链账本中记录的交易具备

可信性与可用性，为监管审计工作

高效开展提供便利。

三、风控与合规

3.1 风控监管要求金融机构的风险动态

监控需在系统留痕，以确保动态监

控日志的完备性。风控部门可将相

关操作记录通过区块链留痕存证。

此外，通过在区块链上编写智能合

约，设置风险控制阈值进行风险的

实时监测与防范，当交易风险出现

时迅速告警，同时结合监控日志快

速展开定位和分析。

当前风控多结合大数据技术，

但大数据技术目前仍面临数据孤

岛、数据低质等问题。借助区块链

实现数据的互通互享，在数据主权

问题得到有效处理情况下，原先孤

立的数据孤岛通过区块链实现数据

连通与整合。此外因交易经校验和

共识，无效及错误数据将减少，数

据质量得到进一步提高。大数据风

控与区块链的结合，将使得大数据

制定更为精准的风险模型，提高风

险分析与预测能力。

3.2 合规管理当前在经营业绩压力下业务人

员易忽视合规相关规定，同时由于

系统信息缺乏整合，合规稽查工作

较为繁重。基于区块链平台，各分

支机构将合规要求的数据哈希处理

后导入区块链保存，同时原始数据

可存入 IPFS 存储网络，通过标识

链上哈希进行关联。通过区块链和

IPFS 存储网络，实现合规数据的有

效存证与溯源，提升合规稽查工作

的可信度与效率。对新业务的合规

管理，合规部门将出具的相关意见

通过区块链留痕，同时基于区块链

创建业务合规性智能合约，通过智

能合约对业务进行全周期的合规管

理。当合规要求发生变化或需要整

改时，合规部门更新合约中合规状

态，后续业务满足合规要求后再更

新合约状态，合约运行信息需在区

块链留痕以便审查。下面将从适当

性管理、反洗钱与 KYC 等方面作

一些探讨。

1）适当性管理

客户在开通账户或风险测评过

程中，将客户适当性相关信息加密

图 3 适当性匹配示意图

吴佳伟 1，王� 1，倪文亮 1，胡晓明 1，李鹏 1，张嵩 2，庄飞 2，雷兵 2

1 兴业证券股份有限公司，上海 2001352 华泰证券股份有限公司，南京 210019E-mail ：wujiawei@xyzq.com.cn

本期热点交易技术前沿Focus The Foreland of Trading Technology

16 17

参考文献 :

[1] 罗红梅 . 场外交易市场的监管 :1986 ～ 2016 年 [J]. 改革 , 2016(5):101-113.

[2] 蔡维德 , 郁莲 , 王荣 , 等 . 基于区块链的应用系统开发方法研究 [J]. 软件学报 , 2017, 28(6):1474-1487.

[3] 王晓峰 . 基于区块链技术的智能合约网络证券交易模型研究 [J]. 对外经贸 , 2017(4):101-105.

[4] 于文菊 . 区块链技术应用于证券市场的法律监管路径 [J]. 福建金融 , 2017(7):17-21.

[5] 刘思雨 . 我国柜台交易市场建构的问题与解决 [J]. 科技风 , 2016(8):165-165.

[6] 刘瑜恒 , 周沙骑 . 证券区块链的应用探索、问题挑战与监管对策 [J]. 金融监管研究 , 2017(4):89-109.

[7] 埃森哲 . 银行区块链投资价值分析报告 . 2017

[8] ChinaLedger. 中国资本市场分布式总账技术应用白皮书 . 2016

[9] 中国区块链应用研究中心 . 中国区块链行业发展报告 2018. 达沃斯 , 2018

[10] McKinsey&Company. Blockchain in insurance – opportunity or threat? 2016. http://www.mckinsey.com/

industries/financialservices/our-insights/blockchain-in-insurance-opportunityor-threat (Accessed February 2, 2017).

后签名后在区块链上留痕。在提供

存证溯源的同时实现多方适当性信

息共享。产品购买的适当性匹配环

节，产品和客户的适当性信息从区

块链、业务系统等收集获取，同时

还可通过联盟链获取补充信息，为

实现精准匹配提供全面完善的数

据。在将链上链下各渠道获取的适

当性信息收集汇总后，采用智能合

约进行适当性匹配，包括将产品和

客户的适当性信息读取入智能合约

中，按照监管的适当性匹配规则进

行配置，实现自动匹配和监管规则

的自动化管理，形成主动监管机制。

2）反洗钱与 KYC

对反洗钱的预防和监控，可结

合行业成熟的 KYC 制度，将业务

系统采集的 KYC 信息进行脱敏或

加密处理后，链入区块链进行存储，

监管方通过接入区块链进行监管审

计。在进行信息采集或变更工作时，

需机构方和客户在区块链上对采集

信息进行联合签名，做到不可篡改

和不可抵赖。在客户 KYC 认证通

过后，机构为客户申请区块链的数

字身份标识，并作为后续业务交易

的身份凭证。此外为加强认证信息

的完整性和避免重复认证，在数据

主权解决情况下实现联盟链成员间

KYC 信息的共享，提升 KYC 认证

的效率和准确性，降低客户和机构

认证的成本。

四、总结与展望

本文介绍了区块链在 OTC 柜

台交易市场的应用，对现有业务

流程中的痛点进行了分析并提出

结合区块链的解决方案，最后针

对风控、合规进行了探讨。当前

区块链技术还未完全成熟，如智

能合约安全性、隐私保护、跨链

技术等都有待发展完善。随着量

子计算机的发展，未来区块链上

加密的数据也将面临安全问题，

遗留以及新增信息如何保障安全

需要解决方案。目前区块链治理

尚无清晰完整的方案或标准可循，

鉴于当前法律法规尚未完善，建

议借鉴在“监管沙盒”下进行探

索与创新。未来，以区块链为代

表的技术将对金融行业产生深远

影响，同时将可能带来生产关系

的变革。

S-SDLC在证券公司中的探索和实践

月

本期热点交易技术前沿Focus The Foreland of Trading Technology

18 19

一、 引言

信息技术已逐渐成为证券公司

业务发展的驱动力，为了更好地服

务和创新业务，证券公司开始更多

选择自主开发信息系统。在《网络

安全法》中明确建设关键信息基础

设施应当保证安全技术措施同步规

划、同步建设、同步使用，然而目

前证券公司在信息系统开发生命周

期中安全活动常常被忽略或难于开

展，造成多种问题未得到有效解决：

a) 安全问题暴露时间长

大部分证券公司信息安全人员

工作更多的是应急处理信息系统运

行时出现的安全问题，属于事后的

安全问题处理，未在信息系统建设

开始时实施相关安全活动使安全问

题较早解决。安全活动滞后，增加

了信息系统安全问题的暴露时间。

b) 安全活动无重点

证券公司信息资产较多，信息

安全人员较多沉浸在资产的日常安

全维护中，让信息安全人员处于非

常被动状态中。实施安全活动无计

划，无重点，不成体系化，而且实

施效果不尽人意。

c) 安全问题整改成本较高

目前证券公司的安全人员通常

是在系统上线或运行时才开始介入

安全活动，安全问题在此阶段被集

中发现。此时安全问题数量往往较

多，而且此阶段对安全问题进行整

改，需重新安排人力和时间，增加

了安全问题的整改成本，影响了信

息系统上线进度。

d) 安全人员力不从心

证券公司专职安全人员非常有

限，在安全上的人力投入无法和互

联网公司相比，但却又和互联网公

司面临一样的安全风险。在风险面

前，往往让安全人员力不从心。

S-SDLC 从系统建设的需求分

析阶段开始嵌入安全活动，确保信

息系统开发生命周期的每一阶段都

能解决相应的安全问题。本文结合

了证券公司特性，介绍了 S-SDLC在兴业证券股份有限公司的具体实

践，有效解决或缓解了上述问题。

二、 S-SDLC 简介

1、什么是 S-SDLCS-SDLC 的全称为 Secure-Soft-

ware/System Development Life Cy-cle，即系统安全开发生命周期，其

理念来源于微软的 SDL。信息系统

开发生命周期包括需求分析、系统

开发、系统测试、系统上线、系统

运维、系统下线等阶段。S-SDLC的实践是将安全活动嵌入至系统开

发生命周期的每个阶段，系统开发

生命周期的每个阶段都应解决本阶

段的安全问题，从而全面降低安全

风险提升信息系统的安全性。

2、S-SDLC 实践原则S-SDLC 实 践 原 则 是 实 践

S-SDLC 成功与否的决定性因素，即：

S-SDLC 实践中的安全活动应融入公

司现有的系统开发和项目管理流程

中，而不是新建一套针对 S-SDLC的管理流程或系统。若新建一套安

全管理流程，一方面增加安全人员

审核和流程维护的工作量，另一方

面开发和运维人员需重新适应全新

的流程，很大程度上增加了信息系

统开发和运维成本，最终可能导致

S-SDLC 被摒弃以失败告终。

三、 S-SDLC 的建设和实践

1、S-SDLC 总体实践架构本文 S-SDLC 实践将安全活动

嵌入系统开发生命周期需求分析、

系统开发、系统测试、系统上线、

系统运维和系统下线等关键阶段，

为保证每个阶段安全活动的顺利进

行，安全培训伴随整个系统开发生

命周期，如图 1 所示。

系统开发生命周期的每个阶段

均有安全活动来解决发现的安全问

题，完成了本阶段的安全活动才能

进入到下一阶段。S-SDLC 实践流

程如图 2 所示，本流程是从项目和

开发管理流程中提炼出仅包含安全

活动的流程，包含了安全需求、安

全开发、安全开发测试、安全上线、

安全运维和安全下线 6 个阶段，对

应了系统开发生命周期不同阶段。

S-SDLC 实践流程分两条主线，一

条是非产品型外购系统，此类系统

全生命周期都应加入安全活动；另

一条是产品型外购系统，系统购买

方无法介入此类系统的需求、开发

和测试等环节，在上线阶段开始加

入安全活动。

2、S-SDLC 具体实践2.1、安全需求

在系统需求分析时引入安全需

图 1. 安全活动嵌入系统开发生命周期

图 2. S-SDLC 实践流程

随着证券行业高度依赖信息技术，越来越多的证券公司倾向于信息系统的自主

研发。然后大部分证券公司因安全资源有限等原因，在信息系统开发生命周期中往

往忽略了安全活动，或者仅在运行阶段才开展安全活动，造成在信息系统的运行阶

段集中暴露大量安全漏洞，极大地增加了系统安全风险和安全漏洞整改成本。本文

分析了证券公司普遍存在的问题，提出了适用于证券公司的系统安全开发生命周期

（S-SDLC）体系；本文结合兴业证券股份有限公司的信息系统安全开发管理经验，

介绍了 S-SDLC 的具体实践。

关键字：证券公司；系统安全开发生命周期（S-SDLC）；系统安全

本期热点交易技术前沿Focus The Foreland of Trading Technology

20 21

求，使系统具备一定的安全功能而

提高系统安全性是此阶段安全活动

的目标。本阶段的安全需求由业务

需求提出方提出，研发团队和安全

团队共同参与完成安全需求分析。

为方便快捷提出安全需求，本文根

据国家和行业的安全标准制定了信

息系统安全需求分析库，表 1 是信

息系统安全需求分析库中关于认证

和鉴权部分的安全需求。此信息系

统安全需求分析库中的安全需求均

为基本安全功能点，在系统测试阶

段可被研发测试团队作为系统功能

点来测试，无需安全团队参加测试。

安全需求分析库“性质”栏中

“强制”是所有系统应至少提供的

安全需求，“增强”是提供互联网

服务的交易类系统满足强制安全需

求后额外至少提供的安全需求，可

选是所有系统有条件情况下至少满

足的安全需求。若在需求分析过程

中放弃可选安全需求，需求提出方

应提供充分的放弃理由，如：影响

业务、与其他系统不兼容等原因。

此阶段最终形成已选择的安全需求

分析库。

2.2、安全开发

安全开发是在系统具体开发

实施阶段应考虑安全活动，最大限

度使研发团队能够按照安全的编码

方式开发系统。为安全活动能顺利

加入开发阶段并有效提升系统安全

性，主要从以下两方面实施：

a) 编码行为规范化

为研发人员在开发过程中有

章可循，制定了信息系统开发安全

规范，规范包含了身份鉴别、访问

控制、安全审计、敏感信息保护、

WebService 安全要求、移动应用

APP 安全手册和编程安全手册等内

容，从不同方面描述了系统开发时

应执行的安全操作。规范除包含了

一些复杂安全需求外，在编程安全

手册部分从数据输入校验、输出编

码、上传下载、异常处理、代码注

释等方面提供了参考编码样式。图

3 是其中防 SQL 注入漏洞攻击的

Java 参考编码样式。

b) 源代码审计

源代码审计可有效验证开发团

队是否参照开发安全规范编写源代

码。源代码审计依托源代码自动化

检测平台，由研发团队自主进行源

代码测试并形成测试报告。测试结

果只要不包含源代码 TOP 30 缺陷即

可通过，TOP 30 缺陷是根据 OWASP Top10、CWE/SANS Top 25、US-Cert安全编码等国际主流标准和日常渗

透测试结果总结而来。

2.3、安全开发测试

此阶段的安全活动是在开发测

试阶段由研发测试团队来完成，测

试的对象是在需求分析阶段选择的

安全需求功能点。研发测试人员需

根据安全需求功能点设计测试用

例，测试安全需求功能点是否在系

统中开发完成，测试完后需形成能

说明所选择的安全需求功能点已开

发完成的测试报告。

2.4、安全上线

上线前对系统进行全面的安

全体检和加固是保障系统在上线后

表 1. 信息系统安全需求分析库—认证和鉴权

图 3. 防 SQL 注入漏洞攻击的 Java 参考编码样式

表 2. 系统上线前安全测试实施表

表 3. 安全问题整改时限表

能安全运行的重要安全活动。在此

阶段我们主要需要完成两个安全措

施：

a) 上线前的安全测试

根据系统上线后所面对的安全

风险不同，互联网访问的系统和内

网使用的系统在上线前的安全测试

实施方式将有所不同，具体如表 2所示：

b) 环境安全加固

上线前除了对业务应用系统进

行安全测试外，还需对系统运行环

境进行安全加固。我们针对不同的操

作系统、数据库和中间件制定了不

同的安全基线和加固手册，对装机、

软件安装和应用系统部署等环节进

行安全策略配置，为验证安全基线

是否真正落地，结合安全运营中心

（SOC）进行安全策略的扫描，保证

系统上线时的环境足够安全可靠。

2.5、安全运维

在系统运维阶段开始介入安全

活动是目前很多证券公司正在做的

事情。我们在此阶段对安全活动的

实施进行整体分类，采用定期与非

定期结合的方式。在外网系统方面，

实时监控端口开放情况，每月定期

进行全面的安全扫描，非定期地进

行安全渗透测试；在内网系统方面，

非定期进行安全扫描和渗透测试，

定期进行服务器扫描。

此阶段安全问题处理是关键，

及时处理好发现的安全问题可有效

降低安全问题的在系统运行时的暴

露时间。表 3 是根据安全问题风险

程度制定的整改时限表，超出时间

未整改的安全漏洞将进行安全通

告，从管理上施压于系统责任人，

督促其整改。

2.6、安全下线

在系统下线过程中应制定安全

下线规范后流程，能规范处理下线

本期热点交易技术前沿Focus The Foreland of Trading Technology

22 23

图 4. S-SDLC 实践职责分工

图 5. S-SDLC 实践前后对比

图 6. S-SDLC 实践效果

参考文献 ：

[1] 吕晓强 , 张磊 , 汤志刚 . 信息系统开发全生命周期安全管理研究与实践 [J].

金融电子化 ,2016,8:75

[2] ( 美 ) 霍华德 (Howard,M.)( 美 ) 李普纳 (Lipner,S.) 著 . 李兆星 , 原浩 , 张铖

译 . 软件安全开发生命周期 . 电子工业出版社 ,2008-1-1

[3] OWASP. OWASP 安 全 编 码 指 南 . http://www.owasp.org.cn/owasp-

project/secure-coding

[4] OWASP. 轻量级应用安全开发生命周期项目（S-SDLC). http://www.owasp.

org.cn/owasp-project/S-SDLC

[4] RT 0067-2011( 证券期货业信息系统安全等级保护测评要求 )

[5] 中国信息安全测评中心 . 软件安全开发 [DB/OL]. http://wenku.baidu.

com/link?url=BTCBvhDiDap9ZZt51zQ8Dr_4VNNpHDKPutLPdUBfYt0hVCHKX

YikayR0sQRlddxvmFg4Y7JZZU7RArMCAOkkVztc7YpnIrwf0MGAFusvcPC

系统、数据和资源，保障下线后的

数据不泄露，资源可回收等。

四、 S-SDLC 实践总结

本文提出适于证券公司的

S-SDLC 实践是安全管理和安全技

术的融合，从具体实践中可以看出

具有多种优势。

1、安全闭环在安全开发阶段开发人员对信

息系统开发安全规范的执行效果一

方面由源代码审计来验证，另一方

面由上线前的安全测试来验证。在

安全研发测试阶段测试人员对安全

需求功能点的实现进行验证。系统

上线前和运行阶段安全测试发现安

全问题的整改由安全人员进行复核

验证。因此，S-SDLC 的实践自身

存在多个安全闭环，保证安全活动

的实施效果可被验证。

2、安全人员是安全驱动者安全人员在 S-SDLC 的实践中

更多的角色是安全驱动者，驱动业

务人员、研发人员和运维人员实施

安全活动。图 4 是 S-SDLC 实践的

职责分工，可以看出安全人员在整

个系统生命周期中仅安全上线和安

全运维阶段是主导者，其他阶段均

作为协助者出现，适用于证券公司

安全人员少的情况。

3、S-SDLC 实践前后对比和实践效果

S-SDLC 实践前后对比如图 5所示，分别从 4 个方面阐述了实

践 S-SDLC 具有降低漏洞暴露时

间、提高安全措施的实施效率、保

障系统上线进度和降低安全漏洞整

改成本等优势。图 6 分析了部分系

统实践 S-SDLC 的效果，通过实践

S-SDLC 在系统上线前可消除系统

65% 的常见安全漏洞。

五、 展望

S-SDLC 的实践是从信息系统

开发源头开始提高系统安全性的重

要措施。我们将继续研究和完善实

践 S-SDLC，增强 S-SDLC 在证券

公司所有开发场景和开发模式下的

兼容性，将进一步分解安全开发规

范，制定规范化的安全代码样式，

探索证券行业系统安全成熟度评估

体系，为提升证券行业信息安全水

平贡献绵薄之力。

本期热点交易技术前沿Focus The Foreland of Trading Technology

24 25

浅谈移动安全感知平台在证券行业的应用晏强 刘嵩 / 光大证券股份有限公司 信息技术部，邮箱：liusong@ebscn.com

1 移动安全概述

近几年，全球陆续发生重大

的网络安全事件，对社会、企业造

成了巨大的损失。从国内看，党的

十八大以来党中央高度重视网络安

全工作，成立中央网络安全和信息

化领导小组，习总书记做出划时代

的“没有网络安全就没有国家安全”

的重要论断，改变了我国整体网络

安全的面貌。

当前社会正在快速进入数字

化、智能化时代，各种新技术，新

应用层出不穷，带来的安全问题也

层出不穷。目前我们会面临的主要

网络安全攻击包含：

1 ：新型网络犯罪威胁财产和人身安全

在近期举行的全国社会治安综

合治理表彰大会上，有关领导指出，

网络犯罪已成为第一大犯罪类型，

未来绝大对数犯罪都可能借助网络

实施。

随着新技术的不断出现，网

络犯罪的技术手法多种多样。网

络诈骗已经形成非常完善的产业

链条，国内网络诈骗从业者可能

多达 160 万人，从开发制作、批

发零售、到诈骗策划、诈骗实施，

再到分赃销赃，细分工种多达 20多个。网络钓鱼诈骗黑产的年产

值达到上千亿，甚至超出我国网

络安全行业的产值。

2 ：勒索病毒攻击威胁社会稳定和安全

2017 年发生的“WannaCry”勒

索病毒事件是最具代表性的安全事

件，影响全球 150 多个国家。勒索

病毒不但破坏了大量高价值数据，

还导致很多公共服务、基础设施无

法正常运行，严重威胁社会稳定。

勒索病毒已存在多年，但是今

年的“WannaCry”事件，利用“永

恒之蓝”武器将其破坏力推向了高

峰。勒索病毒的高效变现能力，给

全球网络犯罪分子带来巨大启发。

可以预见，未来此类网络恐怖袭击

将大行其道，甚至成为常态。

3 ：网络攻击威胁关键基础设施安全

习总书记指出“金融、能源、

电力、通信、交通等领域的关键信

息基础设施是经济社会运行的神经

中枢，是网络安全的重中之重，也

是可能遭到重点攻击的目标。”

自“震网病毒”被发现至今，

针对关键信息基础设施的网络攻击

活动被频繁曝光，近两年尤为活跃。

网络攻击从信息间的对抗，演变到

对物理域进行破坏、控制，达到与

传统战争同等的火力效果。相比传

统战争，网络战的效率更高，成本

更低。

4 ：网络攻击威胁金融系统安全

金融系统是保证国家经济稳定

运行的基础，金融安全也是国家安

全的重要组成部分。随着互联网及

新技术与金融业务的深入融合，金

融领域面临的网络攻击威胁在不断

增加。

2016 年上半年接连发生了以

孟加拉国央行为代表的一系列发展

中国家央行或大型国有银行被盗事

件，受害者损失高达数千万美元；

下半年又发生了以台湾第一银行

ATM 机吐钞事件为代表的一系列

ATM 机攻击事件。

5 ：网络攻击威胁国家政权安全

网络技术的发展，突破了时空

限制，拓展了传播范围，创新了传

播手段，被用来干涉他国内政，攻

击他国政治制度、煽动社会动乱等

活动，严重危害国家政治安全。

希拉里“邮件门”事件就直接

改变了美国乃至世界的政治格局。

这件事，可以发现人是最薄弱的环

节。

我们看到，线上线下正在深入

融合，互联网成为像水、电和空气

一样的基础设施；网络攻击将会穿

透虚拟空间，直接映射到现实世界；

安全问题已经泛化，我们面临着大

威胁、大挑战，世界已经进入了“大

安全时代”。

信息安全问题已经从单纯的技

术问题上升为政治问题、社会问题，

直接影响主权国家的安全和发展，

关系到社会的和谐稳定，成为国际

关注的焦点。

随着智能手机以及 4G 网络的

普及和金融科技的深入发展，人们

的生活已经被逐步改变，使用手机

支付、办公、购物、娱乐等成为主

流方式。

截至 2017 年 6 月，中国手机

网民规模达 7.24 亿 手机上网使用

率为 96.3%（第 40 次｜中国互联网

络发展状况统计报告）；随着国家

对网络安全的不断重视，以及移动

应用在工作、生活中的快速渗透，

移动安全越来越得到重视，移动安

全技术也将得到迅速的发展。

整体来说，移动应用安全市场

整体处于发展初期阶段，目前移动

安全主要包括三大服务体系：

安全检测：人工渗透测试和自

动化检测是目前常用的检测手段。

安全加固：实现 APP 的整体防

御，包括防反编译、防篡改、防调试、

防截屏、防劫持等。

安全监测：渠道管理、识别仿

冒程序以及大数据分析是安全监测

的常用手段。

随着移动应用安全技术的不断

发展，以及大数据、人工智能、机器

学习等技术的综合运用，移动应用安

全市场未来将在复杂应用的加固保

护方案和移动应用的威胁态势感知

两个方向，而威胁感知技术的运用必

然为移动安全提供有力的支撑。

通过建模推理、机器学习等智

能化手段，基于特征分析深入挖掘

和洞察用户行为和应用状态，有效

发现并阻止攻击行为和网络安全隐

患。从偏于应急响应式的网络安全

防护工作模式，逐步转向主动感知、

预防为先、更为有效的安全防护工

作模式是移动应用安全防范保障发

展的必然过程。

2 证券行业移动安全风险分析

证券业务具有时效性强，用户

分布广，国内网络情况复杂等环境

特点。实时行情 / 资讯是证券公司

最基础也是访问压力最大的服务，

绝大多数券商都在互联网金融云服

务商部署自己的行情系统，根据使

用量进行弹性扩容，适合证券行业

业务波动的特性。证券移动终端用

户也基于云计算、移动互联网技术

本期热点交易技术前沿Focus The Foreland of Trading Technology

26 27

的应用而大幅增长，随之而来的是

层出不穷的移动应用安全问题，交

易劫持、信息泄漏、业务欺诈等一

系列安全事件，造成了大量用户隐

私泄漏、企业经济损失，对企业与

用户都造成了严重的影响。

当前证券企业部署在因特网上

的服务已经成为网络攻击的重要目

标。在移动互联网环境中，移动应

用是企业业务发展的主要载体，对

于企业而言，业务体系不可避免的

面临来自多方的威胁，而作为企业

业务发展的载体，移动应用自然成

为了主要的威胁原点。当证券移动

应用服务遭受攻击时，移动应用终

端会留有非法访问和攻击情况的痕

迹，因此在开展金融网络安全事件

分析定位时，最直接有效的数据来

源移动应用终端的威胁行为数据和

安全事件日志。但由于技术限制，

这些零散和庞大的信息长期以来对

金融网络安全风险防范起到的作用

并没能发挥出来。

区别于银行、电商、游戏等行

业，证券行业具有一定的行业特征，

所关注的移动安全风险点也不尽相

同；银行、电商更关注自动化攻击、

薅羊毛等风险，游戏行业更关注破

解和外挂；而证券行业由于其业务

特点，在关注数据安全的同时，更

关注系统自身的安全性和可用性；

通过分析安全风险对移动交易业务

的影响程度，这里提出证券行业的

六大高危移动安全风险点：

1）APP 被调试、代码注入等

攻击行为

2）运行环境不安全

3）APP 崩溃无法获知原因或

得到有效收集和处理

4）登录撞库攻击

5）交易服务端接口原理被泄露

6）APP 被集成到其它非授权

APP 中

3 证券行业移动安全风险解决方案

根据证券行业面临的六大高危

风险点，结合企业自身的需要，针

对性的提供以下安全保护措施。

3.1 APP 被调试，代码注入等攻击行为

防动态调试保护思路：

通过加固手段，同时对关键函

数进行监控，通过对进程状态，端

口，信号的实时监听探测保护 APP不被动态调试。加固后 APK 在被

动态调试时，需自动退出自身运行。

如：GDB 动态调试。

防动态调试技术原理：

1）加固代码中需实时检测 app进程状态，当发现进程状态处于

traced 状态或者 TracePid 为非自身

进程时，程序退出；

2）加固代码需监控常见调试

程序利用端口，当发现端口被调试

程序给占用时，程序退出；

3）加固代码需捕获调试器信

号 SIGTRAP，SIGCONT 信 号 等，

检测进程是否处于调试状态；

4）加固代码需检查子进程与

主进程建立通信是否异常，是否发

生通信超时或者通信中断等；

防代码注入保护思路：

通过加固手段，防止对加固后

APK 进行运行时内存代码注入攻

击。当进行内存代码注入时，APK需自动退出自身运行。

防代码注入技术原理：

1）加固使用 inotify 接口对内

存文件进行监控，当发现有进程

直接对内存进行操作事件时程序退

出；

2）同时加固对进程 map 中注

入的动态库来源进行判断，通过

hook 关键系统调用，截获注入进程

数据写入和传递。

3.2 运行环境不安全清场保护思路：

通过建立黑白名单机制，对移

动应用运行环境进行清场，保证恶

意应用、病毒、恶意框架存在的终

端无法运行受保护的 APP。清场保护原理：

1 ：可以通过将黑白名单放入

云端的方式，来解决本地黑白名单

反复操作，以及减少工作量，不用

频繁的修改，程序运行后需进行云

端黑白名单的同步对比，以保障黑

白名单的及时性、准确性、灵活性。

黑白名单样本内容主要包括以

下 4 类：

1、 包括现有的各类工具（调

试器、加速器、模拟器、修改器）；

2、 病毒库；

3、 恶意行为库

4、 隐藏 API 库2 ：病毒类清场可以依靠第三

方安全厂商提供的病毒库来作为样

本进行病毒代码的匹配。

3.3 APP 崩溃问题无法得到有效的收集和处理

APP 崩溃解决思路：

建立一套移动应用崩溃信息

管理系统，自动发现反馈机制，监

测应用在用户手机上发生崩溃的情

况，上传相关信息至 web 平台，并

进行数据分析、汇总、展示。

APP 崩溃系统组成：

崩溃系统需包括客户端的信息

搜集引擎和服务端的崩溃信息管理

后台：

1）信息搜集引擎，分为安卓

和 IOS 二种，实现在客户端发生崩

溃时，自动搜集相关信息（包括机

型、系统类型、版本、时间等）并

上传至服务端平台。

2）崩溃信息管理后台：提供

一个管理后台，供 APP 开发人员进

行查看操作。管理后台可以为 APP开人员展示应用崩溃数据，帮助开

发人员进一步研究崩溃原因，并进

行改进。

3.4 登录撞库攻击撞库攻击保护思路：

通过相关感知系统，在 APP 中

捕获关键敏感界面（登录界面等）

的点击频次和点击间隔时间，一旦

发现点击频次过高（超过正常点击

水准）或者点击间隔为固定时间时，

即可判断为面临撞库攻击风险。

撞库攻击保护原理：

1）分析模型建立：需根据企

业自身 APP 应用特点，建立一套独

有的威胁分析模型，该分析模型必

须符合 APP 自身特点，区别自动化

攻击与正常操作，同时需要在一定

时间段内，不断的去完善该模型来

应对不同的威胁和风险。

2）关键数据埋点收集：根据

分析模型中需要收集的数据类型，

在 APP 内部进行预埋点，同时需保

证数据收集的及时性，以便于后台

进行判断和处理。

3）策略下发：因为分析模型

的建立具有变更性，分析模型会随

着业务的变更与攻击手段的更新而

变化，所以数据埋点收集以及分析

策略需要支持下发至终端设备，以

便于支持不断变更的业务及应对新

型攻击手段。

3.5 服务端接口原理被泄露查询接口泄露保护思路：

在需保护的 APP 中，获取特点

文件的哈希值，然后用这个哈希值

结合自有的算法，在服务器端进行

安全校验，校验通过，即代表该查

询属于正常请求，服务器端返回相

关数据即可，反之则不返回任何数

据。

查询接口泄露保护原理：

1）查询接口泄露主要表现在

接口被随意滥用，恶意应用通过查

询接口，发送请求至服务器端，导

致会有数据泄露风险。而通过 APP内部特定文件，通过哈希值来进行

校验，可以保证所有发送的请求来

源是正版 APP 中发送的请求，可有

效避免数据泄露风险。

2）哈希值的校验，需建立在

自有算法的基础上，生成一个新的

校验值，并且算法需做相关防反编

译及数据传输保护，以保证校验值

不被泄露。

3）需对相关算法进行定期更

新，以保证校验值的有效性。

3.6 证券 APP 被集成到其它非授权 APP 中

非授权调用保护思路：

1 ：通过源码加壳、源码分离、

防内存 dump 方式，保证源代码相

关调用逻辑无法被恶意用户或黑客

获知。

2 ：通过黑白名单校验方式，

将已知的非授权应用加入黑名单进

行鉴别。

非授权调用保护原理：

APP 被其他 APP（主应用）调

用一般有两种方式：一种是动态加

载的方式，一种是通过安卓 Intent组件实现。

一种是采用动态加载的方式，

将待加载 APK 反编译，获取 APP启动和调用逻辑后，将处理过的待

加载 APK 放在主应用 APK 的资源

文件中，用户在主应用中即可无感

知启动待加载应用。此类风险的预

防只需要对 APP 做安全加固即可

有效防止，黑客要实现动态加载必

须先破壳，才可分析 APP 相关逻

辑。

另一种方式是通过在 A 工程

中的 activity 点击某按钮启动 B 工

程中的 actvity，此种方法依赖于

Android 的 Intent 组件实现。此方式

是 Android 系统所允许的调用方式；

如果一定要避免对此类行为对 APP造成的影响，需要采用清场保护技

术，将恶意 / 非授权应用加入到清

场黑名单即可。

3.7 防止 Cycript/Runtime 修改风险

通 过 内 核 设 置 进 程 的

TRACED 标志能检测 gdb 或其他

调试器附加到进程，但不能检测

恶意代码，诸如攻击，cycript（或

者其他类似不跟踪的工具）附加

到进程。在代码中实现这些可以

强制攻击者避免使用调试器（这

会让他更麻烦），或者定位修补相

关的检测代码。

保护思路：

通过重载相关方法及多进程相

互监控，以避免安全措施被攻击者

绕过。

保护原理：

1 ：防止 choose( 类名 )在 Cycript 中可以很方便的使用

choose( 类名 ) 来获取到 App 中该类

所有的实例变量，那么我们只需要

重 载 - (NSString *)description 方 法，

让他返回一个空值或自定义语句，

即可保证实例变量的安全性。

2 ：加密内存区块

如果 Cracker 们搜索内存的话，

本期热点交易技术前沿Focus The Foreland of Trading Technology

28 29

还是有可能找到一些数据的，我们

不用的时候加密这块内存，用的时

候再解密，即可保证内存中数据的

安全性。

3.8 本地数据被缓存风险应用软件可能是安全的，但

操作系统中继承的许多特性使得大

量的数据被缓存以便让用户在稍后

使用时更快速和便捷（诸如残余

的 gps 缓存，sqlite 缓存，属性列表

等重要文件，键盘缓存，屏幕系统

截图都能被还原），建议在编写代

码时注意对抗设备上的各类取证措

施。

保护思路：

通过对落地数据加密处理以及

定期做数据清理（主 / 被动方式），

对本地数据进行加密保护。

保护原理：

1 ：落地数据加密处理

对涉及到会落地到手机上的所

有数据进行加密处理，就算 APP 有

数据残留问题产生，这些残留的数

据也是加密的数据，不会造成风险。

2 ：主 / 被动定期数据清理

包括了：APP 主动周期性清理

数据、APP 提供给用户接口可被动

清理数据等。

3.9 数据流量监听风险通过伪造 APN 配置，物理上

的接触可以使攻击者轻易监听目标

设备的移动数据流量。移动流量和

wifi 数据都可以被劫持和监听，从

而监控到用户应用软件收发的 Web数据。中间人攻击并监听时，因移

动浏览器不会像计算机上那样显示

用户期待的可视化指示器使其数据

遭受威胁。同时需考虑 SSL 无法完

全可信。

保护思路：

增加相应的 DNS 及内容防劫

持机制，保证恶意用户无法监听相

关数据流量。

保护原理：

1 ：DNS 防劫持

域名解析是通过 DNS 协议解

析完成，其最终结果就是获取域名

真实的服务器地址。保护措施可采

用 IP 调度的方式，通过域名封装、

动态鉴权、动态 IP 列表、IP 回源

等技术，防止用户域名被运营商或

其他不法分子劫持，有效保护应用

安全。

2 ：内容防劫持

运营商出于利己目的，会按照

一定的策略拦截 HTTP 请求。保护

措施可通过对私有协议进行传输加

密，有效保护用户请求在传输过程

中的安全，避免用户请求被篡改、

注入内容，避免内容劫持带来的损

失。

3.10 未知风险以上六大类风险为证券行业

已知的可预测风险，针对某些未知

风险以及因业务变更导致的新增风

险，需通过相关威胁感知系统进行

分析。

4 威胁感知方案设计

4.1 数据定义威胁传统安全行业中，威胁的定义

来自于已有防护体系的知识库以及

人工的判断分析。分析的重点也只

是针对于当前面临的攻击行为，对

真实业务面临的其他多个维度的威

胁并不关注，所以常常导致安全脱

离业务，威胁感知变成了攻防分析

工具。而证券行业最需要关注的业

务威胁并没有得到合理的分析与解

决。

所以应从数据角度出发，构建

了三大数据采集体系，全方位采集

更广，更细，更新的数据；通过无

监督机器学习算法，让系统在海量

的数据中构建出无限的威胁可能，

然后通过不断的训练，建模与预测，

将系统与企业业务无缝关联，深入

挖掘出基于业务的潜在风险，解码

未来威胁态势。

4.2 主要威胁说明4.2.1恶意威胁行为（见表 1）

图 1 如何定义移动应用威胁场景

4.2.2恶意环境识别（见表 2）

4.2.3APP 崩溃信息收集

移动应用因为性能、适配等问

题导致使用过程中出现响应迟缓、

内存或 CPU 消耗增加、甚至是崩溃

的情况，严重影响用户体验，导致

用户流失。威胁态势感知系统应支

持应用崩溃统计分析，使企业自身

了解应用的性能情况、应用崩溃原

因，从而进行应用性能优化。

崩溃收集信息包括：设备信息、

用户步骤、堆栈信息、控制台信息等

4.2.4基于移动应用的防自动

化攻击

自动化攻击场景下，设备需要

被 Root 或者设备为模拟设备，设

备中需要安装 xposed 框架以便修改

系统配置，业务交易等达到超高频

操作。通过移动威胁态势感知系统，

实现设备 Root 监测、模拟器监测、

xposed 框架监测、业务节点操作频

率监测，监测点可包括如下信息：

页面信息收集：页面 ID、页面

名称、访问时间、离开时间、访问

时长、加载时长、是否首次访问等；

按钮点击收集：按钮 ID、按钮

名称、点击时间、两次点击间隔等；

通过多种监测条件组合形成判

定条件，识别自动化攻击 / 异常行

为。

4.2.5移动应用接口保护

证券行业的 APP 大多数由外部

开发商开发，不排除个别开发商在

其它项目中非授权使用 APP 接口，

进行行情 / 资讯的查询。

威胁感知系统需支持对此类风

险的甄别，可对移动应用的多个文

件采用哈希算法进行校验，校验通

过的移动应用，后端服务器提供相

应的行情 / 资讯服务。实现业务服

务器和威胁感知服务的联动，将非

授权移动应用的请求信息交由威胁

表 1 常见恶意威胁行为

表 2 常见恶意威胁环境

本期热点交易技术前沿Focus The Foreland of Trading Technology

30 31

感知服务器进行分析和处理，获取

威胁的具体详情。

4.2.6APP 非授权被调用

APP 被其他 APP（主应用）调

用一般有两种方式：一种是动态加

载的方式，一种是通过安卓 Intent组件实现。

一种是采用动态加载的方式，

将待加载 APK 反编译，获取 APP启动和调用逻辑后，将处理过的

待加载 APK 放在主应用 APK 的

资源文件中，用户在主应用中即

可无感知启动待加载应用。此类

风险的预防只需要对 APP 做安全

加固即可有效防止，黑客要实现

动态加载必须先破壳，才可分析

APP 相关逻辑。

另一种方式是通过在 A 工程

中的 activity 点击某按钮启动 B 工

程中的 actvity，此种方法依赖于

Android 的 Intent 组件实现。此方式

是 Android 系统所允许的调用方式；

如果一定要避免对此类行为对 APP造成的影响，需要采用清场保护技

术，将恶意 / 非授权应用加入到清

场黑名单即可。

4.3 威胁数据体系我们将威胁数据来源分为三大

数据源体系，分别是自构体系，赋

能体系以及派生体系。

1 ：自构体系指企业内部自构

的数据采集体系，如 APP 中的自埋

点数据，历史数据以及各种业务产

生的日志信息；

2 ：赋能体系指平台为客户提

供的数据采集体系，包括感知 SDK和安全大数据平台提供的数据服

务；

3 ：派生体系指第三发提供的

数据采集体系，包括客户处集成的

第三方 SDK 的数据采集，客户处

件详情，了解威胁产生的本质原因。

4.5 智能分析方法传统安全行业威胁分析方法采

取的强人工干预，需要安全研究员

不间断的对应用数据进行研究或在

安全事故发生后进行针对性分析，

提取特征值并建立新的模型加入到

模型库中。输入新数据后根据已有

的模型库判断是否异常。此方式的

局限性在于模型库中存在的都是已

知的威胁模型，且模型库需要大量

的人工进行维护干预。

移动威胁态势感知系统应采

用机器学习中无监督学习算法进行

威胁建模与分析。无监督式学习

(Unsupervised Learning) 是 人 工 智

能网络的一类算法 (algorithm)，其

目的是去对原始资料进行分类，以

便了解资料内部结构，发现数据之

间的关系规则。有别于监督式机器

学习，无监督式机器学习在进行分

析时并不知道其分析结果是否正确

（即没有监督式增强）。它会主动从

输入数据中找到潜在的类别规则并

建立关系模型，当学习完成并测试

纠正后，新的模型将可应用于新的

案例数据上。

无监督式机器学习特点在于主

动从输入的范例数据中寻找潜在的

规则，代替人为分析，提高分析效

率并存在无限可能结果，最终达到

准确预测的目的。

此处以高考为例，高考的题目

在上考场前我们未必做过，但在高

中三年我们做过很多很多题目，懂

第三方服务平台的数据导入以及从

合作伙伴处获取的相关数据。

4.4 数据应用能力1 ：数据采集能力，移动威胁

态势感知系统主要的数据来源包括

企业自构体系、数据赋能体系与第

三方派生体系。从三大体系中采集

的数据可进行分类，分别为：基础

数据、安全数据、业务数据、竞品

数据、优化数据。其中，基础数据

主要为硬件数据、软件数据、网络

数据、系统日志数据等；安全数据

主要为攻击事件数据；业务数据主

要为业务流程中的关键节点数据、

业务日志数据；竞品数据主要为应

用所处设备终端竞品安装、运行状

态数据；优化数据主要为应用崩溃

日志数据、性能数据。

2 ：数据挖掘能力，采集后的

数据进入数据挖掘阶段，系统采用

了机器学习方法，通过对数据进行

分词，关键信息提取得到关键词数

据，系统将关键词信息与系统内置

标签库进行匹配并得出匹配结果，

匹配结果进行数据分析后识别正确

则进入样本模型库并提供给上层做

分析展示，如果识别错误则进行人

工干预纠错，再将纠正后的正确识

别信息存入样本模型库并提供给上

层做分析展示。随着不断的新数据

的数据输入，机器学习引擎对大量

数据进行训练，建模，预测。不断

完善和提升样本模型准确性及与用

户真实业务的适配性。

3 ：数据应用能力，系统通过

大量的机器学习建立了海量的样本

模型，形成基于企业业务模式下的

行为画像与内容画像。系统根据行

为画像与内容画像建立了多维度的

数据分析模型，包括基础数据分析，

安全数据分析业务数据分析，竞品

数据分析，优化数据分析 5 种自建

分析模型，另外系统提供扩展分析

接口，允许自建分析模型来分析个

性化的威胁数据。

4 ：数据分析能力，独立的数

据分析能力无法对真实的业务威胁

进行关联与闭环，数据决策的意义

在于将分析结果与策略进行智能关

联，当威胁事件发生时及时下发决

策，推动业务系统的策略更新。

5 ：数据展示能力，数据展示

是系统对数据能力的直观表达，系

统通过 dashboard 展示所有数据能

力的综合态势，通过分类数据分析

进入到每种数据能力中进行深度分

析展示，通过数据详情洞穿威胁事

图 2 数据应用

图 3 传统威胁分析方法

解题方法，因此考场上面对陌生问

题也可以算出答案。机器学习的思

路也类似：我们能不能利用一些训

练数据（已经做过的题），使机器

能够利用它们（解题方法）分析未

知数据（高考的题目）？最简单也

最普遍的一类机器学习算法就是分

类。对于分类，输入的训练数据有

特征，有标签。所谓的学习，其本

质就是找到特征和标签间的关系。

这样当有特征而无标签的未知数据

输入时，我们就可以通过已有的关

系得到未知数据标签。在上述的分

类过程中，如果所有训练数据都有

标签，则为有监督学习。如果数据

没有标签，显然就是无监督学习了。

4.5.1安全数据分析

应用安全威胁分为运行安全威

胁与环境安全威胁。运行安全主要

指运行过程的攻击事件威胁，环境

安全主要指应用所处硬件环境、软

件环境、网络环境是否存在潜在威

胁。对应用安全态势分析依托于对

运行安全与环境安全的分析，而运

行与环境安全分析主要通过基础数

据、安全数据两个维度数据进行数

据挖掘实现。

4.5.2业务数据分析

不同应用运行过程中面临不同

的业务威胁。移动威胁态势感知系

统感知 SDK 基于基础数据、安全

数据、业务数据应实现及时发现并

定位业务异常情况。依托基础数据

识别设备身份、地理位置等，依托

安全数据识别设备环境状态，依托

业务数据识别异常点击、函数调用

情况，结合三者可识别异常环境与

异常操作行为，分析定位安全事件，

及时通知企业。

4.5.3运营数据分析

移动威胁态势感知系统对实现

竞品数据、业务数据采集。其中竞

图 4 无监督机器学习分析方法

本期热点Focus

32

品数据主要采集终端安装应用、运

行应用信息，通过黑白名单方式识

别竞品应用并采集相关数据，分析

企业本身应用与竞品应用的用户重

合情况，结合业务场景，分析业务

场景下应用与竞品之间的优略差

别。

4.5.4优化数据分析

企业移动应用自身存在设计缺

陷或因外部环境变化产生不适应等

因素造成应用性能下降，如响应迟

缓、内存或 CPU 消耗增加、甚至

是应用崩溃的情况。移动应用威胁

态势感知系统帮助企业客户采集应

用崩溃日志信息，并通过数据挖掘，

发现应用崩溃原因并修复建议，协

助企业对移动应用的优化。

4.5.5扩展数据分析

移动威胁态势感知系统支持用

户进行扩展数据分析。如已有的数

据分析不能满足客户个性化需求，

客户通过接口对接、数据导入等形

式扩展数据维度，并通过手段关联

方式进行自定义维度的数据分析。

4.5.6基础模板场景分析

移动威胁态势感知系统配置了

基础场景模板，其中包含攻击模板

（框架攻击、调试攻击、注入攻击、

界面劫持攻击）、新增用户留存模

板、崩溃统计模板、攻击综合模板，

支持客户快捷创建场景分析。

4.5.7自定义场景分析

移动威胁态势感知系统支持客

户根据具体场景，通过字段、事件

条件匹配设置，实现场景创建与监

测。

5 总结

通过建立移动威胁态势感知系

统，证券企业可以支持运维人员及

安全人员等查询精准的数据详情，

展示事件全过程。运维人员及安全

人员等可根据数据详情内容进行威

胁原因分析、定位威胁源。

1）启动、运行、切换等全过

程的客户端威胁事件监控

2）可持续自适应的终端环境

安全检测

3）可视化埋点与多维数据统

计

4）实时守护进程与场景定制

化策略

同时，建立移动威胁态势感知

系统，可有效提高证券 APP 的安全

水平，为开发团队在威胁预测、版

本升级、风险项目解决等多方面提

供了数据化的支撑，能有效帮助安

全人员、运维人员及开发人员等第

一时间了解到自身 APP 的威胁程

度，从而第一时间找到解决方案，

所以建立移动安全态势感知体系势

在必行。

本文档主要参考资料如下 ：

中国信息安全 - 中国信息安全测试中心主办（摘要 ：习近平在网信工作座谈会上的讲话全文发表）

第 40 次｜中国互联网络发展状况统计报告

防止 Cycript/Runtime 修改 http://www.cocoachina.com/ios/20150511/11801.html

什么是无监督学习？ https://www.zhihu.com/question/23194489

实践探索Explore

5 商业银行数据中心基础设施云与防火墙、负载均衡集

成实践的研究

6 分布式缓存 Redis Cluster 在华泰证券的探索与实践 7 基于 Kafka 的实时盯盘系统设计概述

8 OPENCL 开发 FPGA 应用的路径探索

34

商业银行数据中心基础设施云与防火墙、负载均衡集成实践的研究

吴仲阳、张新晖、马国祥 / 中国工商银行数据中心（上海） 邮箱：zywu@dccsh.icbc.com.cn

35

交易技术前沿

The Foreland of Trading TechnologyE实践探索Explore

云计算在金融企业的应用不断发展和深入，云网络是云计算中最为基础和重

要的一个环节，如何将传统网络设备和技术集成到云网络环境中是基础设施云的

一个难点。本文对防火墙和负载均衡等四层网络技术之上的设备与基础设施云的

集成进行了深入研究，提出基于 OpenStack Neutron 自定制的集成解决方案，为传

统网络设备集成到基础设施云提供了解决思路，并在大型银行的数据中心云环境

中得到了很好的实践和应用。

关键字：OpenStack、 Neutron 自定制、 基础设施云

一、概述

( 一 ) 现状商业银行数据中心基础设

施云的主流解决方案之一是基于

OpenStack 和 Ceph 等开源软件并

依托自主开发而建立，助力传统金

融行业实现互联网金融战略转型。

OpenStack 对计算、存储和二三层

网络的技术集成支持比较好，而对

于防火墙、负载均衡的支持则相对

较弱。同时由于银行业务安全监管

的要求和应用系统的复杂性，在银

行业的数据中心中大规模使用防火

墙和负载均衡技术。强安全监管和

严格流程的要求导致商业银行 IT 系

统的生产变更数量连年增长。以工

商银行数据中心（上海）为例，每

年仅网络类变更数量的平均增长量

就达到 15%。而这大量变更中，约

有 60%+ 的变更属于防火墙策略变

更和负载均衡变更（见图 1），如此

大体量的变更数量单单依靠人力投

入无法长期维系 , 并且无法满足互

联网金融下的快速响应要求。

为了解决防火墙策略及负载均

衡变更数量多、工作效率低、用户

体验差等问题，商业银行数据中心

普遍采用了一些自动化的手段来提

升运营水平。但是自动化的手段还

是存在如下弊端 : 1、自动化手段往往与基础设

施云 IaaS 脱节和无法联动导致无法

给用户提供自服务能力。

2、自动化手段囿于 IT 流程的

框架限制，变更流程冗长且未有突

破，用户体验改善度有限。

3、自动化手段往往仅满足部

分基础常见的场景，新场景定制化

成本较高，对高级功能不支持。

4、自动化手段仍然将防火墙

和负载均衡策略看成是网络属性，

一般由网络专业团队集中受理实

施，难以完全理解应用并快速响应

其需求。

( 二 ) 思考通过对商业银行数据中心实践

图 1 某商业银行变更情况

中的现状及痛点分析，从用户（用

户可以是租户或者应用维护人员）

的视角对防火墙和负载均衡策略进

行重新思考和推演。假设有租户在

云中申请了一些资源，如虚机、数

据库等 , 租户在这些资源上部署了

相关应用需要对外提供服务，租户

希望能通过自服务的方式来开通防

火墙策略控制从而允许终端用户能

顺利访问服务。随着业务量的增长，

租户就希望能通过自服务的方式采

取负载均衡技术让多个服务实例作

为一个集群来满足业务扩展。

为了满足业务的快速变化和增

长，租户必须能通过自服务的方式

自主、按需地定制和使用基础技术

资源，从而让整个服务流程自然流

畅。以自服务作为目标重新思考相

关技术：

思考 1 ：多租户情况下，云运

营单位集中受理各租户的变更需

求，变更爆发带来的冲击力如何应

对？

思考 2 ：防火墙变更、负载均

衡变更需求到底应该是网络属性，

还是应用属性？

思考 3 ：防火墙本质是应用访

问关系，负载均衡变更是集群关系。

变更的本质是将这些应用语言转化

为网络语言，如何做到不失真，如

何做到可追溯，可回滚？

( 三 ) 诉求通过研究防火墙和负载均衡在

银行业的实践，主要目标是在防火

墙和负载均衡资源共享的前提下实

现租户间安全隔离，同时通过提供

自服务的方式满足租户需求和减轻

多租户下云运营方的压力。具体体

现在几个方面：

1、通过网络设备虚拟化与

OpenStack 权限系统 Keystone 结合

36 37

交易技术前沿

The Foreland of Trading TechnologyE实践探索Explore

目前商业银行数据中心使用的

主流防火墙和负载均衡设备均有基

于多租户模式的设计，均可基于物

理资源给每个租户分配虚拟设备，

每一个虚拟设备之间实现故障隔

离，性能按需分配。

F5 负载均衡设备使用 Partition（router domain）虚拟化技术为多

租户提供技术支撑。通过 Partition（router domain）方式创建的虚拟设

备间网络结构完全隔离，共享物理

CPU 和内存等硬件资源，Partition的数量可到数十万量级。防火墙中

各主流厂商均有相关技术支撑多

租户的虚拟化，如华为 USG 系列

和 Juniper 的 SRX 系统防火墙一台

硬件防火墙可虚拟出上千个 vsys

（vRouter）虚拟防火墙分配给不同

的租户。

3、 多租户隔离安全

计算和存储层面通过 Open-Stack 的租户模式实现资源安全隔

离，每个租户只能访问有权限的资

源。网络层面利用网络设备本身虚

拟化后的资源隔离能力，网络设备

VRF、vsys、vRouter、Partition 等

多种虚拟化技术的安全隔离都非常

成熟，能满足多租户场景的安全控

制要求。

4、 定制 Neutron 的防火墙模

式 FWaaS

OpenStack 中 网 络 支 撑 模 块

Neutron，对防火墙策略进行了建

模 FWaaS（Firewall as a Service）。

实现分权分域控制，多租户间安全

隔离。

2、通过网络设备虚拟化技术，

使用同一套网络设备为多个租户提

供统一的服务，减少设备资源投入。

3、通过用户的自助服务，合

理划分责任界限，简化云使用用户

和云运营单位的管理流程，提升资

源使用的敏捷性。

二、基础设施云与防火墙负载均衡集成实践

( 一 ) 基础设施云与防火墙负载均衡集成的关键技术点

1、 整体架构（见图 2）

角色分为四类：

1）应用维护人员：自助服务

的对象。

2）网络人员：策略安全规则

约定、输入规范制定。

3）安全人员：策略安全规则

约定、策略例外审批。

4）流程管理人员：IT 服务流

程管理。

关联平台 :1）云管理平台：北向提供自

助服务，南向调用 OpenStack API。东西向联动网管平台提供技术支

撑，联动 IT 服务流程平台提供管理

流程。

2）网管平台 : 为云管理平台提

供输入、规则等决策的技术支撑。

4）IT 服务流程平台 : 为云管

理平台提供管理流程。

2、 网络设备虚拟化

通过防火墙、负载均衡虚拟化

技术将一台物理设备虚拟划分为多

台相互独立的逻辑设备，为每个租

户自动分配一套逻辑防火墙、负载

均衡，实现物理共享、逻辑隔离，

提高资源利用率。

图 2 整体架构

图 3 设备虚拟化

OpenStack 在建模的时候着重考虑

通用性，一个模型需要适配所有的

产品。因此目前 OpenStack 原生框

架中针对防火墙仅实现了基本的功

能，目前商业银行数据中心实践中

使用的部分高级功能特性在 FWaaS通用模型中得不到支持，存在不少

差异点。通过研究梳理，OpenStack中常规的模型和商业银行数据中心

生产实践所需要的的功能缺失主要

在下表中，导致该模型无法在实际

中直接集成使用。

基于差异和缺失，对 FWaaS 进

行重新整体设计，引入自定义的数

据结构来支撑高级特性。整体架构

设计分为 Plugin、Driver、Device 三

个部分，整体架构设计如图 4 所示：

Plugin 对 外 提 供 Restful 接口， 接 收 Json 数 据 并 解 析；对

外提供 CLI 接口，接收命令行参

数数据并执行，暴露 RPC 接口

FirewallAgentAPI、FirewallCallbacks满足组件之间的 RPC 调用。

Plugin 调用 Driver 向上层提供

的 create_rule、delete_rule、update_rule 三个接口直接进行防火墙策略

的创建和删除，其余 rule 信息的

维 护 由 Plugin 维 护 在 Neutron 的

DataBase 中。

Driver 对 外 提 供 create_rule、delete_rule、update_rule 三 个 接 口

以供 Plugin 组件调用，接口接收

Json 格式数据，用来满足 Plugin 对

firewall_rule 的创建、修改和删除。

Driver 组件内维护一个 data convert函数，用于上层 json 数据与防火墙

具体配置数据之间的转换。Driver 组件向下负责维护 Device 信息，用

于创建 Device 连接信息、物理防火

墙配置下发及 Device 连接回收等。

Device 为具体物理防火墙，由

防火墙供应商提供。表 1 OpenStack FWaaS 通用模型与商业银行实际中的差异

交易技术前沿E The Foreland of Trading Technology

38 39

实践探索Explore

图 4 FWaaS 自定制模型

为了适配不同厂商的设备，将

FWaaS 中 的 plugin 和 driver 整 体

解耦。定义 FWaaS Plugin 北向接

口由上层的云管理平台进行统一入

口 Restful 接口调用，规范 FWaaS Plugin 南向接口，由各厂商 Driver适配对接。

5、 负载均衡集成思路

在负载均衡与 OpenStack 集成

思路上，有多条路径同时可供选择。

路径 1 ：基于 LBaaS V1/V2 实

现 OpenStack 原生框架内的功能

优点：通用解决方案 ,LBaaS为 OpenStack 构建的负载均衡模

型，通过 LBaaS 可实现对 HAProxy（OpenStack 默认的负载均衡技术）、

F5 等不同厂商的支持。

缺点：由于在实现上主要考虑

多种负载均衡技术的通用性，仅能

实现基础的负载均衡功能，对于商

业银行数据中心来说，无法满足对

于例如高级应用健康检查等技术的

支持。

路径 2 ：基于 HEAT 编排模块，

结合 F5 iApp 应用模板，实现高级

功能的扩展

优点：官方推荐路径，如下图

所示，通过 OpenStack 的流程编排

模块 HEAT 模板，结合 F5 的应用

模板可满足目前所需的高级功能的

支持。模板使用 Yaml 脚本可基于

场景灵活定制，模板可归类、可复

制和可扩展。

缺点：用户成熟案例较少。

路径 3 ：基于云管理平台 +Rest-ful API，实现按需的高级功能调用及

实现；

优点：F5 设备本身向外暴露

iControl 的 Restful API，可通过云

管理平台调用 API 接口，实现对 F5的管理。实现较为灵活。

缺点：场景化要求过高，相较图 5 FWaaS 分层结构

图 6 LBaaS 与 Heat 实现对比

图 7 Heat 流程图

图 8 OpenStack“单向”模型

于命令行的模式没有明显优势。且

兼容性不高，若采用其他的负载均

衡技术，整套体系需要重建。

经过反复研究论证确定选择集

成路径 2。首先由 OpenStack 原生

的 LBaaS 模型提供基础功能，其

次结合 OpenStack 流程编排模块

HEAT，定义适配商业银行数据中

心的负载均衡设备的自定义资源，

提供高级功能，相关的流程如图 7。

6、 高可靠性设计

OpenStack 的整体模型在各种

资源如虚拟机、防火墙策略都是单

向的，通过 OpenStack 层面的数据

沉淀记录并下发到设备。但是必

需考虑高可靠的问题，OpenStack层面的“账本”与实际落到设备

上的“账本”无法完全一一对应。

OpenStack 无法检测到设备在下发

过程中异常重启所引发的运行配置

与保存配置不一致和不同步。

为了解决“账实不一”的不一

致风险，在自研的模型中增加一系

列“对账”的功能确保配置的高可

靠性。一是针对防火墙策略规则定

期或者主动触发进行对账，获取设

备上的规则与 OpenStack 的规则进

行验证；二是主动获取策略命中的

情况来配合用户的验证。将单向模

型优化成双向模型，确保策略的准

确性和一致性。

7、 自助服务与自动化体系的

关系

随着商业银行数据中心 IT 架

构转型，云计算逐步推广，在自助

服务与传统自动化体系的关系上存

在如下两条路径的分歧：

1）继续走自动化的路，在管

理平面上将云环境里的网络设备和

传统环境的网络设备拉齐，依托 IT服务流程提供统一的管理界面。

2）双轨制，云环境里的网络

40 41

交易技术前沿

The Foreland of Trading TechnologyE实践探索Explore

设备管理通过 OpenStack 的 ML2，FWaaS，LBaaS 模 型 建 模， 联 动

OpenStack 的数据库，探索 IT 服务

流程的突破，提供对网络设备的自

助管理。

通过深入研究，我们认为在处

理云自助服务和传统环境自动化的

关系时，应该基于如下几个基本原

则：

1）应用入云是大势所趋，云

内的需求会越来越多。

2）传统统环境在一段时间内

与云环境共存。

3）通过自助服务提升云环境

的用户体验，传统环境仍然保留自

动化的方式提升工作效率。自助服

务与交易化分头建设，并保持模块

松耦合的原则。

( 二 ) 主要成效1、 理念转变、明确责任边界、

规范创新

通过自助服务提升云环境的用

户体验，给用户“自服务”、“所见

即所得”的优质服务体验，需要创

新现有的规范与管理流程制度要求。

首先需要明确责任边界，租户

（应用维护人员）的责任是明确访

问关系需求、访问集群需求是被授

权且完整的。云运营方的责任是通

过自动化手段确保租户的需求能够

无差错的加以实施。在该责任边界

模型上，商业银行数据中心需要优

化和创新现有的安全规范及 IT 服

务流程，如调整云内防火墙策略颗

粒度，废止不适云的条款，简化安

全可控的防火墙策略审批流程，增

加资源所有者确认环节，甚至变更

的时间也可根据管理要求灵活定

制。

梳理托管双方的主要服务流

程，通过合理划分界限，基于自服

务模式，提升 IT 的运维敏捷性。

2、 多方共建模型

为了适配不同厂商的设备，将

Neutron 中的 FWaaS 和 LBaaS 中的

plugin 和 driver 解耦。规范 Plugin 南向接口，由各厂商 Driver 适配对

接。实现对外暴露同一个接口，由

于该模型的建立基于自定制的多方

（商业银行数据中心、各相关厂商）

共建，在建设不同区域云环境时加

图 9 自助服务与自动化的关系

载不同厂商的 Driver 即可对外提供

一致性、标准化的防火墙和负载均

衡自助服务。

3、 适配商业银行数据中心的

模型

基于自服务的防火墙和负

载均衡模型定制工作共计优化

OpenStack 模型与生产需求差异点

23 项，改进了 OpenStack 单向下发

的缺陷，让单向模型变成双向模型，

避免“账实不一”，结合设备虚拟

化实现了对资源共享基础上的安全

隔离。在已有的模型基础上，多层

加固，以满足在银行业重监管重安

全的行业要求。

三、应用实践

截至 2017 年底，工商银行已

完成研发、测试和生产三朵基础设

施云的建设工作，随着以融 e 行、

融 e 联、融 e 购三大平台为代表的

大量应用实例陆续迁移上云，对资

源供应效率、用户体验提出了越来

越高的要求。

基础设施云自助服务方面，在

具备计算、网络资源的基础供应能

力之外，工商银行创新实验室已完

成基于多租户自助服务的负载均

衡、防火墙功能模块与基础设施云

平台集成的原型验证。计划近期完

成成果转化和应用推广，预计可大

幅度提升基础设施云防火墙和负载

均衡等策略类服务请求的用户自服

务能力和响应效率。

后续以进一步丰富 Iaas 云服务

应用目录为主线，在域名解析、地

址转换、云自助备份等云服务方面

开展持续研究，加快与服务应用部

署速度，提升基础设施的运营管理

效率 , 最终实现“面向用户的云服

务，解放专业人员”的目标。

樊建 陈营 葛宝磊 / 华泰证券股份有限公司 邮箱：fanjian@htsc.com

分布式缓存Redis Cluster在华泰证券的探索与实践

Redis Cluster 作为最热门的开源分布式缓存，在券商领域会有怎样的应用场

景？本文从华泰证券的应用现状出发，介绍了 Redis Cluster 在华泰证券的大规模实

践经验。

42 43

交易技术前沿

The Foreland of Trading TechnologyE实践探索Explore

1. 引言

Redis 是一个开源（BSD 许可）

的内存 Key-Value 存储系统，它可

以用作数据库、缓存和消息中间件。

它支持多种类型的数据结构，如：

字符串、散列）、列表、集合、有

序集合与范围查询等。 Redis 内置

了复制、LRU 驱动事件、事务、磁

盘持久化等特性，并通过 Redis 哨兵（主从模式）和自动分区（Redis Cluster 模式）提供高可用性。

官方的 Redis Cluster 推出前，

常见的 Redis Cluster 开源方案主要

是 Codis 和 Twemproxy，两者均采

用 Proxy 的方式实现分布式。通过

引入 Proxy 层来屏蔽底层数据的分

布，可以简化客户端的实现，但使

得集群架构变得复杂，维护成本上

升。Redis 从 3.0 开始支持自动分区，

采用无中心节点方式实现 Cluster模式。访问 Redis Cluster 时，无需

Proxy 代理，具备 Smart 特性的客

户端直接与 Redis Cluster 中的每个

节点连接。

Redis 引入 Cluster 模式带来的

优势在于：

1. 可靠性 ：具有分区机制、

副本机制和自动容错机制；

2. 高性能：保证了 Redis 高吞吐的前提下，可线性扩展到上千

个节点；

3. 可扩展性 ：基于分区的自

动扩容、缩容，客户端透明的数据

迁移。

目前，Redis 在互联网、金融、

传统行业内的应用已十分广泛。随

着金融业接入互联网的业务增加，

活动、促销、节假日、热门事件等

可能带来突发数倍甚至几十倍的

访问峰值的情况时有发生，Redis Cluster 是抵御突发海量访问的有效

手段。

2. 基本原理及概念

Redis Cluster 整体设计是比较

简单的，集群架构采用无中心节

点的方式实现，集群中的节点通过

Gossip 协议相互交换集群状态。客

户端无需代理直接访问服务端，客

户端通过 Hash 算法计算出 Key 对

应的哈希槽，然后直接访问哈希槽

对应的服务端节点。

Redis Cluster 的拓扑结构如下

图所示：

图 1 Redis Cluster 架构图

集群构建：

Redis Cluster 提供了一组集群

搭建和管理命令，如：CLUSTER INFO、CLUSTER NODES、CLUS-TER MEET 等。实际使用过程中可

以借助命令行工具 redis-trib.rb，可

以方便的搭建一个集群、平衡集群

哈希槽分布、删除添加节点等。

搭 建 一 个 Redis Cluster 仅 需

两步：1. 节点准备，将编译好的

Redis 发布到至少三台服务器上，

修改配置文件并启动 Redis 节点 ；

2. 节点握手，使用 redis-trib create host1:port1 ... hostN:portN 命令完成

节点握手并确认槽位分配。服务器

上有多个 Redis 实例时，注意修改

服务的端口、工作目录、AOF 和

RDB 文件名等配置。创建集群时可

以指定副本数，也可以在集群创建

完成后，将从节点逐个添加到集群

中去。

数据分布：

Redis Cluster 基于哈希槽（分

片）的方式将数据分布到 16384 个

槽中，每个 Master 节点负责一部

分哈希槽的数据存储。Redis 中的

每个键都会被映射到这些哈希槽

的其中一个，集群使用 Hash 公式

CRC16(key)%16384 来 计 算 键 key属于哪个槽。

Redis 的 Smart 客户端在访问

集群时，先获取并缓存哈希槽和节

点的映射关系，然后通过计算 Key对应的哈希槽编号查找应该访问的

节点。为了配合集群扩缩容、数据

迁移等哈希槽映射需要改变的操

作，Redis 服务端添加了 MOVED、

ASK 两种响应策略，前者通知客户

端所访问的哈希槽所在的新节点，

后者则通知客户端哈希槽正在迁移

到哪个节点。

主从复制：

Redis Cluster 节点间使用异步

冗 余 备 份（Asynchronous Replica-tion），不能保证数据的强一致性。

可能出现数据丢失的场景：修改操

作完成主节点上更新，当主节点回

复客户端成功后，增量改动未能同

步到从节点，此时主节点异常（宕

机、故障转移等），从节点成为主

节点；客户端路由表更新窗口期间，

集群内或许会有主从角色快速出现

两次切换，此时数据仍有可能写错

节点，最终造成数据丢失。

虽然 Redis 主从复制不能保证

强一致性，但在不出现主从切换的

情况下，数据出现不一致的情况还

是很难出现的。实际生产环境下，

出现主从切换的概率不大，但仍建

议业务系统要有容忍缓存数据丢失

的能力。

故障检测：

Redis Cluster 中的每个节点都

存储有一份其他已知节点的标识列

表，其中有两个标识是用于失效检

测，分别是 PFAIL 和 FAIL。当一

个节点在超过 NODE_TIMEOUT 时

间后仍无法访问某个节点，他会将

被检测节点标识为 PFAIL，表示可

能失效；一个节点被大多数主节点

确认不可达，则会标识为 FAIL，表

示已经失效。

每个节点定时向其他节点发送

Gossip 消息，消息中包含一些随机

的已知节点的状态。最终每个节点

都能收到一份其他节点的标识。当

节点被标记为 FAIL 时，就需要提

升一个从节点来做主节点。

故障转移：

当一个负责槽位数大于 0 的

主节点处于 FAIL 状态时，他的从

节点可以自动的发起选举。一旦

某个从节点收到了大多数主节点

的回应，那么它将提升为新的主

节点。另外，Redis Cluster 提供了

手动故障迁移的命令 CLUSTER FAILOVER，可以在运维使用。

3. Redis Cluster 在华泰证券背景介绍及建设现状

2015 年，随着华泰证券互联网

金融自主研发的大规模投入，面对

海量用户并发场景，迫切需要建设

统一化、服务化的分布式缓存平台。

通过对 Redis Cluster、Codis 及Twemproxy 等开源 Redis 集群解决

方案进行验证和对比，最终从性能、

易维护、高可用等方面考虑，选择

Redis 3.2.0 版本的 Cluster 模式作为

公司级缓存解决方案。Redis Cluster获得了开源社区的持续支持，功能、

特性一直在迭代改进。相比之下，

Codis 及 Twemproxy 社区活跃度较

低，维护成本相对较高，吞吐量也

略逊于 Redis Cluster。目前，在华泰证券建设有多

套 Redis Cluster 资源池，总体集群

服务器数量 20 余台。在交易时段，

峰值访问量超 20 万次 / 秒，服务了

30 个以上应用系统，包括：行情中

心、涨乐财富通、互联网用户中心

等，在缓存、分布式锁、内存存储、

任务队列等业务场景都有应用。

4. 实践经验

（1）高可用多活架构

如图 2 所示，Redis Cluster 数据节点采用同城三数据中心部署方

式，通常其中两个数据中心部署数

量相等的机器，另一数据中心部署

单台机器。为加速重做从节点的速

度，主机采用万兆网卡。为保证访

问缓存的延时足够小，跨数据中心

之间的网络通信采用独立的万兆波

分通道。

实际部署时，需要调整 Redis Cluster 的 Master 节点分布，要保证

任意一个数据中心 Master 节点数小

于集群的一半。采取这样的部署架

构，如果单数据中心出现问题，另

一个中心能自动进行接管，业务系

统可以无感知切换。

（2）Java 客户端层面的调优

1、 推荐使用 Jedis2.8.x 及以

上版本，关闭 TestOnReturn 和 Tes-tOnBorrow ；

2、 推荐使用 Jedis 的 JedisPool-Config，它是对 GenericObjectPoolCon-fig 的优化版本；

3、 合理使用HGETALL、SMEM-BERS等O(N)操作。

（3）服务端层面的优化

1、 重命名 KEYS、FLUSHALL、FLUSHDB 等耗时且危险的操作；

2、 适度加大 client-output-buf-fer-limit slave 避免不必要的重做从

节点；

3、 适度加大 repl-backlog-size和 repl-backlog-ttl，值越大 slave 可

丢失的时间越长；

4、 AOF，关闭 RDB，减少服

务端 fork 操作造成的访问出现卡顿

的现象；

5、 根据实际场景配置 cluster-require-full-coverage 为 yes，减少集

群不可用的时间。

图 2 Redis Cluster 部署架构图

44 45

交易技术前沿

The Foreland of Trading TechnologyE实践探索Explore

（4）RedisCluster 的功能限制

Redis cluster 是分布式的 Redis实现，具有一定的容错性和线性可

扩展性，这些特性牺牲了以下功能：

1、 不能使用 SELECT 命令，

不支持对多个槽位内的 KEY 进行

操作，比如 MSET、SUNION ；

2、 发布订阅功能不推荐使用，

集群规模越大，产生的网络流量越

大；

3、 采用 Redis 主从模式的应

用，客户端代码需要少量的改造才

能升级到 Cluster 模式。

（5）问题跟进及版本更新

开源中间件难免出现 Bug 及其

它性能问题，大部分问题开源社区

都能找到问题的解决方案，积极的

跟进社区讨论是有效的避免生产事

故的有效途径。在实际使用中，我

们发现了多个 Redis 的 Bug，社区

均有解决方案。目前，我们已经将

生产环境上部分 Redis 节点升级到

3.2.7 版本，主要因为遇到以下问题：

1、 从节点同步 Ziplist 后，List索引更新错误，造成从节点 Crash ；

2、 Ziplist 中成员长度增长，

List 索引更新错误，造成主节点和

从节点的 AOF 重写均失败，产生

大量临时文件。

（6）持续跟进

Redis 2.8.0 版 本 开 始 引 入

PSYNC 机制，PSYNC 通过添加缓

冲队列，缓存从节点断开连接期

间的数据变化增量，当从节点重新

连接且缓存队列未溢出时，则可避

免早期版本从节点重连后必然需要

SYNC 操作全量同步主节点数据的

问题。

PSYNC 可以有效地解决网络

抖动造成的从节点短暂断开连接的

问题，但无法避免当主节点、从节

点相继出现网络失连、重启、进程

推出的情况发生后的全量数据同步

和 恢 复，Redis 4.0 引 入 PSYNC 2和 PSYNC 3 等新特性来解决相关

问题。目前 Redis 4.0 仍处于验证阶

段，需要持续验证和密切关注。

5. 典型场景

与其它开源的 key-value 内存

存储系统相比，Redis 支持的数据

更加丰富，常用的 value 数据类型

包括：字符串、哈希表、链表、集

合、有序集合。同时，Redis 还内

置了这些数据结构的常见操作。目

前，Redis 的应用已经非常广泛，

常见的使用场景包括：缓存热数据、

计数器、队列、分布式锁、排行

榜、新闻列表、评论等场景。Redis Cluster 在华泰证券的新建信息系统

中也得到了广泛的应用，使用的部

分场景举例如下：

·行情截面

某些应用场景可能需要获取某

个市场或多个股票的最新行情，可

以使用 Redis 的 Hash 结构来实现这

个需求。示例代码如下：

添加或更新一只股票的行情

HSET MD:XSHG:STOCKTYPE "601688.SH" 17.88

获取多只股票最新行情

HMGET MD:XSHG:STOCKTYPE "601688.SH" "601689.SH"

获取某个交易所所以股票最新

行情，HGETALL 操作为 O(N) 操作，

不建议频繁调用

HGETALL MD:XSHG:STOCK-

TYPE·K 线

常见的 K 线为日 K 线或分钟

K 线，以日 K 线为例，可以使用

Redis 的有序集合来实现，示例代

码如下：

添加某只股票 2018 年 3 月 1的 K 线

ZADD KLINE:1DAY:601688.SH 20180301 kline_value

获取某只股票多天的 K 线

ZRANGEBYSCORE KLINE:-1DAY:601688.SH 20180301 20180302

·任务队列

任务队列用来在任务的生产

者和消费者之间传递任务，实现任

务的产生和任务执行模块间的松耦

合。实例代码如下：

生产者生成一个任务 task01RPUSH TASK:QUEUE "task01"消费者堵塞等待 100 秒等待任

务，BLPOP 是 LPOP 的堵塞版本

BLPOP TASK:QUEUE 100

6. 未来规划

随着业务的不断发展，Redis Cluster 在华泰证券内部已成为核

心组件。未来重点进行 PaaS 平台

建设，加强集群自动化灾备 ；建

立分级保障制度，对重点业务进

行独立管理。目前，Redis 的最新

版本 4.0.x 解决了 Redis 3.2.x 版

本在面对网络剧烈抖动时，偶尔

会出现部分分片所在的主从节点

均不可用的情况。尽早验证 Redis 4.0.x 版本的稳定性，制定有效的

升级方案和计划，也将是未来工

作的重点之一。

牟大恩 熊友根 / 海通证券股份有限公司 邮箱：mde10956@htsec.com

基于Kafka的实时盯盘系统设计概述

随着计算机技术的飞速发展，股票交易方式也在发生演变，从以前的人工盯

盘手动下单方式，到现在的由计算机实时自动盯盘，然后提醒用户的半自动委托

下单方式和由计算机盯盘后直接进行委托下单的全自动方式。由于计算机代替人

工盯盘省时省心、高效快捷、多条件全方位跟踪股票等特点，越来越受到股票投

资者的青睐。本文从技术层面，接合当前主流的消息中间件 Kafka 技术框架，探

讨 Kafka 在实时盯盘系统中的运用。本文内容包括 Kafka 核心技术应用分析以及基

于 Kafka 的实时股票盯盘系统设计，为实时盯盘系统的技术设计提供参考。

关键字：Kafka ；盯盘；条件单；监控作业

46 47

交易技术前沿E The Foreland of Trading Technology实践探索Explore

一、引言

计算机技术的快速发展，尤其

是近些年移动互联网及人工智能技

术的迅猛发展，证券行业程序化交易

也向着更加智能方向发展。本文介绍

的实时盯盘系统就是在这一大背景

下衍生出的应用，用户通过对股票价

格、涨跌幅、止盈止损、拐点、回落、

股票买卖时间、网格交易策略等多种

条件进行组合、多维度、多策略，全

方位对股票进行跟踪监控，达到用户

设定的条件后进行预警提示或自动

提交委托。由于计算机自动盯盘在用

户设置盯盘条件之后，直至盯盘条件

被触发的整个过程无需用户干预，这

样不仅节约了用户时间成本，而且比

人工盯盘更精准、及时、高效，因此

颇受用户喜爱。当前许多券商抑或其

它金融公司都在各自的炒股应用中

提供盯盘功能。

然而，股票盯盘系统其本质

是对股票行情的跟踪，对于行情这

种时效性强、波动频繁的数据流的

处理在技术实现上就具有一定的难

度，再加上各种不同条件的组合设

置，就进一步加大了处理的复杂度

和难度，这就要求我们在系统设计

和技术选型时要选择合适的架构和

技术以保证盯盘系统的时效性和准

确性。其实，盯盘也是复杂事件处

理技术（Complex event processing，简称 CEP）的一个典型应用场景，

不同应用场景下会采用与之相应的

CEP 技术框架，鉴于盯盘这种对行

情数据流的处理，本文提出一种基

于 Kafka 实现的实时自动盯盘系统

的设计方案。

二、技术要点

该实时盯盘系统采用 Kafka+Re-

的一条消息只能被同消费组下某一

个消费者消费，但不同消费组的消

费者可同时消费该消息。消费组是

Kafka 用来实现对一个主题消息进行

广播和单播的手段，实现消息广播

只需指定各消费者均属于不同的消

费组，消息单播则只需让各消费者

属于同一个消费组。

2.Kafka 分区

主题是一个逻辑的概念，而分

区是物理概念，每个分区在 Kafka集群的代理中对应一个存储目录，

分区由一系列有序、不可变的消息

组成，是一个有序队列，分区无论

是对生产者还是消费者而言都是透

明的，他们只需要关注消息属于哪

个主题。倘若没有分区，则一个主

题的消息就只能保存在一个代理之

中，当数据量较大时 Broker 就会成

为性能的瓶颈。分区的引入就是从

Kafka 性能方面考虑，是为了解决

Kafka 水平扩展问题。同时为了提

高可用性，每个分区又可以有一至

多个副本，副本分布在 Kafka 集群

不同的代理上。

Kafka 保证同一个分区中的消

息有序，并不能保证跨分区消息的

有序性。 Kafka 提供了分区策略，

客户端可以自定义分区策略，因此

要想保证消息有序，一种简单的方

式就是通过自定义分区策略让相同

Key 的消息发送到同一个分区当中。

在本文介绍的盯盘系统设计当中，

就将股票代码的 Hash 值做为消息

的 Key，这样相同股票的行情信息

就会有序地发送到同一个分区。

由于一个分区只能被同一个消

费组下的其中一个消费者消费，因

此我们说分区是消费并行度的基本

单位。同时，对于上层应用而言分

区也是最小的存储单元。从消费者

角度，我们订阅消费一个主题，即

dis 的实时流处理构建方案。在该方

案中行情服务器将行情数据推送到

Kafka，同时在监控条件被触发后处

理结果信息也写到 Kafka ；监控作业

做为 Kafka 消费者客户端，负责处

理特定类型的监控条件；Redis 用于

缓存条件单类型及行情信息。可见，

整个系统的核心模块采用的技术框

架为 Kafka，下面将对 Kafka 进行详

细阐述。

（一）Kafka 基本概述Kafka 最初由 Linkedin 公司开

发的一个分布式、可分区、多副本

基于 ZooKeeper 协调的分布式消息

系统，现在已成为 Apache 基金会的

一个顶级开源项目。Kafka 具有高

吞吐量、高可用性、低延时、高容错，

可水平扩展，数据可持久化、消息

压缩、支持安全机制等特性 , 特别

是在 0.10 版本之后，Kafka 推出了

Kafka Streams，这让 Kafka 对流数

据处理变得更加方便。同时 Kafka可以很方便地与当前主流的分布式

框架集成 , 例如与 Flume、Storm、

Spark、Flink、ELK(Elasticsearch，Logstash,Kibana) 等集成。Kafka 目

前已成为数据传输及处理方面的首

选技术框架，被各类公司广泛应用，

其性能已在各类公司应用中得到验

证，在海通证券很多项目中我们都

引入了 Kafka。

1.Kafka 基本体系结构

Kafka 体系结构中包括 Broker、生产者和消费者。其中每个 Kafka实例称为一个 Broker, 由多个 Broker构成一个 Kafka 集群。Kafka 利用

ZooKeeper 管理相应元数据信息存

储、更新及同步，Kafka 元数据信

息包括 Broker 节点信息、Kafka 集

群信息、旧版消费者信息及其消费

偏移量信息、主题信息、分区状态

信息、分区副本分配方案信息、动

态配置信息等。其体系结构如图 1所示。

在 Kafka 体系结构中，生产者

（Producer）负责将消息发送给 Kafka集群的某个代理（Broker）的某个主

题（Topic），是发送消息的客户端。

消费者（Consumer）以拉取的方式

从 Kafka 中拉取消息，是消费的客户

端。在 Kafka 中每一个消费者都属于

一个特定消费组（ConsumerGroup），通过参数 group.id 为消费者指定消

费组。如果不指定消费组，则该消

费者属于默认消费组。同一个主题

图 1 Kafka 基本体系结构

为订阅了该主题的所有分区，当然

也可以订阅主题的某个分区。从生

产者角度出发，我们可以通过指定

消息的 Key 及分区分配策略将消息

发送到主题相应的分区当中。

3.分区数与消费者的关系

Kafka 的生产者和消费者都可

以多线程并行操作，而每个线程

处理的是一个分区的数据，Kafka提供了配置项 partition.assignment.strategy 用来设置消费者线程与分区

映射关系。Kafka 提供了两种分配

策略：Range 和 Round-robin，默认

是 Range 分配的策略。Range 策略

即按照线程总数与分区总数进行整

除运算计算一个跨度，然后将分区

按跨度进行平均分配，以保证分区

尽可能的均衡地分配给所有消费者

线程。Round-robin 策略较简单，首

先将订阅的主题的分区以及消费者

线程进行排序，然后通过轮询方式

逐个将分区依次分给消费者线程。

从线程与分区的分配关系来

看，理论来讲分区数越多并发度越

高。然而，由于每个分区自身要进

行相应分区元数据的缓存、同步等

都有一定的开销。同时分区多意味

着要保持打开状态的文件句柄数也

就越多，因此并不一定是分区越多

越好。在实际应用中要根据应用场

景选择合适的分区数，使得消息尽

可能的均衡分发到所有分区当中。

通常我们将消费者线程数设置与分

区数相等，这样通常能达到较高的

吞吐量。若消费者线程数大于分区

数，则多余的线程就会分配不到任

何分区，这样就浪费了系统资源。

三、系统设计

为了描述和理解方便，在开始

阐述系统设计之前，我们约定以下

基本术语：

条件单：指用户设置的不同盯

盘条件，一组条件构成一笔条件单。

条件单类型：每一笔条件单特

属于一种类型，如指定某支股票日

涨幅达 5% 时买入，则这个条件对

应一笔条件单，而这个条件单属于

的条件单类型为涨跌幅。根据产品

设计可以定义多个条件单类型，如

价格条件、时间条件、网格交易、

拐点交易等。条件单类型是监控

作业及条件单处理器处理的基本单

位，每一种类型分别对应一个条件

单处理器和一个监控作业。

监控作业：每种类型的条件单

对应一个监控处理类，该处理类负

责监控该种类型的所有条件单是否

达到触发条件。

委托单：由条件单转化而来，

例如用户设置某个条件单以卖一价

的价格卖入，那么该条件单经由监

控作业触发后用卖一价的价格将条

件单转为一笔委托单。

（一）系统架构盯盘系统主要包括条件单收单

入库、条件单监控作业两部分，对

于盯盘后直接进行委托的全自动交

易方式，还包括委托作业模块。在

监控作业中将条件单转为委托单，

然后将委托单写入到 Kafka，对于

全自动交易方式本文不作深入分

析，但本文所提供的方案也能够方

便地增加此模块。该系统网络拓扑

如图 2 所示。

本 方 案 基 于 Kafka 来 实 现，

数据库采用 MySQL，缓存使用

Redis，系统架构如图 3 所示。

（二）核心流程用户通过客户端设置盯盘条

件，提交到盯盘系统后台，盯盘系

48

交易技术前沿E The Foreland of Trading Technology

49

实践探索Explore

统会调用交易服务进行用户信息及

条件单信息验证，验证成功后条件

单入库。行情服务器将行情数据实

时推送到 Kafka 集群，盯盘系统监

控作业从 Kafka 中消费行情数据，

并异步将行情信息写入到 Redis，以提供给基于时间触发的监控作业

使用。条件单经监控作业处理后写

入到 Kafka。

1.盯盘条件收单

用户通过盯盘界面，设置盯盘

条件，通过 HTTPS 协议提交到盯

盘系统后台。后台系统会对用户基

本信息及公用参数进行较验，较验

成功后会根据条件单类型，路由到

具体的条件单处理器，经由与该条

件单类型对应的处理器处理，构造

一条初始化状态为 I 的记录写入到

行情信息写入 Kafka 后，就会

触发监控作业开始执行。每个条件

单类型对应一个作业处理类，该作

业处理类是监控作业的真正执行者。

作业处理类首先会根据从 Kafka 拉

取的股票行情信息以股票代码进行

分组，然后异步交由线程池进行处

理。线程的执行逻辑为：首先根据

条件单类型及股票行情信息构造本

次触发条件单的查询条件，然后批

MySQL 数据库。盯盘条件收单流

程如图 4 所示。

图 4 盯盘条件收单逻辑

2.监控作业

不同类型的条件单分别对应一

个作业处理类，每种类型的条件单

在数据库中对应一张表，一个监控

作业就是一个 Kafka 消费者。监控

作业分两类：基于行情触发和基于

时间触发。基于时间触发的作业即

当达到用户设置的某个时间点进行

触发，作业内部处理逻辑与基于行

情触发的作业处理逻辑基本相似，

只不过基于时间的作业触发是定时

执行，同时行情数据是从 Redis 中读取，在本文不再展开阐述，本文

所讲的作业在没有特殊说明情况下

均指基于行情触发的监控作业。

图 2 盯盘系统网络拓扑图

图 3 盯盘系统系统架构

量更新当前类型条件单对应的数据

库表，条件单状态由 I 更新为 P，P状态的条件单即为已满足用户设置

的条件。由于是多节点部署，为了

保证 P 状态的条件单只被加载一

次，我们采用字段标识法，即数据

库中每行数据包含一个批次标识字

段 result_batch，该字段值为本机 IP后接 UUID。在更新条件单时，同

批次更新的记录拥有相同的 result_batch。若本次成功更新的记录数大

于 0，则查询状态为 P，result_batch与本次更新的批次号相同的所有记

录。然后将这些记录写入到 Kafka，再由消息推送服务从 Kafka 中拉取

信息推送给用户。在成功推送后将

条件单状态更新为 S 状态。在处理

条件单发生异常时则将该条件单保

存到失败列表中，最后批量将其状

态重置为 I 状态。监控作业的逻辑

流程如图 5 所示。

图 5 基于行情触发的监控作业流程

图 6 盯盘系统核心逻辑

50 51

交易技术前沿E The Foreland of Trading Technology实践探索Explore

（三）系统总体流程前面就盯盘条件收单及监控作

业基本流程阐述之后，这里再将盯

盘系统总体逻辑流程简单梳理如图

6 所示。图 6 描述了基于行情触发

和基于时间触发的两类监控作业的

处理逻辑。

四、总结

本方案选用 Kafka，一是由于

Kafka 具有高吞吐量、低延时、高

可用性、支持多线程并发处理的特

性，二是由于 Kafka 的消费者具有

消费组的概念，同一条消息只被同

一个消费组下的某一个消费者消

费，这就很方便地解决了在分布式

系统部署时，如何避免程序重复执

行的问题。盯盘系统后台会部署在

多个节点上，多个节点上部署的程

序都是同一套代码，每个监控作业

分别对应一个消费组，这样一条行

情信息会触发所有条件单类型对应

的监控作业执行。对于一个监控作

业从节点层面来看却是属于同一个

消费组，这样就不会出现一条消息

被多个节点同时执行的情况，也就

避免了一笔条件单被各节点同时触

发的情况。同时 Kafka 能够很方便

地处理服务节点水平扩展，以及当

某个节点不可用时，Kafka 又可以

方便地进行故障转移。

本文概述性阐述了基于 Kafka实现的盯盘系统的设计方案，具有

一定的可行性和参考价值，在对条

件单进行监控时，我们改变了一般

先查询再比对的设计思路，在本方

案中我们采用根据条件单类型及当

前行情信息构造条件单被命中需要

满足的条件，然后以此条件去批量

更新条件单的逆向设计思路，经验

证这种方式较先查询再逐笔比对方

表 1 Kafka 生产者性能测试

表 2 Kafka 消费者性能测试

参考文献 ：

[1] 牟大恩 .Kafka 入门与实践 [M]. 北京 ：人民邮电出版社，2017 ：2-18.

[2] Apache Kafka[OL]. http://kafka.apache.org/0101/documentation.html.

[3] 崔星灿 , 禹晓辉 , 刘洋 , 吕朝阳 . 分布式流处理技术综述 [J]. 计算机研究与发展 ,2015,02:318-332.

邹经纬 马辉 / 国泰君安股份有限公司

钟浪辉 陈敏 陈坚 刘啸林 / 上交所技术有限责任公司

OPENCL开发FPGA应用的路径探索

近年来 FPGA 技术在证券期货市场得到广泛使用，证券期货业许多核心机构、

会员单位都加大了对 FPGA 技术的研究与应用。上交所技术公司也积极布局研究

FPGA 技术，我们在去年研发《FAST 行情硬解码》的基础上，今年新立项与国泰

君安合作研究《FPGA 实现股票期权相关指标》，希望探索纯软件工程师自主开发

FPGA 应用的路径，既利用 FPGA 应用运行稳定、运算高效、低功耗的特点，又达

到公司完全掌控知识产权的要求。

式在效率上提升很多。

同时，由于盯盘本身时效性要

求非常高，Kafka 具有高吞吐量、

低延时的特性在一定程度上能保证

消息能够被及时处理。在这里，我

们给出一组用 Kafka 自带的基准测

试脚本测试的 Kafka 生产者和消费

者性能测试结果，分别如表 1 和表

2 所示。

从表 1 和表 2 测试结果可以

看到 ：Kafka 生产者的延时都是在

毫秒级，消费者每秒能消费 10 几

万条记录，这也很好验证 Kafka 具

有高吞吐量，低延时的特性。以

上测试我们并没有对 Kafka 集群、

Kafka 生产者以及 Kafka 消费者做

过多的优化，表 1 测试结果是将

acks 设置为 -1，其实对于盯盘这

种应用场景，我们完全可以将 acks值设置为 1, 同时也将副本数设置

为 1，这都将会提升 Kafka 生产消

息的性能。同时设置合理的分区数

来提升消费者并行度，JVM 参数

优化设置等一系列优化措施都将会

提升 Kafka 生产消息和消费消息的

性能。本文重点在于提出一种基于

Kafka 实现的盯盘系统设计方案及

对该方案可行性进行分析阐述，对

于 Kafka 性能优化方面的操作不做

深入阐述。

52 53

交易技术前沿E The Foreland of Trading Technology实践探索Explore

1. FPGA 与 OPENCL 概述

1.1FPGA

FPGA（Field － Programmable Gate Array，现场可编程门阵列）介

于专用芯片和通用芯片之间，具有

一定的可编程性，可同时进行数据

并行和任务并行计算，在处理特定

应用时有更加明显的效率。更重要

的是，FPGA 具有明显的性能功耗

比优势，其能耗比是 CPU 的 10 倍

以上、GPU 的 3 倍。

此外，可定制化也是 FPGA 的

一大重要特性。正是因为具备极强

的性能功耗比优势和定制化特点，

FPGA 在诸多领域得到应用，如逻

辑控制，信号处理，图像处理等方

面，最近更是在大数据处理、深度

学习中的在线识别系统中开始尝试

使用。

不过，传统 FPGA 开发采用

Verilog、VHDL 等硬件描述语言，

对开发者要求较高，开发周期也较

长，因此在高性能计算应用受到限

制。而采用 OpenCL，利用软件高

级语言和模型编程，开发周期可大

幅缩短，对于一些应用可以实现几

个人月完成，为 FPGA 的应用发展

提供了更为广阔的平台。

1.2OPENCL

OpenCL 标准是首个开放式、

免费许可的统一编程模型，能够在

异构系统上加快算法速度。OpenCL 支持在不同的平台上使用基于 C 语言的编程语言开发代码，例如 CPU、GPU 及 FPGA。OpenCL 的主要优势在于它是一个可移植、开

放式、免费许可的标准，这是它与

专用编程模型相比的一个关键优

势。

对于软件工程师而言，OpenCL 是一个编程模型，而对于系统架构

师来说则是一种方法。它基于支持

扩展的标准 ANSI C (C99) 来隐藏

并行性。此外，OpenCL 还包括一

个应用编程接口 (API)，支持主机

与硬件加速器进行通信（一般通过 PCI Express），或内核之间通信，而

无需主机交互。

2. 面向 OPENCL 的 FPGA解决方案 - 赛灵思（Xilinx）的 SDAccel

赛灵思是 All Programmable 器件、SoC 和 3D IC 的全球领先供应

商。赛灵思公司行业领先的产品与

新一代设计环境以及 IP 核完美地整

合在一起，可满足客户对可编程逻

辑乃至可编程系统集成的广泛需求。

SDAccel 是赛灵思公司面向系

统和软件工程师的一系列开发环

境，让具备较少甚至没有 FPGA 专业知识的开发人员也能够利用高级

编程语言充分发挥可编程硬件和业

界标准处理器的功能优势。

2014 国际超算大会 (Super Com-puting 2014) 上宣布推出针对 Open-CL ™、C 和 C++ 的 S DAccelTM 开发

环境，将单位功耗性能提高达 25 倍，

从而利用 FPGA 实现数据中心应用

加速。SDAccel 将业界支持 Open-CL、C 和 C++ 内核任意组合的架构

优化编译器、库、开发板完美结合

在一起，在 FPGA 上首次实现了完

全类似 CPU/GPU 的开发和运行时

间体验。

2.1编译器架构面向OpenCL、

C和C++ 进行了优化

• 结构优化的编译器，较之 CPU/GPU 可将数据中心单位功耗

性能提升高达 25 倍• 较之其他 FPGA 解决方案，

实现了 3 倍性能和资源效能

• 实现全新或已有的 OpenCL, C 和 C++ 代码，加速高性能加速器

软件开发人员充分利用 SDAc-cel 编译器的功能，能够利用新的或

现有的 OpenCL、C 和 C++ 代码创

建高性能加速器，并针对计算搜索、

图像识别、机器学习、编码转换、

存储压缩和加密等各种数据中心应

用中的存储器、数据流和流水线技

术进行了精心优化。

2.2可在FPGA 上实现类似

CPU的开发体验

SDAccel 是首个面向 OpenCL、C 和 C++ 进行架构优化的编译器，

并结合了 # 库、开发板，可在 FPGA上实现类似 CPU/GPU 的开发运行

体验 。 • 首款面向 FPGA 平台的完整

的软件开发环境

• 即便没有 FPGA 使用经验，

也能优化 FPGA 平台的应用

• 轻松将应用移植到 FPGA 上，

同时还可维护和重复用 OpenCL、C 和 C++ 代码

借助 SDAccel，开发人员能够

使用其熟悉的工作流程优化应用，

而且即便之前没有 FPGA 使用经

验，也能受益于 FPGA 平台的优势。

集成设计环境 (IDE) 不仅可提供编

码模板和软件库，而且还能对各种

开发目标进行编译、调试和特性分

析，如在 X86 平台上仿真、使用快

速仿真进行性能验证以及在 FPGA 处理器上进行本地执行等。IDE 可在数据中心用 FPGA 平台上执行应

用。该平台配套提供面向所有支持

开发目标的自动仪器插入功能。此

外，SDAccel 还经过精心设计，使 CPU/GPU 开发人员能够轻松将其

应用迁移到 FPGA 上，同时还可在

他们熟悉的工作流程中维护和复用 OpenCL、C 和 C++ 代码。

综合全面的 SDAccel 环境包

括编程器用 IDE、基于 C 语言的 FPGA 优化库，以及数据中心用现

成商用 (COTS) 平台。

SDAccel 库包括用于高性能低

功耗实现方案的内置 OpenCL 函数、

DSP、视频以及线性代数库。针对

特定领域加速，赛灵思联盟合作成

员 Auviz Systems 提供了精心优化

的 OpenCV 和 BLAS OpenCL 兼容

型软件库。 COTS 成员还有 Alpha Data、Convey、Pico Computing 等。

2.3可在FPGA 上实现类似

CPU的运行体验

• 使用多程序和类似 CPU/GPU 的可加载计算单元，支持大型应用

• 程序转移时维护系统功能，

同时还能在执行应用时保持关键的

系统接口和功能继续发挥作用

• 实现全新或已有的 OpenCL, C 和 C++ 代码，加速高性能加速器

SDAccel 能够支持带有多个程

序和类似 CPU/GPU 按需可加载计

算单元的应用。与 CPU/GPU 类似，

SDAccel 对于 FPGA 解决方案的独

特之处，在于能够保持程序转换过

程中的系统正常工作。SDAccel 是业界唯一能够创建可在应用运行过

程中加载新加速器内核的 FPGA 计算单元的环境。 在整个应用执行过

程中，存储器、以太网、PCIe® 和

性能监控器等关键系统接口和功能

均保持工作状态。即时可重配置的

计算单元可 让多个应用共享 FPGA 加速器。例如通过对运行系统编程，

可支持图像搜索、视频转码和图像

处理之间的切换。

3. 面向 OPENCL 的 FPGA解决方案 - 英特尔 (Intel)FPGA SDK

面 向 OpenCL ™ 的 英 特 尔

(Intel) FPGA SDK 是一个一流的开

发环境，支持软件开发人员提升

其应用程序在使用英特尔 CPU 和 FPGA 构建的异构平台上的运行速

度。该环境将英特尔的先进软件开

发框架和编译器技术与新的革命性

英特尔 Quartus® Prime 软件相结

合，提供了新一代开发环境，在隐

藏 FPGA 细节的同时实现了工作优

化。面向 OpenCL 的英特尔 FPGA SDK 支持您充分利用 FPGA 的独特

功能提升性能，实现高能效和低延

迟。

面向 OpenCL 的英特尔 FPGA SDK 提供了一个厂商扩展、一个 I/O 及一个主机通道 API，能够通过

数据流 I/O 接口（例如 10 Gb 以太

网）直接将数据传输至内核。

3.1IntelFPGASDK 的主要特

性

•Microsoft* Visual Studio 或基

于 Eclipse 的面向 OpenCL API 的英特尔代码构建工具（现在支持 FPGA）

• 采用英特尔编译器技术的快

速 FPGA 模拟

• 创建 OpenCL 项目快速启动

向导

• 语法突显和代码自动完成特

性

• 假设内核性能分析

• 快速静态 FPGA 资源和性能

分析

• 支持快速和增量 FPGA 编译

3.2 Intel FPGASDK 开 发

OpenCL的示例

3.2.1IntelOPENCLSDK 的安

装

从 Intel FPGA 网站下载安装

包 ：Intel FPGA SDK for OpenCL。根据选择的版本类型和版本号不

同，下载的安装包文件可能不一样。

以 Intel PAC 对应的 Pro 17.1 为例，

进行安装说明。下载的安装包为

AOCL-pro-CB-17.1.0.240-linux.tar，同时找 Intel 相关人员申请软件使用

的 License。环境要求：

硬件：内存 24GB RAM 以上，

磁盘 85GB 空闲以上。因为安装包

本身就是 20~30GB。软件：Linux 操作系统，安装

gcc，perl。将 AOCL-pro-CB-17.1.0.240-

linux.tar 拷贝到用户目录下。切换

到 root 权限。解压：

tar -xvf AOCL-pro-CB-17.1.0.240-linux.tar

运行安装程序：

./setup_pro.sh图 1 SDAccel 开发 FPGA 应用的环境

54 55

交易技术前沿E The Foreland of Trading Technology实践探索

编译

编译分为两种，一种是模拟编

译，一种是正常编译。前者是用于

纯软件调试，运行于纯 CPU 上，无

需 FPGA，对应的描述是 emulator，采用类似于调试 c/c++ 语言的方式

调试 OpenCL 代码。后者是编译出

aocx 文件（用于加载到 FPGA 上运

行的 bitstream），在运行时，加载

到 FPGA 上，不能使用普通的 gdb进行调试，需要专用的 FPGA 调试

工具 JTAG 或是其他工具进行调试。

一般情况下，在开发 FPGA OpenCL 代码时，先进行模拟编译，

调试通过之后再上板运行，进行测

试。

编译仿真的 aocx ：

aoc -march=emulator device/vector_add.cl -o bin/vector_add.aocx --board a10gx

编译正常的 FPGA 使用的 aocx（耗时几个小时）：

aoc device/vector_add.cl -o bin/vector_add.aocx --board a10gx

编译主机程序：

make调试

调试 kernel 代码。在 Linux 上，

使用 gdb 调试主机程序（host 代码）

和设备程序（FPGA 的 OpenCL），调试时，加上临时环境变量 CL_CONTEXT_EMULATOR_DEVICE_INTELFPGA=1，执行主机程序，

这样主机程序不会将 aocx 烧入

FPGA，而是选择仿真 emulator 进行调试。仿真的 aocx 类似于 Linux上的 so 动态链接库。

使用 gdb 调试程序：

CL_CONTEXT_EMULATOR_DEVICE_INTELFPGA=1 gdb bin/host

主机代码就是 c 或 cpp 代码，

Explore

如果系统有图形界面，没有图

形界面，则一直输入 Enter ：图形界面下选择 next，然后设

置安装目录，默认为 /root/intelFP-GA_pro/17.1。可以自行设置。

选择需要支持的 FPGA 型号。

Intel PAC 是 A10 芯片，因此选择

Arrial 10 的部分。

安装结束后会提示是否安装

Intel 的 CodeBuilder，编写 OpenCL的工具，可选。

完成安装后，进入 IntelFPGA SDK 的安装目录，默认是在 ~/in-telFPGA_pro/17.1/hld

cd ~/intelFPGA_pro/17.1/hld运行脚本，检查环境变量

source ./init_opencl.sh

设置 license 路径的环境变量：

export LM_LICENSE_FILE=/root/4ccc6af076ff_License.dat

建议将如下脚本添加到 ~/.bashrc最后，添加环境变量，或者手动设

置。

安装 FPGA 板卡驱动，默认安

装 a10gx，也可以指定其他 FPGA型号。

aocl install选择 Y，继续。

3.2.2实例的开发、编译、调

试与运行

以官网的矢量加为例，下载官

网上的代码。可以使用 visual stu-dio、sublime text 或是其他软件开发

工具进行 OpenCL 的代码开发。

调试方式相同，但是 kernel 代码调

试有些区别，因为没有源代码，需

要在 kernel 函数名打断点：如果出

现未定义提示，选择 Y 继续，进入

kernel 代码中，可以打印查看变量

信息，与调试 c/c++ 函数相同。

运行

运行仿真程序，默认执行 1000000个浮点矢量加

CL_CONTEXT_EMULATOR_DEVICE_INTELFPGA=1 bin/host

运行正常程序，就无法使用

gdb 调试 FPGA 程序，必须使用专

业的 FPGA 调试工具。上板运行就

是不加仿真环境变量，直接运行主

机程序。

bin/host

4. 开发 FPGA 应用的路径探索

本文主要分享了我们通过 Intel FPGA SDK 、OPENCL 开发 FPGA应用的一些心得。后续我们将在此

基础上开展期权定价等相关指标的

开发，希望可以得到优于 CPU 计

算的性能，进而获得期权做市商等

业务专家的认可。未来，越来越多

的 C/C++ 等纯软件类工程师可以拓

展新开发领域，利用 Xilinx、Intel等公司提供的 OPENCL 解决方案开

发各自需要的 FPGA 应用。

图 2 安装时选择 Arrial10

图 3 仿真运行

交易技术前沿

The Foreland of Trading Technology交易技术前沿

The Foreland of Trading Technology

5757

行业观察observation

9 金融行业的舆情信息监测

10 证券行业大数据测试技术初探

11 基于事件驱动架构的企业级应用集成方法探究

金融行业的舆情信息监测杨珍良 / 恒生电子股份有限公司

舆情监控，整合互联网信息采集技术及信息智能处理技术通过对互联网海量信

息自动抓取、自动分类聚类、主题检测、专题聚焦，实现用户的网络舆情监测和新

闻专题追踪等信息需求，形成简报、报告、图表等分析结果，为客户全面掌握群众

思想动态，做出正确舆论引导，提供分析依据。舆情监控可以适用于多个行业，如

政府部门、大企业的市场公共部。

1. 舆情监测概述

1.1 舆情监测的背景互联化技术推动行业变革，大

量的社会舆情信息从纸质媒体、线

下生活圈转移到大型社交平台，如

微博、微信、论坛。舆情信息，它

是以巨大海量信息存在互联网各

处，带有明显碎片化、突发性、传

播性强等特性。

舆情信息监测，需要健立一套

完整监测机制及健全信息系统来配

合使用进行信息监测。它能解决目

前以下几大现状：

（一）有限的人力资源难以监

测巨量的舆情信息

监测部门（企业的市场部）都

存在部门编制不健全、人力薄弱的

情况较为突出，且兼顾行政其他工

作。部分企业经费没有被列入企业

成本预算，难以维持工作组日常运

作。

（二）传统不变的监测模式难

以应对花样不断翻新的犯罪手法

随着现代信息技术的快速发

展，金融与信息技术紧密结合，许

多金融推广活动借助互联网形势，

手法不断翻新，出现了“互联网 +金融”的特征。一些不实宣传由线

下向线上蔓延发展，犯罪分子通过

网站、论坛、聊天工具等网络工具，

打着合作开发、财富管理、海外上

市、互联网金融等名义广泛宣传，

甚至直接通过网上银行、第三方支

付工具在互联网上完成集资行为，

犯罪活动周期缩短、职业化倾向明

显。

（三）单兵（人工）作战式的防

范机制难以覆盖广泛渗透的各行各

业

当前金融舆情信息已经广泛渗

透到各行各业，金融已经配合现货、

养老、理财等各类行业结合，涉及

群体越来越广泛。依靠某一特定的

监管群体，已经无法覆盖巨大信息

量，必须依赖计算机工具，扩大联

防机制。

1.2 舆情监测的业务流程通过对线上的舆情公开数据，

用一定的规则进行数据的清理整

合，然后根据不同行业的监测分析

模型，根据已有的数据，计算出相

关企业的风险指数，及相关事件分

析，最后根据计算出来的结果来进

行相关处理（持续关注、人工干预、

汇报情况）。

• 互联网大数据采集子系统：

提供数据采集和数据维护的服务。

数据采集是监管平台的数据入口，

外部数据的获取，都是通过数据采

集功能进行获取。数据维护是对基

础数据、业务数据、模型数据和采

集数据进行管理维护。

• 大数据处理子系统：主要是

监管平台对采集后的数据按照不同

来源，进行不同规则的数据清洗和

处理。

• 风险监测预警子系统：该系

统提供给工作人员进行使用，通过

汇集来的数据进行分析统计计算，

然后以图形化和指标数据的方式，

进行数据展示，并生成报告。

• 信息发布子系统：提供信息

对外发布，接收调查问卷和投诉信

息，是工作人员同监管企业和社会

公众全面沟通信息的桥梁。真实、

全面、及时、充分地进行信息发布

交易技术前沿

The Foreland of Trading Technology交易技术前沿

The Foreland of Trading Technology行业观察Observation行业观察Observation

58 5959

至关重要，只有这样，才能对那些

社会公众真正有帮助。

2. 舆情监测的建设三大步骤

2.1 互联网数据采集信息抓取系统可对各类机构网

站关于互联网金融信息披露的内容

信息进行采集。采集的内容包括文

字、图片、flash 动画等；采集到的

内容可以显示在页面上正常浏览，

可将采集到的内容当做数据源通过

模版设置以新的方式呈现出来。主

要功能如下：

（1）通过设定内容抓取源、关

键字及相应的栏目，可以自动把其

他网站的信息（包括整页内容、图

片、视频、表格、附件等）抓取后

按类别将标题、正文、内容、来源、

时间等信息存入本地服务器，文章

内容去格式后保存并发布到网站。

（2）自动分析网页结构，按

关键词获取、信息去重、敏感词过

滤、选择自动发布或人工审核发布

功能。

（3）抓取指定网站的数据，自

动更新本站点的当天的相关信息，

比如气象、空气质量预报。

（4）根据信息自定义字段，将

抓取的数据分配到相应的字段，以

满足特定的需要。

2.2 数据分析（语义分析）“大数据处理”是舆情监测的

核心服务，同其他子系统紧密关联，

主要是对获取后的数据按照一定的

规则进行清洗、处理、存储，为综

合监测预警子系统和信息发布子系

统提供处理后的数据支持，为后续

数据挖掘进行支撑。

数据处理方法主要有：统计学

舆情测试的逻辑架构

图 1 ：舆情监测的逻辑架构图

方法，将属性当做随机变量，通过

置信区间来判断值的正误。基于聚

类的方法，根据数据相似度将数据

分组，发现不能归并到分组的孤立

点。基于分类的方法，训练一个可

以区分正常数据和异常数据的分类

模型。基于关联规则的方法，定义

数据之间的关联规则，不符合规则

的数据被认为是异常数据。

数据处理的算法主要有：基本

的字段匹配算法，直接的按位比较。

递归的字段匹配算法，处理子串顺

序颠倒及缩写的匹配情况。Smith-Waterman 算法，性能好，不依赖

领域知识，允许不匹配字符的缺

失，可以识别字符串缩写的情况。

Cosine 相似度函数，解决经常性使

用单词插入和删除导致的字符串匹

配问题。

根据数据采集来源的不同，进

行不同的清洗规则约定，主要步骤

如下图：

1、预处理阶段

预处理阶段主要做两件事情：

一是将数据导入处理工具。通

常来说，建议使用数据库，跑数搭

建 MySQL 环境即可。

二是看数据。这里包含两个部

分：一是看元数据，包括字段解释、

数据来源、代码表等等一切描述数

据的信息；二是抽取一部分数据，

使用人工查看方式，对数据本身有

一个直观的了解，并且初步发现一

些问题，为之后的处理做准备。

2、第一步：缺失值清洗

缺失值是最常见的数据问题，

处理缺失值也有很多方法，监管平

台按照以下四个步骤进行：

（1）确定缺失值范围。对每个

字段都计算其缺失值比例，然后按

照缺失比例和字段重要性，分别制

定策略。

（2）去除不需要的字段。

（3）填充缺失内容。某些缺失

值可以进行填充，方法有以下三种：

以业务知识或经验推测填充缺失

值；以同一指标的计算结果（均值、

中位数、众数等）填充缺失值；以

不同指标的计算结果填充缺失值。

（4）填充缺失内容。某些缺失

值可以进行填充，方法有以下三种：

以业务知识或经验推测填充缺失

值；以同一指标的计算结果（均值、

中位数、众数等）填充缺失值；以

不同指标的计算结果填充缺失值。

3、第二步：格式内容清洗

简单来说，格式内容问题有以

下几类：

（1）时间、日期、数值、全半

角等显示格式不一致。这种问题通

常与输入端有关，在整合多来源数

据时也有可能遇到，将其处理成一

致的某种格式即可。

（2）内容中有不该存在的字符。

某些内容可能只包括一部分字符，

比如身份证号是数字 + 字母，中国

人姓名是汉字（赵 C 这种情况还是

少数）。最典型的就是头、尾、中

间的空格，也可能出现姓名中存在

数字符号、身份证号中出现汉字等

问题。这种情况下，需要以半自动

校验半人工方式来找出可能存在的

问题，并去除不需要的字符。

（3）内容与该字段应有内容不

符。姓名写了性别，身份证号写了

手机号等等，均属这种问题。 但该

问题特殊性在于 ：并不能简单的以

删除来处理，因为成因有可能是人

工填写错误，也有可能是前端没有

校验，还有可能是导入数据时部分

或全部存在列没有对齐的问题，因

此要详细识别问题类型。

4、第三步：逻辑错误清洗

去掉一些使用简单逻辑推理就

可以直接发现问题的数据，防止后

面的分析结果偏差。

（1）去重。如果数据不是人工

录入的，那么简单去重即可。可用

待不限于模糊匹配算法。

（2）去除不合理值。对异常的

数据进行合理性分析。可用但不限

于箱形图（Box-plot）。（3）修正矛盾内容。

5、第四步：非需求数据清洗

对不要的字段或数据，不进行

数据转换。

6、第五步：关联性验证

数据有多个来源，每个来源数

据的内容不一样，那么有必要进行

关联性验证。

2.3 舆情监测分析报告舆情信息监测的效果体现在各

类风险报告上。风险报告可大致分

为企业风险、行业风险、区域风险、

综合风险分析等。

企业风险从合规性、特征性、

偏离性、投诉率、传播性这五个维

度对企业进行分析，另外包括工商

信息、企业与个人关系、企业关联

交易技术前沿

The Foreland of Trading Technology交易技术前沿

The Foreland of Trading Technology行业观察Observation行业观察Observation

60 6161

事件分析等；行业风险针对行业的

指数平均值、最高最低值等指数进

行统计，根据风险级别统计不同行

业企业数量，统计行业风险趋势 ;区域风险指针对地区的指数平均

值、指数最高最低值、等指数进行

统计，根据风险级别统计不同区域

企业数量，统计区域风险趋势；针

对监测的高风险地区分析，针对监

测的高风险行业分析，针对特征词

情况进行分析。

3. 总结

金融行业舆情信息监测的重要

性已经在政府（企业市场部）得到

认可。从政府宏观角度下，需要政

府及企业积极引导正向舆情，防范

负面的舆情信息传播。如何使用一

个高效金融行业的舆情监控平台，

是走在舆情监测的第一步。

证券行业大数据测试技术初探樊芳 / 上交所技术有限责任公司 技术开发总部 邮箱：ffan@sse.com.cn

作者简介 ：

杨珍良 恒生电子股份有限公司 交易所行业事业部 首席架构师 随着移动互联网、物联网、云计算的快速发展，全球数据呈现爆炸式增长。证

券行业交易数据也呈现出 TB 级增长趋势，大数据引发了新一轮技术发展的浪潮，

同时也给软件测试带来了新的挑战。本文结合证券交易领域大数据测试经验，梳

理了证券行业在当前大数据形势下主要使用的测试方法以及测试范围，研究了其

发展前景，并分享了笔者在大数据测试道路上的心得体会。

关键词：大数据 证券行业 测试技术 初探

62 6363

交易技术前沿

The Foreland of Trading Technology交易技术前沿

The Foreland of Trading Technology行业观察Observation行业观察Observation

1 概述

随着移动互联网、物联网、云

计算的快速发展，全球数据出现爆

炸式增长。根据研究表明全球信

息总量每过两年，就会增长一倍。

2011 年全球被创建和被复制的数据

总量 1.8ZB。相较 2010 年同期上涨

超过１ZB，到 2020 年这一数值将

增长到 35ZB[1]。然而，大数据快

速发展的战略意义不在于掌握庞大

的数据信息，而在于对这些含有意

义的数据进行深度分析，从海量数

据中挖掘出对证券行业发展有重要

价值的信息。针对传统数据库或者

数据仓库存在存储空间有限、处理

速度较慢、难以快速从价值密码低

的大量数据中挖掘实时信息等问题

[2]，构建适应于证券交易领域的

大数据处理平台已经迫在眉睫。由

于海量数据的数据量及其分布式的

特点，大数据处理技术与传统的方

式具有很大的不同，从而为软件测

试带来新的挑战。鉴于此情况，为

提高大数据信息系统测试质量和效

率，提出有效的测试策略已经成为

大数据测试领域热点话题。

综上所述，本文结合证券行业

大数据平台构建过程的测试要点，

对大数据环境下测试领域的技术初

探与实践进行了概要介绍。本文第

2 节主要阐述大数据测试领域的关

键技术相关工作，第 3 节详细介绍

证券行业大数据测试的策略。最后，

总结本文主要探究内容，展望未来

大数据测试领域发展前景。

2 大数据测试的关键技术

2.1 大数据的特点随着大数据时代的来临，数据

量呈现 TB 级别增长，大数据分析

2.3.2非功能性测试

由于大数据面向具体行业的应

用，除了功能性测试，在整个大数

据处理框架下需要进行非功能性测

试，主要包块性能测试、容错性测

试、稳定性测试、数据一致性测试

与压力测试。

(1) 性能测试：性能是评估一

个大数据分析系统的最为关键的维

度，大数据系统性能主要包括吞吐

量、任务完工时间、内存利用率等

多个指标，可以反映大数据分析平

台的处理能力、资源利用能力等性

能。可以通过大数据平台性能监控

器来监测运行状态性能指标和瓶颈

问题，性能测试采用自动化方式进

行，测试系统在不同负载情况下的

性能。

(2) 容错性测试：当故障发生

时，大数据分析系统应该在进行恢

复的同时继续以可接受的方式进行

操作，在发生错误时某种程度上可

以继续操作，需要根据应用场景来

设计解决方案和具体部署，然后手

动进行测试。

(3) 稳定性测试：大数据分析

系统通常都是不间断长期运行，稳

定性的重要性不言而喻。稳定性

测试主要验证系统在长时间运行

下，包括系统是否仍然能够正常运

行、功能是否正常。稳定性测试通

常采用自动化方式进行，可以采用

LoadRunner 等工具对测试系统产生

负载，同时使用功能测试方法验证

功能的正确性。

(4) 数据一致性测试：数据一

致性是指文件系统中的数据与从外

部写入前的数据保持一致，即写入

数据与读出数据始终是一致的。 数据一致性能够表明文件系统可以保

证数据的完整性，不会导致数据丢

失或数据错误，这是文件系统最基

系统往往由服务器集群组成，目前

可达到成千上万个核的集群 [3]。集

群需要具备 7*24 小时的正常运行

能力，并且有完善的容错能力，集

群的管理需要简单有效。此外，集

群具备高性能特点，包括毫秒级的

资源调度与负载管理。

2.2 大数据处理流程目前大数据领域处理大数据流

程图 [4] 如图 1 所示：

图 1 大数据处理流程

大数据处理流程分为 5个阶段：

(1) 大数据采集：利用多个

数据库来接收发自客户端户的数

据，并且用户可以通过这些数据库

来进行简单的查询和处理工作，处

理结构化数据和非结构化数据常用

工具为 DataHub。另外，用户日志

数据通常使用 Flume 进行，并使用

Kafka 进行日志数据的搬移工作。

(2) 大数据导入 / 预处理：将

采集端多种结构化数据库和非结构

化数据库导入大型分布式数据库，

并且可以在导入基础上做一些简单

的清洗和预处理工作，目前业界常

用的工具有 sqoop 和 Datax。(3) 大数据统计分析：将海量

的来自前端的数据快速导入到一个

集中的大型分布式数据库或者分布

式存储集群，利用分布式技术来对

存储于其内的集中的海量数据进行

普通的查询和分类汇总等，以满足

大多数常见的分析需求。

(4) 大数据挖掘：比较典型的

有基于聚类的 K-means、用于统计

学习的 SVM 等算法，该过程的难

点和挑战在于挖掘算法的复杂性，

涉及计算的数据量和计算量都非常

大。

(5) 大数据分析：获得数据用

来进行大数据分析，或者使用 BI工具产生报表供使用者作出正确有

利的决策，这是大数据处理技术要

解决的根本问题。该阶段的特点和

挑战是在具体业务背景大数据下，

如何保障业务的顺畅，有效地管理

分析数据，如何针对具体业务逻辑

作出决策。

2.3 大数据测试方法Hadoop 是目前最热门的大数

据处理架构，其数据处理架构及其

测试要点如图 2 所示，下面从功能

性测试和非功能性测试两方面来说

明大数据测试方法。

图 2 Hadoop 数据处理框架及其测试要点

2.3.1功能性测试

大数据功能主要涉及大数据分

析应用，包括文件读取与访问控制、

元数据操作、锁操作等功能。功能

测试需要覆盖根据大数据系统设计

实现的 API 和功能点。功能测试的

回归测试所占比例较高，采用自动

化测试方法进行测试 , 同时使用手

工测试进行补充 , 自动化测试工具

推荐使用 Selenium 与 testNg 的方式

实现。

本的功能。这部分测试可以应用编

写脚本进行自动化测试，LTP 也提

供了数据一致性的测试工具。

(5) 压力测试：大数据分析系

统的负载能力总是存在上限，当系

统过载时，系统就有可能出现性能

下降、功能异常、拒绝访问等问题。

压力测试就是要验证系统在一定压

力下的运行情况，包括数据多客户

端、高 OPS 压力、高 IOPS 吞吐量

压力 , 系统是否仍然能够正常运行、

功能是否正常。

3 证券领域大数据测试策略

3.1 大数据测试概述目前针对证券交易领域存在

存储空间不足、海量数据挖掘速

度缓慢、数据结构类型单一的问

题，证券交易领域结合自身实际发

展情况，构建符合证券交易领域的

大数据基础设施平台。证券交易

领域采用华为 FusionInsight HD 平

台构建企业级大数据存储管理平

台。华为 FusionInsight HD 平台是

基于 Apache 开源社区软件进行功

能增强的企业级大数据存储、查询

和分析的统一平台。大数据华为平

台产品 HDManager 架构图如 3 所

示。测试过程中侧重验证架构图中

组件功能与性能是否达到使用需求，

检测架构功能是否完善。值得注意

的是，架构组件性能测试与稳定测

试相关，重点需要测试平台消息队

列处理机制、日志信息采集何种速

度不停增长、组件间聚合性能与稳

定性、消息被索引和使用的速度、

MapReduce 作业、查询性能、搜索等。

依据 FusionInsight HD 大数据

统一管理平台提供的功能，并结合

证券交易领域目前发展特点和需

求，证券交易领域设计了符合发展

趋势的大数据平台架构，大数据平

台结构设计图如图 4 所示：

依据上述大数据平台架构设计

图，考虑到证券交易领域监管机构

纽带传输数据的情况，大数据平台

建设需要将传统数据库或数据仓库

数据迁移到大数据平台中，迁移过

程充分考虑了架构自身特点及证券

交易公司规章制度。大数据平台建

设的测试任务主要涉及两个方面：

数据迁移测试、基于大数据平台的

ETL 测试。

3.2 数据迁移测试技术目前数据迁移测试范围主要包

图 3 大数据华为平台产品 HDManager 架构图

行业观察 交易技术前沿Observation The Foreland of Trading Technology

64 65

行业观察 交易技术前沿Observation The Foreland of Trading Technology

64 65

括但不仅限于以下部分：元数据及

建模检查、数据迁移程序的准确性

及健壮性、历史数据迁移结果验证。

元数据及建模验证的步骤如

下：当传统数据库数据按照一定顺

序装入异构分布式数据完成后，检

查所有相关表、视图的属性，如库

名、表名等与原始数仓一致，检查

表中字段的数量、列名、类型、长度、

精度与 TD 数仓一致，命名规范等。

检查元数据文件大小是否、文件路

径、文件名称是否与预期一致。

数据迁移程序测试策略按照程

序操作手册配置源文件位置、大数

据平台分布式数据库连接，执行脚

本，检查程序日志，导入完毕后，

启动数据比对程序。健壮性测试主

要为设计输入错误场景，可根据应

急处置文档清理数据并重新装载或

覆盖数据。

历史数据迁移部分，自动化程

序验证数据表的策略分三个方面：

数据总量验证、字段校验、明细数

据验证。

(1) 数据总量验证：编写脚本

获取所有迁移数据表及其记录数。

对于每一张表，查询大数据平台中

该表的所有记录数，与原始数据库

中数据的总条数进行比较。特别需

要注意的是，需要根据数据表业务

逻辑含义编写测试用例，例如切片

表按照时间字段、拉链表开闭链字

段、全增全量表等。

(2) 字段校验：对于每张表的

数值字段，通过 sum，avg,group by等聚合函数编写测试用例，对各种

字符类型的数据进行分类，并使用

自动化程序对迁移前后的数据进行

验证。

(3) 明细验证：对于每张表通

过编写适当的测试用例来查询迁移

后的数据明细，验证大数据平台的

明细结果是否与迁移前数据一致。

通过上述三步设计合理的测试

用例来进行数据校验，可检测出数

据在迁移过程中发生的变化，以及

快速验证出数据迁移的错误信息。

考虑到迁移数据量级巨大，两个异

构数据库之间的查询比对工作量较

大，使用数据导出文件比较。根据

笔者的经验，比较高效率的方式是

首先计算数据文件每行的 hashCode值，然后依据结果值判断数据迁移

结果是否准确，同时需要设置每个

数据表的主键字段，以便进行数据

迁移结果不一致情况的问题定位。

3.3 大数据 ETL 测试3.3.1大数据 ETL

大数据 ETL 即从联机事务数据

图 4 大数据平台架构设计图

库中提取数据，进行转换处理，匹

配分布式数据库模式，然后载入至

分布式数据库中。ETL 是 Extract-Transform-Load 的缩写（提取 - 转换 - 载入），它是一个完整的从源系

统提取数据，进行转换处理，载入

至分布式数据仓库的过程。Extract提取有效的数据，Transform 将提

取的数据转换为大数据平台 ELK支持的模式 / 格式。构建 keys ：一

个 key 是一个或多个数据属性的

惟一标识实例，key 的类型可以是

主 键 (primary key)、 外 键 (foreign key)、 替 代 键 (alternate key)、 复

合键 (composite key) 以及代理键

(surrogate key)。这些 key 只允许数

据仓库进行维护管理，且不允许其

他任何实体进行分配。在提取好数

据后，则进入数据清理流程。数据

清理流程对提取数据中的错误进行

标识和修复，解决不同数据集之间

的冲突问题，使数据保持一致，以

便数据集能用于目标数据仓库。通

常，通过转换系统的处理，我们能

创建一些元数据（meta data）来解

决源数据的问题，并改进数据的质

量。Load 将转换后的数据载入数据

仓库。最后一步为构建聚集：创建

聚集对数据进行汇总并存储数据至

表中，以改进终端用户的查询体验。

ETL 处理流程图 5 如下所示：

3.3.2ETL 测试策略

依据上述 ETL 测试流程图，测

试人员在从事 ETL 测试时，还有两

份文档是 ELT 测试人员需要实时备

有的。ETL 映射表：一个 ETL 映

射表包含源和目的地表的所有的信

息，包括每个列及其引用表等约束

关系。ETL 测试人员需要更为优美

的 SQL 查询语句，因为在 ETL 测

试各阶段可能需要编写具有多个连

接的查询语句来验证数据。ETL 映 表 1 ETL 测试场景和测试用例

射表为数据验证编写查询时提供大

量的有用的信息。源、目标数据库

模式：该模式应该便于验证映射表

中的所有细节，为源和目的地之间

转换时的各个阶段的数据验证提供

基础信息。在此基础之上，测试人

员根据 ETL 测试场景进行划分，并

设计相应的测试用例，通常情况下

划分 ETL 测试场景和设计测试用例

可通过表 1 完成。

3.3.3ETL 测试流程

大数据 ETL 测试是为了确保从

源到目的地数据经过业务转换完成

后是准确的。同时它还涉及数据的

验证，即从源到目的地数据各个不

同阶段验证数据。与其他测试过程

类似，ETL 也需要经历不同的测试

阶段，ETL 测试过程主要分为以下

五大阶段，如图 6 所示。

4 总结

随着大数据时代的来临，信

息的积累与处理为证券行业的发

展注入了新的活力。而由于海量

数据的数据量及其分布式的特

点，大数据处理技术与传统数据

存储方式的不同给软件测试带来

新的挑战。本文抛砖引玉，结合

笔者的测试经验，对大数据测试

的相关技术进行了系统化的梳

理，主要涉及大数据数据如何验

证、大数据 ETL 测试策略等问

题，在大数据测试道路上进行了

探索。希望在以后的工作中，充

分利用大数据框架实现大数据测

试自动化，并对人工智能领域的

大数据测试方向进行深层次探索

与研究。

66 67

行业观察 交易技术前沿Observation The Foreland of Trading Technology行业观察 交易技术前沿Observation The Foreland of Trading Technology

66 67

行业观察 交易技术前沿Observation The Foreland of Trading Technology行业观察 交易技术前沿Observation The Foreland of Trading Technology

图 5 大数据 ETL 流程图

图 6 大数据 ETL 测试流程图

参考文献 ：

[1] 陈 如 明 . 大 数 据 时 代

的挑战、价值和应对策略

[J]. 移动通信 , 2012(17) ：

1415．

[2] 蔡立志 , 阎婷 . 大数据

背景下软件测试的挑战与展

望 [J]. 计算机应用与软件 ,

2014(2):5-8.

[ 3 ] FA N J i a n - q i n g , L I U

Han. Statistical analysis of

big data on pharmacog-

enomics [ J ] . Advanced

D rug De l i ve r y Rev iews,

2013, 65(7): 987-1000．

[4] 代 亮 , 陈 婷 , 许 宏 科 .

大 数 据 测 试 技 术 研 究 [J].

计 算 机 应 用 研 究 , 2014,

31(6):1606-1611.

基于事件驱动架构的企业级应用集成方法探究

江家仁 / 上海证券交易所 总工程师办公室 邮箱：jiarenjiang@sse.com.cn

68 69

行业观察 交易技术前沿Observation The Foreland of Trading Technology行业观察 交易技术前沿Observation The Foreland of Trading Technology

随着企业业务规模的不断扩大，应用系统的集成成为当今企业的迫切需求，

而采用结合了 EDA 技术和 ESB 技术的 SOA 架构企业应用集成模式可以有效地

解决传统中间件企业应用集成 (EAI) 点对点的集成方式存在的诸多问题，使企业

信息系统具备更强的扩展性，能够随时支持业务流程的变化需求。本文首先介

绍了目前适用于 EAI 的架构。然后分析事件驱动 SOA 模型特点，阐明 EDA 与

SOA 架构之间的关系以及它们互补的优势。接着对项目中需要采用的开发环境、

应用技术与实施过程进行简要论述。最后根据我的项目经验，详细论述基于事件

驱动 SOA 架构的企业应用集成模式设计过程，由下至上将系统分为四个层次，

包括服务总线层，数据适配层，流程控制层和应用工具层，阐明每一层的功能划

分以及层次交互流程。

随着企业业务规模的不断扩

大，应用系统和业务流程日益复杂，

而且这些应用系统由于开发时间不

同，采用的开发技术也不同，一项

业务请求很难有效地调用所有相关

的应用系统。对于产生的这类问题，

在 SOA 得以普及之前通常采用传

统中间件 EAI 的点对点集成方式。

在这种方式下为了保证所有的应用

系统能够互通互用，每对应用系统

都需要一个 EAI Server 来对应，这

样随着需要整合的应用系统数量的

增加需要开发的 EAI Server 会呈现

几何倍数增长。这显然不是解决问

题的妥善办法。因此，为有效地解

决传统 EAI 点对点的集成方式存在

的复杂度高，复用性差，可管理性

差和系统脆弱等问题，使企业信息

系统具备更强的扩展性，能够随时

支持对业务流程的变化，本文探讨

如何结合 EDA 技术和 ESB 技术来

设计企业应用集成模式，提出一种

便捷构建企业的资源共享、业务流

程整合的设计思路。

一、目前适用于 EAI 的架构介绍

面向服务的体系结构 (SOA) 是一种支持构件组装的松散耦合机

制，是构件技术面向服务的表现

形式。SOA 核心思想是 (1) 松耦

合 (2) 粗粒度 (3) 服务构件位置和

传输协议透明 (4) 服务构件可以

和各种传输协议自由绑定 (5) 提供完全和技术无关的业务接口。

SOA 架构的优点是实现了业务与

技术的完全分离 ；消除了应用集

成的各种本质障碍，使得各种业

务服务能够随意集成 ；针对市场

需求能够随需而变。

事件驱动的体系结构 (EDA) 是一种设计和构建应用的方法，EDA体系中各构件以异步方式响应事

件，在本质上是可以并行的，因而

在系统集成应用中具有极大的优

势。其具备以下特点 : (1) 支持异步

活动 (2) 支持并发执行 (3) 通过发布

/ 订阅方式，广播一个或多个事件，

支持多对多的交互 (4) 支持事件触

发、数据触发、时间规则触发 (5)实时、增量响应 (6) 分布式事件系

统处理。主要优点是为软件重用提

供了强大的支持；为构件的维护和

演化带来了便捷。（缺点是构件放

弃了对系统计算的控制。）

企业服务总线 (ESB) 可以看作

是系统的“缓冲器”和“转换器”，

但是与服务请求者和服务提供者之

间没有任何逻辑相关，属于松散耦

合互连的集成平台。ESB 本身可以

是单个引擎，也可以是由一些同级

和下级 ESB 组成的分布式系统，它

们协同工作以保证 SOA 系统的正

常运行。ESB 的核心功能包括 (1)提供服务位置的透明，解耦合服务

请求者与服务提供者之间的联系 (2)提供服务请求者与服务提供者之间

不同的传输协议格式的转换 (3) 提

供消息转换、消息路由、消息增强

的功能 (4) 支持对消息的加解密、

授权和认证能力，提供不同的安全

策略 (5) 提供监控和管理能力，能

够监控消息的大小和消息队列的吞

吐率，并管理消息队列。

二、事件驱动 SOA 模型分析

有些观点认为 EDA 的出现会

逐渐取代 SOA，其实这并不正确，

EDA 并不会完全取代 SOA，而会

对 SOA 形成补充，即形成“事件

驱动 SOA”。业务系统可以从中受

益匪浅，因为 SOA 业务问题属于

一对一的请求 / 响应机制，需要服

务请求者事先知道该服务提供者，

而随着 EDA 概念的引入正可以解

耦合这两者之间的联系，采用发布

/ 订阅机制，发布者可以传送消息

给满足订阅规则的任何数量的需要

者，并使系统具备并行快速处理事

务的能力。上述特点能很好地满足

我参与的这个项目的应用需求，例

如，实现跨部门的应急联动系统、

联合业务协同服务等应用。

从时间维度来看这种模型的优

势是：

◆ 短期利益：更容易定制，因

为设计对动态处理有更好的响应 ;◆ 长期利益：系统和组织的状

态变得更精准，对实时变化的响应

接近于同步。

三、项目采用的开发环境、应用技术与实施过程

在业务服务集成中，首先利用

Axis 来实现对原有的各个应用系统

进行打包，生成 Web 服务。基于

Axis 开发的 Web 服务可以直接运行

于 WebSphere 服务器，只要在该服

务器中包含 Axis 的 jar 包就行。在

服务器端发布完服务后，需要将生

成的 WSDL 描述文件发布到 ESB总线上，由服务注册中心负责调用

此描述文件来发现和绑定服务。最

后完成服务组装集成。

四、基于事件驱动 SOA架构的企业应用集成模式设计

采用 SOA 实现企业资源共享，

通常是把企业原有的应用和资源转

换成服务；把这些服务变成标准的

服务形式，通过企业服务总线发布

与查找，实现资源的共享。在本方

案架构中，系统分为 4 个层次设计，

如下图所示。

由下至上分别是服务总线层，

数据适配层，流程控制层和应用工

具层。

（1） 服务总线层 ：包括服务处

理器和服务管理器，为整个应用集

成环境提供底层支持，为其上各

层提供透明的消息传递。总线内

核是基于 JMS 的面向消息的中间

件 (MOM)，它包含点对点和事件

驱动 (EDA) 两种消息模型，在这

个项目中我采用后者，使用 EDA来发现系统中发生的特殊事件并

立刻发布给对此事件感兴趣的“订

阅方”，从而使“订阅方”能快速

做出响应。通过这种方式，ESB最大限度上解耦合了企业与合作

商的业务构件之间的依赖关系，

降低了系统的互连复杂度，加快

了系统的处理速度。例如，在集

成“跨部门的应急联动系统”时，

通过对销售商系统数据的实时采

集，利用 EDA 技术的事件触发与

事件过滤，实现对订单规格的变

更、缺货与增补库存等问题的快

图 1 事件驱动 SOA 架构图

70

行业观察Observation行业观察Observation

速通知和督办功能。

（2） 数据适配层 ：由数据转换

构件与适配器组成，提供标准数据

转换，屏蔽不同系统在数据标准上

的差异，解决应用集成服务器与被

集成系统之间的信息孤岛问题，使

企业的数据资源充分共享。

（3） 流程控制层 ：是对业务过

程的建模。利用业务流程管理 (BPM)技术实现不同系统间流程的衔接，

并结合 Rule Engine 技术实现业务流

程基于业务规则的智能化运行。 其中业务流程对应企业的现实流程，

对它的管理就是对企业的现实流程

的端到端管理。

（4） 应用工具层 ：包括用户应

用界面，ESB 后台管理界面等模块。

它为用户在界面上提供一个统一的

信息服务功能入口，将内部的和外

部的各种相对分散独立的信息组成

一个统一整体。 整个架构的层次交互流程的

业务应用操作主要是通过 " 流程控

制层 " 分解成为多项单一功能的服

务请求，在 " 数据适配层 " 完成数

据转换。然后将转换后的请求发

送到 " 服务总线层 " 的服务处理器

中，根据需要由处理器调用日志管

理模块和安全管理模块，进行安全

方面的检验和记录。无误后解析请

求，然后将请求提交给服务管理

器，由它去查询服务注册表来获得

服务的绑定信息及相对位置，并将

查询结果加入到请求的参数容器对

象 (PCO) 中。完成后，服务管理器

调用服务实现，并把执行结果传回

PCO 重置参数。最后由服务处理

器将处理结果封装，“数据适配层”

进行转换，并在“流程控制层”完

成组装，返回业务响应给“应用层”

客户。

五、按体系结构组织开发团队

开发小组要做到松耦合，高内

聚。在项目的架构层次稳定之后，

可以按开发人员精通、擅长领域的

不同来组织开发小组。因为每个层

次都有属于自己的专门技术，与其

他层次的接口清晰。这样将不同的

层次分配给对应领域的开发小组，

就能减少各开发小组之间的沟通成

本。而在小组内部，由于是处理小

领域问题，例如负责开发 ESB 的小

组，成员一般都掌握了 JMS, WSDL与 UDDI 的专业知识，容易建立起

有效的沟通机制，保证项目开发的

顺利推进。

六、不足与改进

尽管本文对 SOA 以及 ESB 技

术做了较为深入的研究，但是随着

这些技术的不断发展，还存在以下

不足有待改进：

（1） 基于 SOA 的安全性问题

对企业应用非常重要，本文中没有

对“安全策略管理”进行详细探讨，

希望在今后的应用中对此作进一步

研究，使其能针对具体业务调用合

适的安全策略。

（2） 虽然 EDA 能作为 SOA 系

统的一个有效补充，弥补 SOA 系

统的一些不足。但从目前情况来看，

EDA 系统还只是处理简单事件的系

统，对于复杂事件的处理还有待进

一步的研究，希望未来使其能够广

泛应用于复杂事件处理引擎中。

（3） 没有对工作流进行深入研

究，对于业务流程的编排没有涉及，

希望在以后的开发过程中给以关

注，使系统能够更好的自由协同工

作。

七、结束语

本文以 EDA 技术和 ESB 技术

为基础架构，把企业中不同的应用

系统和业务流程进行了整合，支撑

了企业的资源共享、业务流程自动

化以及业务创新。随着 EDA 技术

的不断发展以及相应开发框架和

IDE 工具的不断成熟，EDA 在系统

集成应用中可以发挥更大的作用，

从而简化企业的资源共享 , 及业务

流程整合的复杂度，为快速、高效

地构建系统应用集成提供一种便捷

的设计思路与方法。

资讯I nformation

12 监管科技全球追踪

7372

交易技术前沿

The Foreland of Trading Technology信息资讯I nformation

一、概述

金融科技（FinTech）作为各

金融机构和基础设施越来越重视的

领域，目前正在迅速发展中。技术

的创新也正在被监管当局以及金融

科技企业使用，用以加强合规，满

足监管需求。澳大利亚、日本、新

加坡、英国等国也各自推出了支持

金融科技发展的举措，鼓励利于消

费者利益的创新，创建良好的竞争

环境。

政府为了适应对 FinTech 的监

管，有效提高监管效率和降低监管

成本，纷纷引入 RegTech 来实现监

管职能。全球监管机构之间除了制

定合作安排之外，主要通过以下四

种方式去广泛的研究金融科技和监

管科技相关的技术问题：

·描绘金融科技发展形势

·建立“创新中心”

·监管沙箱

·尝试全方位去定义金融科技

从而达到提升监管水平、持续

监管创新、降低监管成本和防范监

管套利的作用。

2012 年 至 2017 年 初， 全 球

RegTech 领域股权融资达 29.9 亿

美元，涉及 405 次融资，其中美

国的 RegTech 交易数量占总量的

78%。在全球 20 个国家和地区的

前 153 家 RegTech 公司中，涉及

监管报告（20 家）、风险管理（27家）、用户身份识别（39 家）、合

规咨询（48 家）、交易监控（19 家）

五个方向。

监管科技全球追踪二、相关概念和定义

本文节选翻译自 WFE 信息推送《FinTech： A Regulatory Mapping Introduction》，仅限内部阅读，如需转载、

引用或获取原文请与本杂志编辑部或 WFE 联系。

整理翻译：孙增 徐丹 / 上交所技术有限责任公司 规划部 邮箱：zsun@sse.com.cn

·分布式账本技术（DLT）

·智能投顾（Robo-advisors）

分布式账本技术是指可以跨多

个站点、地理位置或机构的网络共

享资产数据库，所有参与者可以拥

有相同的分类账副本，账本的任何

更改都会在几分钟甚至几秒钟内反

应在所有副本中。资产的类型可以

是金融产品、法律、实物或电子记

录。资产存储的安全性和准确性则

通过数字签名和密钥加密来实现。

·金融科技（FinTech）

金融科技是指任何在金融行业

中的技术创新，包括金融教育、小

额银行、财富投资甚至加密货币（如

比特币）。

“沙盒”一词指的是允许企业

在真实市场环境下，面对真实消费

者测试创新产品、服务、商业模式

或交付机制的一种实践。“沙盒监

管”是一个“安全空间”，在这个

安全空间内，金融科技企业可以测

试其创新的金融产品、服务、商业

模式和营销方式，而不用在相关活

动碰到问题时立即受到监管规则的

约束。

“沙盒监管”模式允许在可控的

测试环境中对金融科技的新产品或

新服务进行真实或虚拟测试，该模

式在限定的范围内，简化市场准入

标准和流程，豁免部分法规的适用，

在确保消费者权益的前提下，允许

新业务的快速落地运营，并可根据

其在沙盒内的测试情况准予推广。

·人工智能（AI）：

·区块链（Blockchain）

·大数据（BigData）

·云计算（Cloudcomputing）

人工智能是指机器模拟的智

能，机器被编程，对人类的行为模

式和思考方式进行模仿。人工智能

的一个特征是它有能力去采取行动

以期达到一个特定目标的相对最佳

结果，利用机器来表现人类思维的

特性，例如学习和解决问题。

区块链是一种数字化、分布

式的加密货币交易记账技术。随着

区块（最新的交易）不断增长，交

易记录会按照时间顺序被排列和记

载。它允许市场参与者跟踪数字货

币的交易，每个节点会自动下载并

保持一份拷贝。

区块链是一个多方参与的分布

式数据库，用高度的数据冗余实现

低成本的信任建立，用密码学保证

信息安全和权属安全，用共识机制

和网络通信形成防篡改、防作伪的

一种新型协作范式。

大数据的发展使得如今结构化

和非结构化数据量飞速增长、数据

创建和收集的速度不断变快、以及

数据的涵盖范围不断扩大，且数据

通常来自多个数据源，并拥有多样

化的数据格式。

云计算是一种能够实现随取随

用、按需访问、快速配置的便捷的

计算资源共享池（例如网络、服务

器、存储、应用以及服务），实现

管理成本和服务交互的最小化。

·数字货币首次公开募集（ICOs）

ICO 和 IPO 的运作模式相似，

是公司用来向公众筹款的方式。ICO涉及向投资者发行数字代币，通过

分布式账本技术创造加密货币（如

比特币、以太坊等）向投资者出售。

在大多数情况下，所得款项将被用

于公司业务或项目的早期发展资金。

如果在满足相应证券法规或法律的

条件下适当展开，ICO 其实是可以

作为一种筹集资金的新方式。

智能投资顾问提供智能化、算

法驱动、几乎不依靠人工决策的金

融服务平台，一个典型的机器人顾

问根据客户的财务状况信息与预期

收益，利用数据分析来提供投资建

议 / 或进行自动投资。

监管科技利用新技术的发展帮

助克服金融服务中的监管挑战。

监管科技（RegTech）是金融机

构利用新技术（大数据、云计算、人

工智能等）更加有效和高效地解决监

管合规问题，减少不断上升的合规费

用；监管科技（SupTech）是监管机

构基于（大数据、云计算、人工智能

等）新兴科技，主要用于维护金融体

系的安全稳定，实现金融机构的稳健

经营以及保护金融消费者权利。

·监管科技（RegTech）（SupTech）

·监管沙盒（Regulatorysandbox）

三、全球各大国际组织对 FinTech 和 RegTech的理解与实践

1、国际证券委员会组织（IOSCO）

在 2016 年第一季度，IOSCO董事会要求其新兴风险委员会

（CER）开始关注证券市场的技术变

革。 随后，在 2016 年的证券市场

风险展望文件中，将技术和数字应

用识别为改变金融形势的主要驱动

因素。CER 试图通过编写近期的金

75

交易技术前沿

The Foreland of Trading Technology

74

信息资讯I nformation

使命和责任。

2）LabCFTC 内部有两个核心

组件：

·GuidePoint ：FinTech 创新者

与 CFTC 合作的专门联系人，了

解 CFTC 的监管框架，并获得关于

市场创新技术理念实施的反馈和信

息。这样反馈可能包括信息 - 特别

是在早期阶段 - 可以帮助创新者 /实体节省时间和金钱，帮助他们理

解相关法规和 CFTC 的监管方式。

·CFTC 2.0 ：通过 CFTC 自身

开始采用新技术的活动，促进并帮

助金融科技行业和 CFTC 市场参与

者合作。

(2) 货币监理署 (OCC)2016 年，OCC 分别在华盛顿、

纽约和洛杉矶创建“创新办公室”，

旨在通过“创新办公室”，直接与

FinTech、RegTech 等金融创新公司

对话，了解现阶段金融创新情况，

鼓励新技术发展，并将新技术应用

于监管领域。

(3) 金融业监管局 (FINRA)FINRA 在 2017 年 6 月 建 立

了“ 创 新 外 展 活 动（Innovation Outreach Initiative）”, 与 OCC、

CFTC 类似，FINRA 希望通过建立

“创新外展活动”来推动金融应用

和金融监管的双重创新。

目前，美国没有正在运行的监

管沙箱。这个概念已经通过立法提

出（和通过包括美联储，财政部和

证券交易委员会在内的各种监管机

构），但都没有获得批准。由于当局

数量庞大，以及企业实体可能受到

众多联邦和州监管机构的影响，这

样的概念可能很难在美国成功实施。

亚太地区1、澳大利亚

澳大利亚的政策目标是鼓励金

融科技的发展，而不是过度监管。政

府承诺将澳大利亚建成金融科技中

心，并寻求主要通过以下方式鼓励和

支持新的金融科技企业在澳设立：

·通过澳大利亚证券和投资委

员会（ASIC）的监管沙盒为合格实

体提供许可豁免；

· 与 澳 大 利 亚 审 慎 监 管 局

（APRA）合作，减少金融科技实体

进入银行业的障碍；

·提供特定用于智能投顾的监

管指导；

·澳大利亚证券和投资委员会

（ASIC）建立和运营创新中心，通

过各种法规要求，为金融科技企业

提供向导。

（1）创新中心包含 5 个要素：

·参与其他的金融科技计划；

·对符合条件的初创企业提供

非正式援助，以帮助尽早考虑重要

的问题；

·设立专门的网站为创新企业

提供量身定制的指导和路径，便于

他们获取针对性的信息和服务；

·通过高级内部工作组协调新

业务模式上的工作流程；

·成立数字金融咨询委员会

（DFAC）（成员包括金融科技界

的成员，学者和学者消费者），向

ASIC 提供有关该领域工作的建议。

（2）“监管沙箱”实践

2016 年 3 月，澳大利亚联邦政

府批准澳大利亚证券和投资委员会

（ASIC）成立“监管沙盒”机制。同

年 12月，ASIC 发布《监管指引文件》。

对于符合条件的金融科技公司，在

其向 ASIC 申请备案之后，无需持金

融服务牌照或信贷许可证即可测试

特定业务，并且之后 ASIC 可能根据

具体的测试结果修改相关法律。

“监管沙箱”禁止的申请对象

·被禁止开展金融服务和信贷

服务的公司

·已获得金融服务牌照和信贷

许可证的公司

·获得金融服务或信贷持牌机

构授权开展业务的公司

·金融服务或信贷持牌机构的

相关法人团体

2、香港

香港政府及其监管机构对金融

科技（FinTech）在监管方面采取了

技术中立的立场。证券及期货事务

监察委员会（证监会）表示，其持

牌机构及新进入者均可部署“在香

港规则和标准下取得正确结果”的

技术。

香港金管局于 2016 年成立金融

科技监管沙箱（FSS），让授权的机

构能够进行实地试验测试 FinTech 的

举措，如生物认证，证券交易和区

块链技术。旨在促进授权的金融科

技机构及其他技术创新的试验。在

“监管沙箱”中进行了登记注册的金

融科技公司，在完成业务报备的情

况下，允许开展与现行金融制度和

法律法规有冲突的 Fintech 业务。

香港金管局还推出了 FinTech Supervisory Chatroom - FinTech Supervisory Sandbox 2.0 的新功能。

旨在向那些计划使用新技术的被监

管机构和科技公司提供监管反馈，

从而减少没有成效的工作并加速推

出新技术应用。被监管机构或科技

公司可以通过电子邮件，视频会议

或与金管局面对面会议等方式进入

该聊天室。

（1）“监管沙箱”的申请对象

香港金融管理局设置的“监管

沙盒”的服务对象仅限于需要进行

金融创新的香港当地银行以及为银

行的业务流程提供技术创新的科技

公司。

（2）“监管沙箱”的测试情况

融科技（FinTech）创新报告和分布

式账本（DLT）分别应对技术和数

字应用着两种驱动因素。

CER 与 IOSCO 的附属会员咨

询委员会（AMCC）密切合作，设

立了一个新的金融技术专题小组。 在这个金融科技专题小组中，WFE主持分布式账本（DLT）工作，美

国国家期货协会主持金融科技

（FinTech）工作。

2017 年 2 月，IOSCO 发 布 了

FinTech 的研究报告，分析了证券

市场行业技术驱动变化的潜力，简

要描述 FinTech 对投资者和金融服

务的影响，金融服务业技术驱动型

变革的趋势越发明显，主要原因有：

·数据可用性不断提高；

·计算能力的指数级增长，有

助于分析更大的数据集；

·获得商品和服务的渠道越来

越多和成本不断降低；

·去中介和再融通的需求增长

等。

为了跟上创新，监管机构采取

积极措施，例如：设立金融科技专

业办事处，联络点和中心 ; 启动监

管沙箱计划 ; 以及旨在发现新技术

如何帮助实现更好监管目标的实验

室和加速器计划。

面临的金融科技风险可能来

自：

·无牌跨境活动；

·算法中的编程错误；

·网络安全违规；

·投资者未能了解金融产品和

服务；

·金融公司未能“了解客户”。

2、金融稳定委员会（FSB）在未来几年里，随着新技术被

推广采用，以及越来越多的数据被

使用，金融稳定委员会指出对金融

稳定而言，有以下好处和风险：

·更高效的信息处理能力有助

于提高金融系统效率；

·AI 和机器学习的应用，会导

致金融市场和金融机构间意想不到

的相互关联形式；

·新技术的网络效应和可扩展

性会可能会导致对第三方的依赖性

越来越高；

·AI 和机器学习的方法缺少可

解释性或可审计性，可能成为宏观

层面的风险。

四、全球各地区对FinTech 和 RegTech 的理解与实践

美洲地区1、加拿大

加拿大证券管理机构（CSA）

推出了监管沙箱，以支持提供创新

产品的企业，服务和应用程序。适

用于 CSA 监管沙箱的潜在商业模式

示例包括：

1）在线平台，包括众筹门户，

网上贷款，天使投资者网络或 其他用于证券交易和咨询的技术创新 ;

2）使用人工智能进行交易或

建议的商业模式 ;3）基于风险投资的加密货币

或分布式账本技术 ; 4）证券行业的技术服务提供

商（包括面向非客户的风险和合规

支持服务 -RegTech）。此外，安大略省证券委员会

（OSC）成立了 LaunchPad，是一个

FinTech 加速器，也是 OSC 的一个

部门，用于对接金融科技公司，帮

助他们理解法规要求，并努力使监

管与数字化创新保持同步。

2、美国

FinTech 通常在美国联邦和州一

级考虑。 总的来说，政府对金融科技

的监管立场是确保消费者、公众获得

相同的传统法律保护下促进创新。

金融科技业务通常受到与其他

传统业务相同的监管。 但是，一些

联邦政府代理机构和州已经设立了

特定的许可和认证，以解决某些金

融科技行业的独特需求。

自从 2014 年市场咨询专业委

员会（GMAC）听证会以来，商品

期货交易委员会（CFTC）一直在

考虑分布式账本技术好（DLT）和

虚拟货币。商品期货交易委员会

（CFTC）自开设全球性专业以来一

直在考虑 DLT 和虚拟货币，并概述

鼓励创新的 5 个实际步骤：

·监管机构需要与金融科技公

司合作的专家 ;·监管机构应创造刺激创新的

监管环境 ;·监管机构应直接参与 FinTech

概念验证 ;·监管机构需要在设计现代市

场规则时听取金融技术专家的意见 ;·监管机构需要在全球范围内

协作，并帮助企业在国内和国际司

法管辖区内行事。

(1) 商 品 期 货 交 易 委 员 会

（CFTC）商品期货交易委员会实验室

（LabCFTC）旨在使 CFTC 更易于

接触到 FinTech 创新者，并为 CFTC对新技术的理解提供信息的平台。

此外，LabCFTC 作为 CFTC 工作人

员对创新技术反应的信息来源，可

能会影响政策的制定。

1）LabCFTC 的使命有两方面：

·促进负责任的金融科技创新，

提高美国市场的质量、弹性和竞争力 ; · 加 速 CFTC 与 金 融 科 技

和 RegTech 解决方案的接触，使

CFTC 能够更加有效和高效履行其

77

交易技术前沿

The Foreland of Trading Technology

76

信息资讯I nformation

截至 2017 年 10 月 31 日，已有 9 家银行的 25 项金融创新产品在香

港金融管理局的“监管沙盒”中试行。

其中，11 项产品已完成测试，后续

将陆续投向市场；15 项产品是由银

行与配套科技公司合作研发。

2017 年 9 月底，香港证监会和

香港保监会沿用 HKMA“监管沙盒”

的运行标准，分别推出“证监会监

管沙盒”和“保险科技监管沙盒”。

另外，香港证券及期货事务监

察委员会所关注的金融科技子行业

包括：

·自动交易系统，包括由算法

驱动的交易系统；

·金融产品投资和分销平台，

包括机器顾问和基金分销平台；

·融资平台，包括提供证券或

集体的点对点贷款和股权众筹平台

投资计划；

·分布式账本技术，包括将区

块链应用于特许中介机构，证券和

资本市场；

·大数据，数据分析和人工智

能支持持牌中介机构的前台和后台

运营；

·合规性，风险和监管技术，

包括支持法规遵从和监管报告的技

术并了解你的客户；

·网络和数据安全技术，包括

安全的客户端认证技术。

3、日本

日本的主要金融监管机构金融

服务局（FSA）正在设计促进日本

FinTech 发展的途径，包括与 Open API 有关的新法规、在 FinTech 合

资企业的银行投资、众筹和虚拟投

资货币以及放宽现有金融监管下的

要求，以适应新技术发展等。

4、新加坡

新加坡金融监管机构新加坡金

融管理局（MAS）表示，监管不应

该在创新之前实施，因为过早引入

监管会扼杀创新。 相反，监管方式

应该是以相称的方式平衡的新技术

带来的风险。金管局还推出了各种

金融技术举措，以促进新加坡成为

金融中心 / 金融科技中心。

欧洲、中东以及非洲地区1、阿布扎比

阿布扎比全球市场的金融服

务 监 管 局（FSRA） 于 2016 年

推出了一份关于“监管实验室

（RegLab）”的计划，允许企业在

金融服务部门部署创新技术，在可

控的范围内进行一些试验尝试，来

发展创新的金融科技产品和服务。

监管实验室提供给金融科技公司

在一整套定制的监管环境下开展

试验创新的监管框架，这不仅降低

了成本以及金融科技公司的负担，

同时不损害消费者的权益，并保持

了市场的完整性。

（1）监管实验室

代替从一开始授权批准一整套

监管规则的传统做法，而是根据业

务模式、技术部署以及风险来定制

化一套规则。

在监管实验室的框架下，金融

科技公司参与者将获得为期 2 年的

发展时间，在可控的环境下试验和

发布他们的产品和服务。试验之后

切实可行的商业模式将被转移到全

授权的监管制度下（前提是成功地

证明遵守授权标准）。若在 2 年内

没有准备好，将退出监管实验室。

另外，在 2017 年召开的阿布

扎比首届全球金融科技大会还宣布

了两大举措，一是成立金融科技创

新中心，二是和其战略合作伙伴建

立全球最大的创业加速器项目。

（2）阿布扎比全球金融科技创

新中心

提供一片实体区域供金融科技

公司进行创新，为阿布扎比培育一

个互动协作的创新生态圈。这将包

括提供给初创金融科技企业与金融

机构的合作空间、投资者、潜在的

合作伙伴，以及网络和活动设施等。

创新中心将启动加速器项目，吸引

和培育金融科技企业和来自世界各

地的公司来这里发展。当然该中心

也将会是监管实验室（RegTech）参与者的基地。

（3）金融科技门户网站

一个专门的在线门户网站，为

参与者提供直接的金融科技监管指

导，帮助他们形成自己的监管业务

计划和测试范围、了解监管要求并

了解不断变化的环境。

2、迪拜

2017 迪 拜 金 融 服 务 管 理 局

（DFSA）宣布，将允许金融科技

公司申请一种金融服务牌照——金

融服务创新试验牌照（ITL）。这

种限制型金融服务牌照允许合格的

金融科技公司在迪拜国际金融中心

（DIFC）的管辖之下进行创新产品

的开发和测试，而不必遵循适用于

常规公司的监管要求。迪拜金融服

务管理局（DFSA）将与参与者一起，

充分了解企业的计划，建立适当的

安全控制。

这项举措是在迪拜国际金融中

心（DIFC）启动“金融科技储备

（FinTech Hive）”项目之后开展的，

目的是为了汇集优秀的新一代企业

家和领导者，通过竞争和发展推动

创新与技术，来解决本土市场日益

增长的金融服务需求，同时催化如

贸易金融、另类金融等一系列领域

的增长和效率提升。

3、法国

法国金融市场管理局（AMF）创建了一个管理金融科技创新和竞

争力的分部，其职责主要是：

·应对由于技术发展和全球化

引起的金融消费模式改变；

·分析机会与风险，参与欧盟

讨论，同时研究金融市场管理局

（AMF）政策；

·维持高度的投资者保护策略。

此外，金融市场管理局（AMF）和监督管理局（ACPR）还共同推

出了金融科技主题论坛，提供金融

科技行业的磋商和对话机制，以明

晰金融创新的合规要求与监管挑

战。

4、德国

德国的联邦监管机构（BaFin）采取的方法是，无论是传统的商业

模式还是创新的金融服务形式，监

管措施均需贯彻。一般来说，BaFin对 FinTech 商业模式持积极开放

态度，并建立了一个专门的网站

（https://www.bafin.de/EN/Aufsicht/FinTech/fintech_node_en.html）， 对

监管如何应用于 Fintech 商业模式

有不同典型的详细信息阐述。BaFin还会积极地纵览市场，参加各类相

关会议以及 FinTech 相关的现场讨

论活动，同时还做好准备在必要时

候将其信息提供范围扩大到新的商

业模式。

对于 Fintech 公司而言，牌照

将与传统的金融服务无差异，并且

没有类似“监管沙箱”的机制。在

BaFin 的机制下，金融科技公司获

取牌照的要求如下：

·众筹投资平台根据他们的商

业模式可能需要银行或投资服务、

或基金管理的资质牌照；

·去中介化的众筹借贷模式在

相关借贷法规条件下需要一种特殊

的“小牌照”；

·智能投顾和自动化交易以及

基于智能投顾的社会交易通常需要

投资服务资质牌照，除非完全基于

投资基金，在这种情况下，“小牌照”

可能就足够了；

·由于虚拟货币被视为金融工

具，与其相关的交易、中介、包括

交易平台将都需要投资服务牌照。

德国联邦财政部也推出了自己

的金融科技营（FinCamp），旨在

与德国金融科技公司促进对话。第

一次活动主题主要聚焦在数字银行

业的未来，约 150 名来自德国的

FinTech 初创企业、各大银行、协会、

财政部、德意志联邦银行以及联邦

金融监管局的代表出席。联邦政府

还创建了一个新的“FinTech 委员

会”（2017 年 3 月），成员包括各大

Fintech 公司的代表以及监管当局，

主要希望通过这样的机制提供一个

对话窗口。

5、英国

英国财政部的监管创新计划

（2017 年 4 月）指出，政府的一项

关键政策目标是确保支持开发新的

商业模式，打破进入壁垒，发展技

术，提高生产率。鼓励金融服务创

新也被认为比英国退欧具有更高的

优先级。英国政府打算创造一个适

当的监管环境，以确保创新型企业

能够竞争和发展，而不是受限制。

2014 年 10 月金融行为管理局

（FCA）设立“项目创新（Project Innovate）”计划旨在与新的企业建

立联系，为创新的开展消除不必要

的障碍。其中一个关键元素就是

“创新中心”，它已经帮助了 300 多

家企业在市场上投放创新产品和服

务。该中心还具有前瞻性的作用，

探索新技术的同时了解监管需要改

变的领域，以促进消费者的利益创

新。企业可以在开展业务的第一年

得到专门的监管支持。创新项目主

要包含五方面内容：

·FCA 通过对话的形式了解

FinTech 公司的需求，基于对他们

的充分理解，帮助其适应监管；

·为 FinTech 公司提供自动化

的合规指导与建议，帮助其理解现

行监管要求，提升业务合规性；

·广泛听取学研机构和企业的

意见，通过机构合作和技术共享，

发展和完善 RegTech ；

·实施“监管沙盒”，为 Fin-Tech 公司营造更好的发展环境，同

时在沙盒内检验新技术的实用性；

·鼓励国际合作，在企业层面

和政府层面进行广泛合作，共同探

讨行业标准，鼓励英国的 FinTech公司拓宽海外市场，以及为进入英

国市场的 FinTech 公司提供帮助。

2016 年 5 月 FCA 还建立了 “监

管沙箱（Regulatory Sandbox）”，它

提供了一个环境，使新成立的和现

有的公司（不管是否受监管）可以

在不受强制管制后果的情况下进行

试验。FCA 还鼓励行业（通过创

新金融论坛）建立一个“虚拟沙箱

（Virtual Sandbox）”，使企业能够在

虚拟环境中使用他们公开的数据进

行实验。

（1）“监管沙箱”的特点：

·所有机构都可申请进入监管

沙箱，极大地扩大了金融创新出现

的领域范畴；

·申请者将就其提交的创新产

品或服务得到监管部门个性化的建

议或指引；

·测试环境中将设置包括消费

者保护等内容在内的一些基本监管

要求；

·测试过程中，消费者仍拥有

其他合法权利，如向企业投诉、寻

求申诉等。

（2）“监管沙箱”评估标准：

·产品或服务必须是一项切实

7978

信息资讯I nformation

的创新：申请沙箱测试的产品或服

务必须是独创的，或者和市场上已

有的产品差异较大；

·必须对消费者有利：申请的

产品或服务必须描绘出未来能向消

费者提供可确认益处的前景，比如

更高质量的服务或者更低的价格；

·必须存在进行沙箱测试的必

要性：这家公司必须有在真实的客

户中并且是在 FCA 沙箱中测试产品

或服务的切实必要；

·公司必须对测试做足准备：

需要测试的产品或服务必须对真实

环境中的测试做好准备。

在沙箱内的企业有一定的限制

授权，允许他们测试他们的想法，

因此他们只需要在测试的范围内满

足门槛条件。与金融监管的许多其

他领域不同的是，支付领域已经允

许实施更轻的监管（例如通过小额

授权付款机构）。FCA 通过沙箱可

以授予“免执行函件”、个别指导（对

于相关规则和豁免的解释）以及提

供相关法定范围的规则修改。

沙箱中参与者的生命周期通常

会遵照：

·议案的提交；

·FCA 对合格标准的评估；

·测试方法的确定；

·开展测试与监测；

·报告和评价阶段；

·决定是否可在沙箱之外提供

该项产品或服务。

去年财政部的一份报告“UK FinTech – On the Cutting Edge” 中

指出：

·人才：英国既有良好的人才

储备，同时有丰富的金融实践经验；

·资本：早期投资是好的，尽

管英国风险基金的风险偏好低于美

国的同类等价物；

·政策：英国拥有积极正面的

监管环境；

·需求：金融服务活动的集中

提供了一个很好的平台，为金融科

技提供了解决方案（如交易监管、

数据等）。

尽管英国被普遍认为是实施

FinTech 政策措施方面的 “第一推

动者”，但其他国家也正在迎头赶

上，差距逐渐在缩小。CFTC 主席

Christopher Giancarlo 指出：“英国

的努力使其成为新兴技术创新监管

的黄金标准。”

《交易技术前沿》是上海证券交易所主管，上交所技术公司主办的技术类期刊，以季度为单位发

刊，主要面向全国证券、期货等相关金融行业的信息技术管理、开发、运维以及科研人员。

征稿主题如下 ：

一、金融科技（FinTech）金融科技是一个比较宽泛的结合了目前主流的金融服务框架和大数据、人工智能、机器深度学

习等手段的一种科技新生态的简称。

( 一）FinTech 关键技术和应用场景

主要包含但不限于：大数据应用方面：风控，监管，信用体系，用户细分，预测；云计算应用

方面：基础设施服务，平台服务，软件服务；区块链应用方面：跨境交易，跨境支付，抵押品管理；

人工智能应用方面：智能投顾，智能风控。

( 二 )FinTech 在证券期货行业的应用模式

主要包含但不限于：大数据在证券期货行业的应用；云计算在证券期货行业的应用；区块链在

证券期货行业的应用；人工智能在证券期货行业的应用。

二、云计算云计算是一种基于互联网的计算方式，通过这种方式共享的软硬件资源和信息可以按需求提供

给计算机和其他设备。 （一）云计算架构

主要包含但不限于：云架构剖析探索，云平台建设经验分享，云计算性能优化研究。

（二）云计算应用

主要包含但不限于：云行业格局与市场发展趋势分析，国内外云应用热点探析，金融行业云应

用场景与实践案例。

（三）云计算安全

主要包含但不限于：云系统下的用户隐私、数据安全探索，云安全防护规划、云安全实践，云

标准的建设、思考与研究。

三、人工智能金融业作为信息化程度较高的行业，首先受到人工智能的巨大影响，主要表现为：服务模式更

加主动和大数据处理能力大幅度提升。

（一）应用技术研究

主要包含但不限于：语音识别与自然语言处理，计算机视觉与生物特征识别，机器学习与神经

网络，知识图谱，服务机器人技术。

（二）应用场景研究

2018年二季度《交易技术前沿》

征稿启事

8180

主要包含但不限于：智能客服、语音数据挖掘、柜员业务辅助等。

主要包含但不限于：监控预警、员工违规监控、交易安全等。

主要包含但不限于：金融预测、反欺诈、授信、辅助决策、金融产品定价、智能投资顾问等。

主要包含但不限于：金融知识库、风险控制等。

主要包含但不限于：机房巡检机器人、金融网点服务机器人等。

四、数据中心数据中心是一整套复杂的设施。它不仅仅包括计算机系统和其它与之配套的设备，还包含冗余

的数据通信连接、环境控制设备、监控设备以及各种安全设备。 （一）数据中心的迁移

主要包含但不限于：展示数据中心的接入模式和网络规划方案；评估数据中心技术合规性认证

的必要性；分析数据中心迁移过程中的影响和业务连续性；探讨数据中心迁移的实施策略和步骤。

（二）数据中心的运营

主要包含但不限于 ：注重服务，实行垂直拓展模式；注重客户流量，实行水平整合模式；探寻

数据中心运营过程中降低成本和提高服务质量的途径。

五、分布式账本技术（DLT）分布式账本技术是指可以跨多个站点、地理位置或机构的网络共享资产数据库，所有参与

者可以拥有相同的分类账副本，账本的任何更改都会在几分钟甚至几秒钟内反应在所有副本中。

资产的类型可以是金融产品、法律、实物或电子记录。资产存储的安全性和准确性则通过数字

签名和密钥加密来实现。

（一）主流分布式账本技术的对比

主要包含但不限于：技术架构、数据架构、应用架构和业务架构等。

（二）技术实现方式

主要包含但不限于：云计算 + 分布式账本技术、大数据 + 分布式账本技术、人工智能 + 分布式

账本技术、物联网 + 分布式账本技术等。

（三）应用场景和案例

主要包含但不限于：结算区块链、信用证区块链、票据区块链等。

（四）安全要求和性能提升

主要探索国密码算法在分布式账本中的应用，以及定制化的硬件对分布式账本技术性能提升的

作用等。

投稿说明

1、本刊采用电子投稿方式，投稿采用 word 文件格式（格式详见附件），请通过投稿信箱 ftt.editor@sse.com.cn 进行投稿，收到稿件后我们将邮箱回复确认函。

2、稿件字数以 4000-6000 字左右为宜，务求论点明确、数据可靠、图表标注清晰。

3、本期投稿截止日期：2018 年 6 月 25 日。

4、投稿联系方式 021-68813289, 021-68800293 欢迎金融行业的监管人员、科研人员及技术工作

者投稿。稿件一经录用发表，将酌致稿酬。

《交易技术前沿》编辑部

证券信息技术研究发展中心（上海）

附件：

标题：（黑体 二号 加粗）

作者信息：（姓名、工作单位、邮箱）（仿宋

GB2312 小四）

摘要：（仿宋 GB2312 小三 加粗）

关键字：（仿宋 GB2312 小三 加粗）

一、概述（仿宋 GB2312 小三 加粗）

二、一级标题（仿宋 GB2312 小三 加粗）

（一）二级标题（仿宋 GB2312 四号 加粗）

1、三级标题（仿宋 GB2312 小四 加粗）

（1）四级标题 （仿宋 GB2312 小四）

正文内容（仿宋 GB2312 小四）

图：（标注图 X. 仿宋 GB2312 小四）

正文内容（仿宋 GB2312 小四）

表：（标注表 X. 仿宋 GB2312 小四）

正文内容（仿宋 GB2312 小四）

三、结论 / 总结（仿宋 GB2312 小三 加粗）

四、参考文献（仿宋 GB2312 小四）

杂志订阅与反馈 各位读者，2018 年《交易技术前沿》旨在继续为行业分享优质前沿的技术文章。由于邮寄订阅名单开

始收录的时间较早，部分信息已需待更新。为更好精确定位我们的受众与读者，服务读者需求，我们将从

本期开始采用电子订阅方式重新梳理杂志的订阅名单。

如您想继续订阅杂志的纸质版，欢迎扫描左侧二维码填写问卷进行订阅，同时可

以向我们提出关于杂志的建议与意见反馈。如您希望赏阅电子版，欢迎访问我们的电

子平台 http://www.sse.com.cn/services/tradingservice/tradingtech/sh/transaction/（或扫描

杂志封面尾页二维码），我们的电子平台不仅同步更新当期的杂志文章，同时还提供

往期所有历史发表文章的浏览与查阅，欢迎关注！