0 前言
在前几篇中，我们提到一个量化交易系统应该分成四部分，并给出了第一步市场分析平台的设计方案，这里小木再浅浅探讨下关于第四步实盘交易平台的设计。
过去几个月一直没有认真研究策略，这篇文章也是近期最后一次谈论量化交易系统，照例先给出整体架构，再对细节进行阐述并陈列开发工具选择。
1 整体架构
实盘交易功能搭建起来实则不难，在现在代码开源的环境下，有许多前辈已经将各标的柜台交易接口进行了二次封装，减轻了后来人的开发压力。
然而对于交易平台而言，这不仅要求个人能够准确列出自己的各种需求，同时还需要在保证整个功能流程不出现缺陷的前提上，分别找到合适的工具进行功能搭建。
小木认为一个合格的实盘交易平台，它除了保证最基本的实盘交易功能之外，它的策略代码应该还可以无缝连接策略回测引擎，从而实现策略代码回测实盘一体化。
具体如下图所示：
图一：回测实盘一体化框架
策略研究平台会使用回测引擎对策略的历史表现进行评估，而实盘交易平台通过实时接收行情数据来驱动实盘引擎进行买卖订单发送，在合格的平台设计中，二者应该尽量使用同一份策略代码，以避免代码迁移过程中产生的风险与时间成本。
这要求设计者在实盘交易平台设计时，同时还需要对策略回测功能流程具有充分的掌握，保证两个平台迁移顺利进行。或者换言之，将针对策略进行回测的组件无缝切换到实盘交易。
合格的实盘交易平台除了回测实盘一体化，还应该具备行情接入、数据验证、行情聚合、日志采集、容灾备份、监控界面、邮件通知等辅助功能。
数据验证主要是保证数据的完整性以使策略代码顺利生成交易信号；监控界面除了得到实盘策略的跟踪报告外，还需要提供人工介入接口，保证策略可以及时更换运行状态。
2 细节阐述
上述是从宏观角度来阐述实盘交易平台的功能性组成，但正如魔鬼在细节里的谚语，如果转化为编程实现，实则存在诸多需要进行考虑的地方。
回测框架主流的设计思路主要分成向量式和事件式（也有基于图结构的），前者将策略在历史数据的表现计算拆解成矩阵计算，实现更高效率的回测速度，后者通过依次遍历每一条行情数据，每次交易均需要最新的数据到来作为契机来进行判断。
如果我们考虑回测实盘一体化，那么回测引擎的选择范围只能缩小至事件式方案。同时，区别于回测平台，实盘平台除了需要具有实盘引擎，还要考虑实时数据的及时处理与接入。
一般而言，我们都会采取数据驱动的方法，即每个都有自己的堆栈，只有新的数据被推送至堆栈，组件才会启动执行。这种方法会更加直观，但是如果在有效时间内无法及时处理所有的数据，这将产生阻塞滞后问题。
同时，对于实盘交易平台，除了实盘引擎，还需要考虑行情接入的相关事宜，例如标的类型的选择，设计者是想做股票债券，还是期货期权，甚至是数字货币。为了让后续开发变得轻便，不仅要将这些柜台的连接进行整合。
3 工具选择
正如上文所述，实盘交易功能搭建本身并不足够复杂，难点是围绕它而逐渐建立起来的整个平台设计、功能具体实现和异常情况处理。这节就功能具体实现所需要的工具包进行简单选择。
各标的行情柜台：qmt、ctpbee、ccxt 数据验证与配置：pydantic、hydra 回测与实盘引擎：backtrader 日志采集与监控：loguru、fastapi、plotly
在交易的标的选择上，小木选取的是最常见的股票、期货和数字货币三种标的，为了对接它们的行情与柜台，需要使用的工具包分别是 qmt、ctpbee 和 ccxt。
在接入行情后，选用 pydantic 来进行数据的格式验证工作，它是目前为止执行效率最快的 python 工具包，而完成配置登记，这里选择 hydra 进行实现，它可以轻松地管理复杂的配置。
在回测与实盘引擎中，小木选取的是基于事件驱动的交易框架 backtrader，它天然就实现回测实盘一体化，同时可以很轻便地进行功能拓展，非常适合二次开发。
最后，为了验证系统处于健康的运行状态，我们需要进行日志采集并实时监控，这里使用的是诸多大厂使用的 loguru 和更高性能的网站开发框架 fastapi，并搭配 plotly 工具包来完成金融相关图形的可视化。
对于交易系统搭建感兴趣的朋友们，也可以看看下面小木学习的相关笔记：
