证券交易系统架构演进
券商作为证券市场的中介机构，承担了为广大投资者提供证券交易通道的市场责任。你知道交易指令是如何传递到交易所并最终成交的吗？
上图是一个典型的券商交易系统逻辑架构，手机App、网上交易等系统称为渠道系统，职责是为投资者提供交易渠道，并对指令做初步的要素检查，最终所有合法交易指令都会发送到集中交易系统进行统一业务逻辑处理。所有处理均完成后，把合法的投资指令发送给交易所竞价系统进行撮合。
集中交易系统在证券经纪业务中处于核心地位，它具有怎样的系统架构，承担了那些业务职能，是如何一步步演进过来的，现在又遇到哪些挑战，未来可能会向那些方向发展？本文从一个技术工程师的角度，尝试做一点剖析和探讨。
一、为何叫集中交易系统？
从名字上看，一定是从分散的交易系统整合而来的，事实上也确实如此。在上世纪90年代证券市场发展初期，证券经纪业务是以营业部为单位开展的，每家营业部都有自己的证券交易系统，单独保存自己的业务数据。粗放的管理模式带来了巨大的业务隐患，出现了诸如修改客户结算数据、挪用客户保证金、伪造客户交易指令等风险事件。2004年左右，整个行业风险经过多年累积，呈现集中爆发的态势，出现了“南方证券”，“德隆系”等一系列重大风险案件，促使国家开始对证券行业进行综合整治。也就是从这个时候开始，所有证券公司开始部署集中式的证券交易系统，由技术部门统一运营管理，这一代的证券交易系统也开始被行业内称为“集中交易系统”，并一直沿用至今。
二、集中交易系统承载哪些职能
集中交易系统是按照满足券商经纪业务来设计的，因此承载了很多业务职能。大致可以分为如下几大类：
- 账户业务。可以为客户进行账户开户、销户、管理业务权限、处理与交易相关的适当性管理、合规报送等。
- 资金业务。早期通过银证转帐实现，后来全面实行了客户保证金三方存管制度。
- 证券交易业务。处理投资者提交的各类交易指令，按照交易规则进行资金和证券的处理，并实现与交易所的委托和成交指令的对接。
- 信用交易业务。2010年证监会推出融资融券业务试点，投资者可以通过向证券公司融资买入股票，也可以融券卖出股票，实现了杠杆交易。系统需要按照信用交易的业务规则处理各类交易指令。
- 基金代销业务。投资者可以通过证券账户购买开放式基金产品，系统处理投资者的产品申购赎回指令，并实现与相应基金公司的指令交互和资金、份额结算。
- 清算业务。负责与交易所、登记结算公司进行数据交互和业务核对，完成客户在交易所内产品的资金、股份清算和结算。
- 查询业务。满足客户需要的各种交易流水、对账单、交割单等业务数据。
- 理财产品销售。券商为扩大客户投资品种范围，自行提供的各类理财产品的销售。
- 现金余额理财业务。可将客户投资账户上的现金余额自动申购为货币基金，提高客户的资金收益。
- 其他管理职能。系统参数设置、客户账号安全、外围系统接入、异常交易监控等。
不难看出，集中交易系统是一个综合性的业务系统，它的技术架构经历了怎样的演进，设计过程需要考虑哪些要素，又遇到到哪些挑战呢？
三、集中交易业务有哪些特点？
要理解集中交易系统的架构，先要看看它承载的业务有哪些特点。与其他金融业务相比，证券交易业务有一个非常大的行业特点，就是时效性。主要表现在：
- 交易时段限制。交易所开盘只有4个小时，在开盘时间范围内的指令才会得到处理。
- 竞价交易规则。交易达成是通过竞价实现的，竞价规则是价格优先+时间优先。如果指令提交太慢，就可能错过最佳的成交时间。
“时效性”的特点，决定了集中交易系统在设计时，必须要满足以下特性：（1）极强的稳定性和高可用性，尤其是在交易时段的高可用性（2）有竞争力的性能指标，保障客户的交易指令能快速到达交易所（3）主要业务都在开盘时间内集中处理，因此需要有足够的系统容量，并能随着业务规模的扩大灵活扩容。
证券业务的第二个行业特点是业务的外部性。证券开户需要通过登记结算公司，交易需要通过证券交易所，资金转帐需要通过存管银行，基金交易需要连接基金公司，交易清算需要依赖交易所和登记结算公司提供的结算文件。
“外部性”的特点，决定了集中交易系统在设计时，需要充分考虑与外部系统之间的交互逻辑和业务规则间的对应关系。
第三个特点是金融产品的多样性。各种金融产品的交易、结算、交收规则各不相同，要求业务系统具有很好的灵活性，能适应各种不同金融产品的业务处理要求。
第四个特点是业务的合规性。根据资本市场的主体责任划分，券商需要对交易的合规性进行前置检查，不允许出现证券卖空、资金透支等交易风险，因此就要求业务系统要保障业务逻辑的一致性。
四、证券交易系统技术架构演进之路
第一代的集中交易系统主要供应商包括恒生电子、金证股份、金仕达软件等，基本都采用了三层架构。如下图所示：
系统一共分为三层：
- 接入层，一般为一个高性能的消息中间件，负责渠道系统的接入和业务消息传输。
- 业务逻辑层，一般包含业务处理中间件框架，负责将业务消息分配到不同的业务处理模块进行处理。各业务模块通过与数据库交互，处理相应的业务请求。与外部系统相关的业务，则产生相应的业务请求并发送到外部系统，如交易所报盘、银行转账、登记结算公司账户开户等。
- 数据库，也称为数据层，通过传统的关系型数据库存储所有的业务数据，也有些系统通过存储过程实现部分的业务逻辑。
这一代的集中交易系统一般都有这几个特点：
（1）通过数据库的事务一致性原理，实现业务逻辑的强一致性。如证券交易要求客户的资金冻结和订单委托必须保证一致性，系统就会把这两个数据库操作封装在一个事务中处理，确保其一致性。
（2）数据库承担了大量的业务处理逻辑，为了达到交易系统对容量和延时的要求，必须配置高性能的软硬件设备。软件基本都采用了Oracle、DB2等数据库，硬件则采用IBM的小型机设备，并配备EMC的高端存储。是一种典型的IOE架构。
（3）业务中间件负责业务流程的组织，有统一的业务处理框架，通过将不同的业务分拆成可以动态加载的模块，实现系统功能的扩展，但核心逻辑仍然是对数据库的操作。中间件一般会设计成无状态模式，可以任意增加，单台故障也不会影响业务连续性和数据一致性。
（4）通过数据库复制软件将业务数据复制到备机和灾备机，即实现了业务系统的备份和灾备。正常状态下，备份系统只能执行业务查询，不能处理交易指令。如主机发生故障，可将备份系统启用。如主备系统均不可用，则可切换到灾备机。系统的可用性水平（如RTO，RPO）主要取决于数据库复制的速度。
第一代集中交易系统架构简单，系统的稳定性也很好，但也遇到了极大的挑战，包括：
（1）由于采用了数据库事务强一致性的方案，导致存在严重的资源争用，数据库成为整个系统的容量和性能瓶颈。券商被迫使用高性能的硬件设备来提高系统容量，降低交易延时，这又导致了高昂的系统部署和维护成本。而且从理论上讲，单台数据库系统有容量上限，交易处理延时下降也存在理论下限。
（2）由于每一项证券业务都在使用客户的资金信息，因此资金信息成为资源争用的中心。数据库事务很容易造成数据资源之间的死锁，因此对业务逻辑的编写有很高的要求，加剧了业务之间的耦合，使系统的研发和维护成本越来越高。
第一代证券交易系统从2005年开始进入券商，基本满足了当时的市场业务需要。但随着资本市场的快速发展，特别是在经历了2008年的牛市行情，市场成交量逐步放大的背景下，部分商开始尝试解决集中交易系统可能面临的容量和性能问题。
第一个思路是寻找支持事务一致性的分布式的数据库系统，试图从数据库层面解决但数据库面临的容量问题，DB2也曾发布过类似的产品，但最终未能得到供应商的支持。但Oracle RAC架构的推出，解决了主备数据库的数据同步和高可用问题，因此得到了全面实施。
第二个思路是业务逻辑前移，将主要计算逻辑从数据库迁移业务中间件处理，降低数据库的负载。但由于证券业务并非计算密集型的应用，而是数据操作性的应用，最终还是需要和数据打交道，这种方案也只能部分降低数据库的负载。
第三个思路是将客户按一定的规则进行分拆，通过部署多个交易中心，解决单交易中心的性能容量问题。这个方案得到了供应商的支持，纷纷发布了新的集中交易产品。这可以称为第二代集中交易系统。
通过客户分拆，理论上系统的容量可以没有上限，但在单个节点上，由于数据库事务强一致性的约束，单笔交易的系统延时还是很大。为了解决这个问题，供应商开始尝试使用弱事务一致性来处理交易逻辑，即在处理交易时，不再强制在单一事务内完成资金和交易的处理，而是把它分解成两步，降低事务的原子级别，如果处理过程中发生异常，则通过反向交易进行账务回冲，从逻辑上保证业务处理的正确性。
弱一致性的引入，可以大幅提高系统的吞吐量，也可以降低单笔业务的延时。在恒生电子的UF2.0中，综合采用了客户分拆、弱一致性事务等机制，在券商中得到了广泛使用。但由于是数据库机制，交易延时仍然只能达到10ms这个量级。
弱一致性在带来好处的同时，也降低了系统的数据一致性，当系统发生局部故障时，就可能出现系统资金和证券数据的不一致，需要通过业务过程中的日志和流水进行状态恢复。
在供应商的推动下，券商从2009年开始全面部署第二代集中交易系统，随后证券市场开始出现了新的变化，包括：
- 交易量开始稳步上升，两市每天稳定在3000亿以上，随时有放大的趋势。
- 交易所开始推出各类创新的业务品种，包括创业板、融资融券、个股期权、沪深港通、固定收益产品扩容到地方政府债、公司债、企业债、ABS等。
- 证监会放开非现场开户后，客户争夺更加激烈，市场佣金持续下降。
- 业务合规性要求越来越高
新业务频繁推出，叠加券商间对客户资源的争夺日趋激烈，给集中交易系统带来了庞大的新增需求，供应商响应速度无法达到券商的业务需要，且频繁变更也给系统安全运行带来了巨大的挑战。行业内开始思考如何给集中交易系统进行架构优化。
第一个优化的方向是将账户系统进行剥离，从而为券商优化经纪业务运营体系提供可能性。按照这个思路，部分券商上线了独立的账户系统，将与营业网点相关的账户开立、资料录入、业务审核、合规报送等功能从集中交易完全剥离出来。
第二个优化的方向是将数据查询功能进行剥离，部署独立的数据中心系统，一方面可以减轻集中交易系统数据查询带来的压力，另一方面也可以进一步完善对客户的服务。
第三个优化是将理财产品销售功能进行剥离，部署专门用于处理产品销售的OTC系统，将原有开放式基金业务也纳入OTC系统统一处理。
第四个优化的方向是清算子系统，部分券商将清算职能从集中交易系统完全剥离出来，纳入统一的清算运营平台，更有甚者，将公司自营、资管等业务线的清算也统一考虑，形成了公司级的运营平台。
由于在如何给集中交易系统进行架构优化上，不同的券商有不同的思路，因此并没有形成行业统一的产品形态，以上提及的几个优化方向，券商会按自己的业务实际情况，有选择的进行实施。
瘦身后的集中交易系统功能更加纯粹，聚焦在高效稳定支持各种场内业务的交易、清算、合规管理等职能。但从交易功能上看，并没有改变围绕数据库进行业务处理的框架，可以看成是第二代集中交易系统的优化版。
在证券市场高速发展的同时，投资者结构也悄然发生了深刻变化，大量出现了以量化私募基金为代表的专业机构投资者，他们对交易系统的要求提升了一个量级，主要体现在：
- 使用计算机软件进行程序化交易。
- 对交易延时极为敏感，不同投资者之间存在速度竞争。
- 可能在较短时间内发出大量订单，对系统稳定性要求更高。
以数据库为中心的交易系统虽然经过了各种架构优化，但也只能将交易延时缩短到10ms左右的水平，离专业投资者的要求还有很大的差距。供应商开始推出全内存化的快速交易系统，专门服务少量的专业投资者。快速交易系统只有交易功能，其账户业务、资金划拨、清算均依托集中交易系统。所有业务全部在内存中完成处理，且每个客户的业务均采用串行化处理，确保数据的一致性（这一设计借鉴了期货交易系统）。
快速交易系统将交易延时提升了一个量级，达到了100微秒左右，有些供应商的系统甚至更快一些。但由于数据全部保存在内存中，损失了一定的高可用性，且由于业务串行化处理，吞吐量也受到了一定限制，因此单个节点的快速交易无法承载很多客户，券商会根据需要部署多套快速交易系统，有些甚至部署不同供应商的快速交易系统。券商交易系统进入了一种融合的架构模式，如下图所示：
这种融合架构的集中交易系统部署方案，已在大部分券商的生产系统得到实施。
