前言

  时至今日，WonderTrader曾经受到不少敌人的关注，笔者也感到十分荣幸。这样的关注从某种角度来说，也是对笔者的认可，哪怕是批评的声音，也是对笔者的鞭策。之前有一些敌人在研读 WonderTrader 代码的时候，遇到了一些问题，最次要的就是 不分明整个平台的架构设计，很多细节上了解不透 。所以这些敌人曾经三番五次跟笔者说，心愿笔者写个文章整体介绍一下平台的架构设计。
  其实笔者一开始不是很想写这样的文章。毕竟笔者自问还是下了很多功夫在代码里的，还是心愿识货的人多读读源码，而不是看一下架构文章就对WonderTrader 缄口结舌地指点江山。起初天人交战了一段时间，笔者恍然大悟：既然开源了，何必悭吝多写几篇文章，授人以鱼不如授人以渔。于是乎，就有了这个《WonderTrader架构详解》的系列文章。
  本文是该系列文章的第一篇，次要介绍 WonderTrader 的整体架构和策略实盘环境下的个别流程。

外围设计准则

  笔者之前有一篇文章，大抵介绍了一下 WonderTrader 的演变过程。而 WonderTrader 通过这么屡次的迭代和重构，有一套 外围的设计准则 贯通始终，这也是 WonderTrader 经验屡次迭代和重构，最终走向成熟而不是土崩瓦解的外围起因。

1、组件化准则

  在软件工程中，解耦是零碎设计的必修课程。耦合太重，各个模块之间的相互依赖太多，会导致代码逻辑简单难解，从而升高代码的可维护性。所以 咱们在设计简单零碎的时候，肯定要思考如何正当的解耦。合了解耦当前，失去的就是一个组件化的零碎。

  零碎组件化，有很多 益处：

• 便于团队合作，不同组件的开发能够同步进行，晋升开发效率
• 组件开发更灵便，只有合乎组件接口的范式，开发环境能够灵便应用
• 组件扩大更便捷，对接新的第三方时只须要增量更新，不影响其余组件

  然而零碎组件化，也有一些 前提：

• 各组件之间通过接口进行拜访，没有额定的依赖。所以接口设计的好坏，间接关系到组件化的成功率和成果。
• 组件化，须要在接口层面进行形象。而形象，则难以避免带来性能损失，如果在对性能有极致谋求的场景下，组件化肯定要审慎。
• 对于同一个接口，接口层的形象，会将合乎该接口的不同组件的差异化的点暗藏起来。如果零碎肯定要用到这些差异化的局部，可能会导致接口设计的复杂化。

  WonderTrader采纳的组件化设计，将独立的功能模块全副封装到独立的组件中，用接口连接起来。比拟典型的是不同的行情接入模块（Parsers）和不同的交易通道模块（Traders），因为每个模块都要对接各自对应的第三方API，所以采纳组件化设计，能无效的将各自不同的逻辑隔离开，让零碎只须要关注接口传递的数据即可。此外，执行单元（ExecuteUnit）、风控模块（RiskMonitor）、数据落地模块（DataWriter）和数据读入模块（DataReader）等，都遵循组件化设计的准则。

2、策略最简化准则

  策略最简化准则 ，从某种角度来说， 是一个哲学问题 。之所以这么说，是源自于笔者和一位用户的探讨，探讨次要围绕策略的信号接口是怎么实现的来开展的。大抵的观点就是这位敌人感觉策略须要确定以后信号到底是要开多、开空、平多或者平空，而笔者却认为策略只须要设置指标部位即可，不须要关注到底是要怎么下达交易指令。
  在上一次重构WonderTrader 的时候，笔者花了很长时间来思考一些问题，诸如：

• 策略关注的最外围的点是什么？
• 策略是不是肯定要晓得开平多空？
• 策略是不是肯定要晓得不同的接口回调过去的数据结构？
• 策略是不是肯定要自行治理订单？
• ……

  在经验了重复的思考当前，笔者没有得出任何答案。然而笔者也不是一个拖沓的人，既然没有答案，那么笔者就决定从减法做起。

• 策略只须要关注信号逻辑，不须要关注如何执行，所有都丢给底层
• 策略不须要晓得开平多空，只须要通知交易引擎本人的指标部位是什么，所有都丢给底层
• 策略不须要和任何接口打交道，只和数据打交道，其余的所有都丢给底层
• 策略不须要治理订单，所有都丢给底层
• ……

  减法做完当前，笔者也不再纠结这个问题，正如后面提到的，这是一个哲学问题，而大多数哲学问题，都没有答案。然而笔者置信 这样的减法，对于每个策略研发人员来说，都是十分敌对的。底层会帮忙策略把策略逻辑以外的任何事件都搞定，从数据管理到订单执行，包含多空开平，甚至平今对锁等等，底层都会全副搞定。

3、策略一致性准则

  策略的一致性准则，蕴含多个方面：

• 策略 代码的一致性，即回测和实盘用同样的代码
• 策略回测和实盘 信号的一致性，即实盘中触发的信号，在应用历史数据回测时该当是统一的
• 同一套策略，不同的交易通道中收回的 交易指令，该当是统一的

  策略代码的一致性比拟好了解，也比拟好实现，只有保障回测框架和实盘框架向策略提供的 API 是统一的，就能够保障策略能够 无缝在回测环境和实盘环境之间切换 。
  策略 信号的一致性，其实是对平台数据处理的一致性的要求 。只有实盘中实时处理的数据和历史数据完全一致，能力保障历史回测和实盘信号的一致性。因为实盘环境中，数据的达到有先后，如果解决数据保障策略响应的一致性，的确是比拟考验功夫的。笔者在WonderTrader 中花了很多精力，来 设计一种机制，能够尽可能的保障实盘数据的解决和历史回测数据的一致性，从而保障策略在实盘和回测中信号的一致性 。
  对于不同的交易通道中，信号和指令的一致性，这个就是WonderTrader 的外围机制之一，即 1+ N 的执行架构。1+ N 的执行架构，能够保障一个策略组合的信号在不同的交易通道中都可能统一，从而使得不同的交易通道的策略绩效相差无几。对于1+ N 执行架构 的具体介绍，笔者会在后续的文章中做具体的论述，这里临时就不开展了。

外围架构介绍

  后面提到的设计准则，绝对比拟形象。上面笔者将联合示意图，别离介绍 WonderTrader 的回测框架 、 实盘框架 以及 策略在实盘中的根本流程。读者能够从上面的架构设计中和后面提到的设计准则相互参考，应该能够失去一些印证。

1、回测框架

  上图是 WonderTrader 回测框架的架构图。从上图咱们能够看进去，回测框架还是比拟简洁的。整个回测框架的 外围在于 4 个仿真器和一个历史数据回放器 。而 4 个仿真器，别离对应 3 种不同类型的策略，以及执行单元。
  而策略局部，除了C++ 策略能够间接和回测引擎交互 以外，多语言策略（当初只实现了 python）则须要通过 C 接口的粘合层跟回测引擎进行交互，同时还须要提供一个多语言子框架提供多语言环境下的 API 和底层交互接口（python 下为 wtpy）。
  执行单元，是实盘中执行器的外围逻辑模块，用于执行交易指令和治理订单的。因为执行单元只能 C++ 开发，所以不再提供 C 接口粘合层。Exec仿真器，则 通过定时设置指标仓位，触发执行单元的外围逻辑，并对执行单元收回的交易指令进行模仿撮合，从而达到回测执行单元，剖析执行逻辑的体现的目标 。
  历史数据回放器，通过 从数据引擎加载历史数据，并依据历史数据按数据周期进行回放，触发策略的重算，从而驱动策略逻辑，并在仿真器 Mocker 中进行仿真撮合，进而达到回测的目标 。从上图能够看出，历史数据回放器，能够从WT 数据文件系统、CSV 文件 以及 数据库（目前只对接了Mysql）加载历史数据。

2、实盘框架

  WonderTrader实盘框架相比回测框架就要简单很多。除了策略实现和回测框架是统一的（前文提到的策略一致性准则），底层外围为了对接实盘中不同的功能模块，所以就有了很大的不同。
  策略引擎，也是一个策略组合 ，接管到数据组件播送的实时数据当前，触发策略重算，从而生成信号，并经由策略引擎轧平汇总当前，丢给执行器执行，而执行器调用不同的执行单元的执行逻辑当前，最终通过Trades 交易通道模块，向交易柜台下达交易指令，从而实现一轮信号的生产执行的循环。目前策略引擎针对不同类型的策略实现上有一些区别，所以分成了 3 种策略引擎。
  须要留神的是，数据组件其实是作为一个 独立的伺服 在运行的。目标也比拟明确，就是要实现 读写拆散，并且能够同时向多个组合盘实例提供数据服务 。数据组件通过调用DataWriter 模块接口进行数据的落地，数据存储反对 WT 文件系统 以及 数据库 两种模式。而策略则通过策略引擎调用数据管理器，通过 DataReader 从数据存储中读取文件到内存中，失去数据管理器中返回的数据切片。
  还有一个绝对独立的模块，就是风控模块 RiskMonitor。风控模块次要 针对组合盘（策略引擎）的虚构资金进行风控 ，目前内置的风控模块反对的指标次要包含 最大日内回撤 、 最大多日回撤 等危险指标进行管制。

3、策略根本流程

  上图是 WonderTrader 中 CTA 策略在实盘环境中的根本流程。

• 首先 Parser 从行情源接入行情数据，并解析成 WonderTrader 本人的 tick 数据
• tick数据先传递给CTATicker（数据同步器）进行工夫戳的同步控制
• 每一笔 tick，都会触发策略的on_tick 回调
• 当 tick 数据的工夫戳确定了上一个分钟的完结，就会判断是否有 K 线 刚好闭合
• 如果 K 线 曾经闭合，则触发策略的 on_bar 回调
• 如果策略订阅的全副 K 线 都闭合了，则触发策略的 on_schedule 回调进行重算
• 策略重算过程中，调整了指标仓位，最终汇总到策略引擎中进行汇总解决
• 头寸汇总当前，分发给各个执行器进行执行
• 执行器调用底层执行单元的逻辑收回下单指令
• 最初下单指令通过交易通道 Traders 最终下达交易柜台

  WonderTrader一共有三种不同的策略引擎，以用于不同利用场景的策略。除了 HFT 策略，策略间接对接交易通道 Trader 以外，另外两种策略的根本流程都和下面介绍的 CTA 根本流程是统一的。

结束语

  因为篇幅无限，本文的介绍就到此结束了。置信通过本文的介绍，各位读者对于 WonderTrader 的整体架构曾经有了一个初步的认知了。如果有读者违心更进一步的理解 WonderTrader，心愿这篇文章能够帮忙到各位。下一周，笔者将围绕数据处理，来介绍WonderTrader 的数据处理机制，望各位读者届时多多捧场。

  WonderTrader旨在给各位量化从业人员提供更好的轮子，将技术相干的货色都封装在平台中，力求给策略研发带来更好的策略开发体验。

最初再安利一下WonderTrader

WonderTrader的 github 地址：https://github.com/wondertrad…

WonderTrader官网地址：https://wondertrader.github.io

wtpy的 github 地址：https://github.com/wondertrad…

市场有危险，投资需谨慎。以上陈说仅作为对于历史事件的回顾，不代表对将来的观点，同时不作为任何投资倡议。