证券核心交易系统的平台架构设计

2024-05-27 10:05

作者 | 邓正威
apache/dubbo-go committer、seata-go 项目发起人
GitHub：jasondeng1997
前五百强外企全球创新业务技术负责人，GOTC 特邀嘉宾，目前服务于国内某Top证券交易机构，负责核心交易系统开发。

什么是核心交易系统

核心交易系统包括后台交易系统、中台系统、前台系统等，按照架构层次可分为网络架构，存储架构，主机架构，应用架构。

为什么要分这么细

交易系统架构中的服务管理、流量管理、配置管理、故障容错和可观测性问题，如何去解决、选用什么架构来解决、系统之间是否会存在冲突等等，相信已经让不少前辈开发者难以招架。

在交易系统中，需要解决这些交易系统架构中的问题，通常都会部署以下服务。

网络架构：解决高可用，低时延，高吞吐，网络安全，隔离性
存储架构：可靠性，数据安全，容灾
主机架构：高可用，容灾，扩展性
应用架构：RTO,PRO,扩展性，弹性，稳定性

可以发现，要解决这些问题不得不部署多个架构，并且每个架构都有各自的管控平台，数据联动性差，不细分，难以有一个全局的视角让用户可以很好的管理。

为什么还要使用总线架构

1. 微服务架构有其特点，但交易系统是异步的复杂事务，需要高流动性，总线架构更适合。

2. 券商类系统对吞吐量要求不高，总线架构更能满足需求。

3. 选择总线架构需面临服务和治理问题，需加强总线管理。

4. 总线架构易导致管理混乱，需收紧管理来补足。

整体技术架构

竞价撮合平台（MTP）：

竞价撮合平台为市场参与者提供股票、基金交易业务。目前竞价撮合平台包括A股和B股两个市场，支持的业务包括核心撮合交易、IPO申购、融资融券、指定/撤销指定等。

竞价撮合平台的报单软件是交易网关TDGW、EzOES。

综合业务平台（ATP）：

综合业务平台主要为市场参与者提供创新类业务支持，包括大宗交易、转融通、盘后固定价格、非公开发行优先股、货币式基金申购赎回、ETF申购赎回、LOF申购赎回、国债预发行、约定购回、报价回购、股票质押式回购、网络投票等业务。

综合业务平台的报单软件是EzStep。

期权业务平台（DTP）：

期权业务平台主要为市场参与者提供股票、ETF标准化期权合约的核心撮合交易、行权业务。

期权业务平台的报单软件是EzStep、TDGW。

港股通平台（ITP）：

港股通平台主要为市场参与者提供香港联合交易所规定范围的港股交易业务。

港股通平台的报单软件是EzStep。

券商传统信息系统多采用单体架构模式开发，把所有的功能都打包在一个独立单元中，并当作一个整体来开发、测试和部署。

然而，随着业务的爆炸性增长，应用系统规模不断增大，单体架构将给业务系统的开发、维护、部署带来巨大的问题。

为何叫核心交易系统？

证券交易系统由分散走向集中。90 年代，证券经纪业务以营业部为单位，每家营业部都有自己的系统和数据。

粗放的管理模式导致风险事件频发。2004 年左右，行业风险集中爆发，促使国家开始整治证券行业。

随后，证券公司开始部署集中式证券交易系统，由技术部门统一管理，这一代系统被称为“核心交易系统”，沿用至今。

核心交易系统承载哪些职能

核心交易系统是按照满足券商经纪业务来设计的，因此承载了很多业务职能。大致可以分为如下几大类：

1、账户业务。可以为客户进行账户开户、销户、管理业务权限、处理与交易相关的适当性管理、合规报送等。

2、资金业务。早期通过银证转帐实现，后来全面实行了客户保证金三方存管制度。

3、证券交易业务。处理投资者提交的各类交易指令，按照交易规则进行资金和证券的处理，并实现与交易所的委托和成交指令的对接。

4、信用交易业务。2010年证监会推出融资融券业务试点，投资者可以通过向证券公司融资买入股票，也可以融券卖出股票，实现了杠杆交易。系统需要按照信用交易的业务规则处理各类交易指令。

5、基金代销业务。投资者可以通过证券账户购买开放式基金产品，系统处理投资者的产品申购赎回指令，并实现与相应基金公司的指令交互和资金、份额结算。

6、清算业务。负责与交易所、登记结算公司进行数据交互和业务核对，完成客户在交易所内产品的资金、股份清算和结算。

7、查询业务。满足客户需要的各种交易流水、对账单、交割单等业务数据。

8、理财产品销售。券商为扩大客户投资品种范围，自行提供的各类理财产品的销售。

9、现金余额理财业务。可将客户投资账户上的现金余额自动申购为货币基金，提高客户的资金收益。

10、其他管理职能。系统参数设置、客户账号安全、外围系统接入、异常交易监控等。

不难看出，核心交易系统是一个综合性的业务系统，它的技术架构经历了怎样的演进，设计过程需要考虑哪些要素，又遇到到哪些挑战呢？

核心交易业务有哪些特点？

核心交易系统架构的理解，需先明晰其所承载业务的特点。与其他金融业务相较，证券交易业务具有时效性这一显著行业特点，具体表现为：

1. 交易时段受限：交易所开盘时间仅为 4 小时，仅在此时间段内的指令会被处理。

2. 竞价交易规则：交易通过竞价实现，遵循价格优先与时间优先原则。若指令提交过慢，可能错失最佳成交时机。

“时效性”特点决定了核心交易系统在设计时需满足以下特性：

1. 极强的稳定性与高可用性：尤其在交易时段，需确保高可用性。

2.卓越的性能指标：保障客户交易指令快速抵达交易所。

3. 主要业务集中于开盘时间处理，因此系统需具备充足容量，并能随业务规模扩大灵活扩展。

证券业务的第二个行业特点为业务的外部性。证券开户需通过登记结算公司，交易需通过证券交易所，资金转账需借助存管银行，基金交易需连接基金公司，交易清算则依赖交易所与登记结算公司提供的结算文件。

“外部性”特点决定了核心交易系统在设计时，需充分考虑与外部系统的交互逻辑及业务规则的对应关系。

第三个特点是金融产品的多样性。各类金融产品的交易、结算、交收规则各异，要求业务系统具备出色的灵活性，以适应不同金融产品的业务处理要求。

第四个特点是业务的合规性。依据资本市场主体责任划分，券商需对交易合规性进行前置检查，严禁证券卖空、资金透支等交易风险，因此业务系统需确保业务逻辑的一致性。

证券交易系统技术架构演进之路

第一代的核心交易系统主要供应商包括恒生电子、金证股份、金仕达软件等，基本都采用了三层架构。如下图所示：

系统共分为三层：

1. 接入层：通常为高性能消息中间件，负责渠道系统的接入和业务消息传输。

2. 业务逻辑层：一般包含业务处理中间件框架，负责将业务消息分配至不同业务处理模块进行处理。各业务模块通过与数据库交互，处理相应业务请求。与外部系统相关的业务，则产生相应业务请求并发送至外部系统，如交易所报盘、银行转账、登记结算公司账户开户等。

3. 数据库（数据层）：通过传统关系型数据库存储所有业务数据，部分系统通过存储过程实现部分业务逻辑。

这一代核心交易系统通常具备以下特点：

1. 利用数据库事务一致性原理，实现业务逻辑的强一致性。如证券交易要求客户资金冻结和订单委托保持一致，系统会将这两个数据库操作封装在一个事务中处理，确保其一致性。

2. 数据库承担大量业务处理逻辑，为满足交易系统对容量和延时的要求，需配置高性能软硬件设备。软件基本采用 Oracle、DB2 等数据库，硬件则采用 IBM 小型机设备，并配备 EMC 高端存储，是典型的 IOE 架构。

3. 业务中间件负责业务流程的组织，拥有统一的业务处理框架，通过将不同业务分拆为可动态加载的模块，实现系统功能扩展，但其核心逻辑仍为对数据库的操作。中间件一般设计为无状态模式，可任意增加，单台故障不影响业务连续性和数据一致性。

4. 通过数据库复制软件将业务数据复制到备机和灾备机，实现业务系统的备份和灾备。正常情况下，备份系统仅执行查询业务，不处理交易指令。如主机发生故障，可启用备份系统。如主备系统均不可用，可切换至灾备机。系统的可用性水平（如 RTO，RPO）主要取决于数据库复制的速度。

第一代核心交易系统架构简单，稳定性良好，但也面临巨大挑战：

第一代证券交易系统采用数据库事务强一致性方案，导致资源争用严重，数据库成为系统容量和性能瓶颈，券商被迫使用高性能硬件设备提高系统容量，降低交易延时，增加了系统部署和维护成本。

同时，单台数据库系统容量存在上限，交易处理延时下降也存在理论下限。由于每项证券业务均使用客户资金信息，资金信息成为资源争用的焦点。数据库事务易造成数据资源死锁，对业务逻辑编写要求高，加剧业务耦合，使系统研发和维护成本不断增加。

第一代证券交易系统自 2005 年进入券商，基本满足当时市场业务需求。但随着资本市场快速发展，尤其在经历 2008 年牛市行情，市场成交量逐步放大的背景下，部分券商开始尝试解决核心交易系统可能面临的容量和性能问题。

第一个思路是寻找支持事务一致性的分布式数据库系统，试图从数据库层面解决容量问题，DB2 曾发布类似产品，但最终未获供应商支持。而 Oracle RAC 架构的推出，解决了主备数据库的数据同步和高可用问题，因此得到全面实施。

第二个思路是业务逻辑前移，将主要计算逻辑从数据库迁移至业务中间件处理，降低数据库负载。但由于证券业务并非计算密集型应用，而是数据操作性应用，最终仍需与数据打交道，该方案只能部分降低数据库负载。

第三个思路是将客户按一定规则分拆，通过部署多个交易中心，解决单交易中心的性能容量问题。该方案得到供应商支持，纷纷发布新的核心交易产品，可称为第二代核心交易系统。如图：

客户分拆可提升系统容量，但受数据库事务强一致性约束，单笔交易延时仍大。为解决此问题，供应商尝试使用弱事务一致性处理交易逻辑，将交易分解为两步，降低事务原子级别，异常时通过反向交易回冲账务，保证业务正确性。

弱一致性可提高系统吞吐量，降低单笔业务延时。恒生电子 UF2.0 综合采用客户分拆、弱一致性事务等机制，在券商中广泛应用。但由于数据库限制，交易延时仍为 10ms 量级。

弱一致性虽带来好处，但降低了系统数据一致性，局部故障时可能导致资金和证券数据不一致，需通过日志和流水恢复状态。

在供应商的推动下，券商从2009年开始全面部署第二代核心交易系统，随后证券市场开始出现了新的变化，包括：

1、部分券商将账户系统、数据查询功能、理财产品销售功能、清算子系统从核心交易系统中剥离，以优化经纪业务运营体系、完善客户服务、提高系统性能和稳定性。

2、不同券商在如何给核心交易系统进行架构优化上有不同的思路，因此没有形成行业统一的产品形态。

3、瘦身后的核心交易系统功能更加纯粹，聚焦在高效稳定支持各种场内业务的交易、清算、合规管理等职能。

4、快速交易系统将交易延时缩短到 100 微秒左右，但数据全部保存在内存中，损失了一定的高可用性，且吞吐量也受到了一定限制。

5、券商交易系统进入了一种融合的架构模式，即核心交易系统与快速交易系统并存。

虽然以数据库为中心的交易系统经过了各种架构优化，但交易延时只能缩短到 10ms 左右，仍无法满足专业投资者的需求。

因此，供应商开始推出全内存化的快速交易系统，专门服务少量的专业投资者。这种系统只有交易功能，账户业务、资金划拨、清算等均依托核心交易系统。所有业务全部在内存中完成处理，且每个客户的业务均采用串行化处理，以确保数据的一致性。

快速交易系统将交易延时提升了一个量级，达到了 100 微秒左右，有些供应商的系统甚至更快。

然而，由于数据全部保存在内存中，系统的高可用性有所损失，并且由于业务串行化处理，吞吐量也受到了一定限制。

因此，单个节点的快速交易无法承载很多客户，券商会根据需要部署多套快速交易系统，有些甚至会部署不同供应商的快速交易系统。

这样，券商交易系统就进入了一种融合的架构模式。如下图所示：

这种融合架构的核心交易系统部署方案，已在大部分券商的生产系统得到实施。

未来会怎样？

可以明确的是，于资本市场即将到来的未来：

1、投资者结构必定会持续朝着机构化的方向演进，将服务好机构投资者视为关键要点。

2、专业投资者对于交易系统的核心需求依旧是高吞吐量以及低延时，且会愈发提升。

3、监管部门针对交易系统的业务连续性监管必定会愈发严格，标准亦会越来越高。

4、在大环境以及国际形势不明朗的情况下，开源节流也成为券商主流，导致了交易系统更加信创化，国产化。

END

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。

来源: qq

点击查看作者最近其他文章