新一代证券交易系统应用架构的研究

网友投稿 1496 2023-03-07

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

新一代证券交易系统应用架构的研究

本文选自《交易技术前沿》总第三十八期文章(2020年3月)

摘要:随着国内外证券市场的持续发展,当前的证券交易系统已越来越难以满足业务上的需求。本文从证券行业的应用现状出发,分析证券业务对交易技术的新需求,研究设计新一代交易系统应用架构,解决当前交易系统普遍存在的耦合过紧、效率不高、扩展性差等问题,以支持新业务的快速上线,并满足不同类别客户做全业务的需求,从而更好的支持未来证券交易业务的发展。

一、引言

证券公司目前普遍采用的是集中式的交易系统,集中交易系统是证券公司最重要的一套系统,它几乎覆盖了所有的场内证券业务和部分场外业务。可以说,集中交易系统为证券行业十几年来的稳定发展做出了巨大贡献。然而,随着证券业务越来越复杂、交易品种越来越丰富,集中交易系统上集成了越来越多的业务逻辑,而且目前的集中交易架构普遍采用的是单体结构,系统的拆分、扩展能力有限,导致系统过于臃肿,越来越无法适应业务的快速发展。另一方面,随着外部接入的放开,量化交易客户对交易速度的要求越来越高,集中交易系统完全无法满足量化交易业务对性能的要求。于是,很多证券公司引入了针对量化业务的量化交易系统。然而,集中交易系统和量化交易系统是两套独立的体系,在架构上难以做到互相融合,这就制约了客户做全业务的需求。因此,证券行业急需研究、建设新一代的交易系统,而有的券商已经开始在尝试。

二、证券行业新一代交易系统应用现状

新一代交易系统在证券行业中的应用主要基于以下两种模式。

(一)基于极速框架的应用模式

这种模式的核心思想是,以性能为核心,基于极速交易架构,从机构客户试点开始,试图扩展到全客户、全业务。基于极速框架设计的交易系统应用在极速交易业务是可行的,但如果要扩展到集中交易业务,就会面临以下两方面的挑战:一方面,它设计的出发点是极速,对服务拆分的能力有限,特别是核心交易引擎依然是一个单体结构。它的分布式主要体现在水平扩展方面,比如可以复制出多个交易引擎来实现高可用,但要对交易引擎做垂直拆分是比较难做到的,因为拆分增加了交互复杂性,必然影响性能,失去了极速的意义。所以如果采用这种模式,随着业务不断增加,将会面临目前单体架构普遍遇到的问题。另一方面,普通的股票交易客户(俗称“散户”)对交易延迟是不敏感的,是否有必要投入极速交易架构?极速交易架构相比普通交易架构需要付出更多的成本代价,但是这种架构在极速方面所做的优化对集中交易业务而言并不能带来更多的业务价值,也就是投入产出比不高。因此这种架构模式具有应用上的局限性,并不适合推广到所有业务。

(二)基于微服务框架的应用模式

这种模式的核心思想是,以分布式为核心,基于微服务架构,试图对交易业务进行完全解耦,并且容量和功能可扩展。微服务的架构本身是比较先进的,主要面临的挑战是落地实施。

一方面,服务拆分之后,服务之间的关系复杂,增加了管理和运维的难度。微服务架构之所以能够在互联网公司流行,是因为它们对研发的投入非常大,能够对微服务组件进行定制开发和维护;而以券商目前的研发实力是比较难做到的。另一方面,服务拆分之后就会带来一些分布式的问题,比如原来都在一个系统里通过一个事务指令可以完成,现在拆分到了多个系统,如何保证分布式事务的一致性?这是一个难题。这些挑战说明了微服务架构在证券行业还不到大规模落地的时候,特别是针对核心交易系统。

三、证券业务对交易技术的需求分析

(一)证券业务对快速交付的需求

由于目前的交易系统都是集中式的单体结构,随着业务越来越复杂,集中交易系统集成了太多的业务逻辑,导致系统过于庞大,缺乏灵活性,改动升级代价大、风险高,无法适应业务上快速交付的需求。例如,理财业务属于各个公司的个性化业务,它具有一定创新性、需要通过不断探索完善其功能,因此需要频繁发布更新。理论上,理财业务的更新不应该影响其他业务。而实际上由于目前所有业务都耦合在一个系统上,任何一个业务的变更都可能影响其他业务,所以任何一个业务的变更都会导致其他业务也需要同步构建、测试和发布,极大的影响了交付的效率,无法满足业务对上线时间的要求,也无法适应未来敏捷开发的需求。

(二)证券业务对交易速度的需求

1. 不同业务对交易速度的需求

场内交易业务对交易系统的要求,除了要满足基本的功能需求之外,越来越多的体现在对交易时效性的要求上。交易速度甚至是某些业务最核心的诉求。交易速度的提升不仅能够捕捉更多的市场机会,为客户带来更大的收益,也是券商核心竞争力的体现。下面从交易时效性出发,根据交易速度对业务竞争力的影响,笔者对交易业务进行了分类(见表1)。

总体上可分为实时和非实时两类,其中非实时业务表示对时效性没有太多要求,或者需要较长时间(分钟级以上)才能完成交易的业务;而实时业务则表示客户需要即时完成交易 的业务,或者交易结果会受实时行情影响的业务。实时业务又可以进一步细分为极速和快速两个子类别。

A类(极速需求):交易速度是业务的核心需求之一,速度越快越能增加业务的竞争力,也越能增加公司在行业的影响力。B类(快速需求):交易速度对业务有一定影响作用,但业务竞争力还受其他因素如算法、外部环境等的影响;或者由于交易量占比不大,对公司整体利润没有实质性影响。C类(普通需求):交易速度只需要达到客户接受的范围内即可(如秒级),速度的提升对业务的竞争力几乎不产生影响。

2. 不同客户对交易速度的需求

从客户的角度出发,不同的客户对交易速度的需求是不同的。但随着程序化交易的普及,越来越多的客户将意识到交易速度的重要性,因为它将直接影响收益,例如抢涨停板、套利、逃顶等。下面根据客户的交易方式和当前的市场竞争力,分析交易业务的速度指标需求(见表2)。

总体上分为量化客户和普通客户。普通客户指的是目前市场上占绝大多数的散户。量化客户指的是机构客户和一些专业的个人投资者,他们借助现代统计学和数学的方法,利用计算机技术来进行交易。其中量化客户又进一步细分为普通量化客户和极速量化客户。

I级(量化客户-极速):对A类业务的交易速度非常敏感,因为资金量大并且交易频繁,客户有意愿投入更多成本用于提升交易速度。II级(量化客户):客户关注交易速度,并且借助计算机程序自动化执行,基本上能够跑赢市场上绝大多数的散户。在其他条件不变的情况下,客户希望速度越快越好。III级(普通客户):客户对交易速度并不敏感,因为是通过纯手工操作,秒级内的延迟对他们的影响并不大。

四、新一代证券交易系统应用架构设计

(一)交易分级设计

速度和容量等需求对软件设计和硬件规格的要求是不同的,因此根据前面对业务和客户的分级需求,证券公司需要建设分层次的交易系统,以达到成本和收益的最佳组合(如图1所示)。

图1:分级交易系统

(1)普通交易系统:定位于面向所有普通客户进行全部场内和部分场外交易。系统实现的目标是稳定、容量大并支持全业务,技术上主要采用传统的数据库作为存储组件。

(2)快速交易系统:定位于有快速交易需求的量化客户做场内实时业务。系统实现的目标是高性能、高可靠性、容量可扩展,并支持场内绝大部分业务;技术上主要采用目前较为先进的内存交易技术。

(3)极速交易系统:定位于需要极致交易速度且资金量大的少量托管量化客户或自营业务。系统实现的目标是交易通道的低时延,技术上采用目前最先进的软、硬件加速机制。

为满足所有客户对全部业务的交易需求,对每类系统的功能和边界进一步详细划分(见表3)。

除了满足业务需求外,上表对各层次功能的划分主要考虑了以下因素:(1)技术可行性主要受两个方面的影响:一方面是业务逻辑复杂度。越复杂的软件或硬件,执行速度必然越慢,也越难以进行调优,所以融资融券交易业务最好不要放在极速柜台中实现。另一方面是系统的并发量。单机的性能随着并发量的上升而下降,但并发量超过单机阈值时就面临拆分或分布式部署,进一步增加系统复杂性。所以极速柜台只能面向少量客户。(2)建设与管理成本:理论上速度快的系统完全可以满足慢速系统的时效性需求,但越快的系统需要投入的成本会越高,所以极速层和快速层都设定了准入门槛,不可能接入所有的客户。(3)用户体验:让客户切换使用系统意味着损失了客户的便捷性,在其他条件不变的情况下应用尽量让客户在一个系统中完成所有业务。

(二)服务化设计

服务化设计主要解决普通交易系统的快速交付问题。服务化设计最关键的要点是如何把控拆分的粒度。下面根据Gartner对服务化定义的三种不同拆分粒度[1]进行分析:(1)宏服务(MacroService):这是目前普遍存在的系统,就是类似于单体架构,基于共享数据和公共的访问接口,它的主要优点是方便管理。(2)小服务(MiniService):基于中粒度的服务,将单体架构拆分成少数相对独立的服务,主要目标是改善敏捷性。

(3)微服务(MicroService):基于小粒度的服务,每个服务拥有私有的数据、私有的接口,服务之间调用关系复杂,主要目标是实现持续集成、持续交付。基于MacroService的架构是券商的现状,根据前面的分析这种架构的问题比较突出;而基于MicroService架构存在的问题在前面章节也已经分析过,目前并不适合在证券行业大规模推广。所以真正适合证券行业的服务拆分方式是基于MiniService的架构,因为它既能达到解耦的目的,也不会带来太大的复杂性。借鉴MiniService的思想,以及对业务快速交付需求的分析,下面对集中交易的业务进行拆分。如果拆分粒度太大就达不到解耦的目标,如果拆分过细又会导致管理复杂,所以需要进行权衡,权衡的标准就是业务的变更频率。因为不同业务的变更不应该互相影响,这是解耦的主要目标,越是变更频繁的业务越能够成为独立拆分的备选服务。因此,根据从实践中统计的变更频率大小,集中交易业务适合拆分成如下独立的服务(如图2所示)。

图2:普通交易系统的服务化拆理财服务:理财销售与管理,如场外基金、金天利等;两融服务:融资融券、转融通的业务逻辑处理;债券服务:债券交易、质押回购、协议回购等业务逻辑处理;交易服务:对接证券交易所的场内交易通道;资产中心:管理客户的资金、股份数据;账户中心:管理客户的账户数据,如客户适当性数据等;清算中心:实现统一清算逻辑,从各系统采集数据并分发交收后结果。(三)极速化设计

极速化设计主要解决引进快速交易系统和极速交易系统后面临的架构问题。

1. 资金股份管理

交易系统分级之后需要解决的一个问题就是客户的资产(即资金和股份)如何管理。一种方案是采用集中的管理方式,也就是通过独立的资产中心管理所有客户的资金股份。这种方案的优势是方便管理,但无法满足低时延的需求,特别是对于极速交易系统,如果每次交易都需要到另一个系统查询、更新资产数据,将极大影响性能。因此,一种更合理的方案是对资产数据按客户类型进行拆分(见图3)。I级客户的资产数据部署在极速交易系统,II级客户的资产数据部署在快速交易系统,III级客户的资产数据部署在普通交易系统。由于III级客户的数量比较大,并且对交易速度要求不高,根据前面服务化设计思路,可以拆分出针对III级客户的独立资产中心。

图3:客户资产按客户类别独立拆分和部署

三类资产数据之间不交叉,每个客户只有一份资产数据并且部署在尽量快的系统中,以此来保证交易速度,并避免了客户要在不同系统之间做资金调拨。

2. 交互解耦设计

当客户的资产数据被拆分之后,就会出现系统之间交互的问题。比如有一个I级客户要购买金天利,因为他的资金是存储在极速交易系统的,而业务则在普通交易系统中处理,所以这两个系统就需要进行交互;而其它系统也类似,因此正常情况下所有交易系统之间两两都需要交互,复杂度急剧上升。为了解决这个问题,通过引进一个服务调度中心来解耦交易系统之间的这种交互关系(见图4),当需要请求资金时通过服务调度中心进行转发。每个系统只需要对接服务调度中心,减少了交互复杂性。

上一篇:网络运维学习(网络运维入门培训)
下一篇:ApplicationHost.config文件被破坏导致IIS崩溃
相关文章

 发表评论

暂时没有评论,来抢沙发吧~