WonderTrader架构详解之一——总体架构

前言

  时至今日，WonderTrader已经受到很多朋友的关注，笔者也感到很是荣幸。这样的关注从某种角度来讲，也是对笔者的承认，哪怕是批评的声音，也是对笔者的鞭策。以前有一些朋友在研读WonderTrader代码的时候，遇到了一些问题，最主要的就是不清楚整个平台的架构设计，不少细节上理解不透。因此这些朋友已经三番五次跟笔者说，但愿笔者写个文章总体介绍一下平台的架构设计。
  其实笔者一开始不是很想写这样的文章。毕竟笔者自问仍是下了不少功夫在代码里的，仍是但愿识货的人多读读源码，而不是看一下架构文章就对WonderTrader滔滔不绝地指点江山。后来天人交战了一段时间，笔者豁然开朗：既然开源了，何须吝啬多写几篇文章，授人以鱼不如授人以渔。因而乎，就有了这个《WonderTrader架构详解》的系列文章。
  本文是该系列文章的第一篇，主要介绍WonderTrader的总体架构和策略实盘环境下的通常流程。

核心设计原则

  笔者以前有一篇文章，大体介绍了一下WonderTrader的演变过程。而WonderTrader通过这么屡次的迭代和重构，有一套核心的设计原则贯穿始终，这也是WonderTrader经历屡次迭代和重构，最终走向成熟而不是分崩离析的核心缘由。

一、组件化原则

  在软件工程中，解耦是系统设计的必修课程。耦合过重，各个模块之间的互相依赖太多，会致使代码逻辑复杂难解，从而下降代码的可维护性。因此咱们在设计复杂系统的时候，必定要考虑如何合理的解耦。合理解耦之后，获得的就是一个组件化的系统。

  系统组件化，有不少好处：

• 便于团队协做，不一样组件的开发能够同步进行，提高开发效率
• 组件开发更灵活，只要符合组件接口的范式，开发环境能够灵活使用
• 组件扩展更便捷，对接新的第三方时只须要增量更新，不影响其余组件

  可是系统组件化，也有一些前提：

• 各组件之间经过接口进行访问，没有额外的依赖。因此接口设计的好坏，直接关系到组件化的成功率和效果。
• 组件化，须要在接口层面进行抽象。而抽象，则难以免带来性能损失，若是在对性能有极致追求的场景下，组件化必定要谨慎。
• 对于同一个接口，接口层的抽象，会将符合该接口的不一样组件的差别化的点隐藏起来。若是系统必定要用到这些差别化的部分，可能会致使接口设计的复杂化。

  WonderTrader采用的组件化设计，将独立的功能模块所有封装到独立的组件中，用接口链接起来。比较典型的是不一样的行情接入模块（Parsers）和不一样的交易通道模块（Traders），由于每一个模块都要对接各自对应的第三方API，因此采用组件化设计，能有效的将各自不一样的逻辑隔离开，让系统只须要关注接口传递的数据便可。此外，执行单元（ExecuteUnit）、风控模块（RiskMonitor）、数据落地模块（DataWriter）和数据读入模块（DataReader）等，都遵循组件化设计的原则。

二、策略最简化原则

  策略最简化原则，从某种角度来讲，是一个哲学问题。之因此这么说，是源自于笔者和一位用户的讨论，讨论主要围绕策略的信号接口是怎么实现的来展开的。大体的观点就是这位朋友以为策略须要肯定当前信号究竟是要开多、开空、平多或者平空，而笔者却认为策略只须要设置目标部位便可，不须要关注究竟是要怎么下达交易指令。
  在上一次重构WonderTrader的时候，笔者花了很长时间来思考一些问题，诸如：

• 策略关注的最核心的点是什么？
• 策略是否是必定要知道开平多空？
• 策略是否是必定要知道不一样的接口回调过来的数据结构？
• 策略是否是必定要自行管理订单？
• ……

  在经历了反复的思考之后，笔者没有得出任何答案。可是笔者也不是一个拖沓的人，既然没有答案，那么笔者就决定从减法作起。

• 策略只须要关注信号逻辑，不须要关注如何执行，一切都丢给底层
• 策略不须要知道开平多空，只须要告诉交易引擎本身的目标部位是什么，一切都丢给底层
• 策略不须要和任何接口打交道，只和数据打交道，其余的一切都丢给底层
• 策略不须要管理订单，一切都丢给底层
• ……

  减法作完之后，笔者也再也不纠结这个问题，正如前面提到的，这是一个哲学问题，而大多数哲学问题，都没有答案。可是笔者相信这样的减法，对于每一个策略研发人员来讲，都是很是友好的。底层会帮助策略把策略逻辑之外的任何事情都搞定，从数据管理到订单执行，包括多空开平，甚至平今对锁等等，底层都会所有搞定。

三、策略一致性原则

  策略的一致性原则，包含多个方面：

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

  策略代码的一致性比较好理解，也比较好实现，只要保证回测框架和实盘框架向策略提供的API是一致的，就能够保证策略能够无缝在回测环境和实盘环境之间切换。
  策略信号的一致性，实际上是对平台数据处理的一致性的要求。只有实盘中实时处理的数据和历史数据彻底一致，才能保证历史回测和实盘信号的一致性。由于实盘环境中，数据的到达有前后，若是处理数据保证策略响应的一致性，确实是比较考验功夫的。笔者在WonderTrader中花了不少精力，来设计一种机制，能够尽量的保证明盘数据的处理和历史回测数据的一致性，从而保证策略在实盘和回测中信号的一致性。
  关于不一样的交易通道中，信号和指令的一致性，这个就是WonderTrader的核心机制之一，即1+N的执行架构。1+N的执行架构，能够保证一个策略组合的信号在不一样的交易通道中都可以一致，从而使得不一样的交易通道的策略绩效相差无几。关于1+N执行架构的详细介绍，笔者会在后续的文章中作详细的阐述，这里暂时就不展开了。

核心架构介绍

  前面提到的设计原则，相对比较抽象。下面笔者将结合示意图，分别介绍WonderTrader的回测框架、实盘框架以及策略在实盘中的基本流程。读者能够从下面的架构设计中和前面提到的设计原则互相参考，应该能够获得一些印证。

一、回测框架

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

二、实盘框架

  WonderTrader实盘框架相比回测框架就要复杂不少。除了策略实现和回测框架是一致的（前文提到的策略一致性原则），底层核心为了对接实盘中不一样的功能模块，因此就有了很大的不一样。
  策略引擎，也是一个策略组合，接收到数据组件广播的实时数据之后，触发策略重算，从而生成信号，并经由策略引擎轧平汇总之后，丢给执行器执行，而执行器调用不一样的执行单元的执行逻辑之后，最终经过Trades交易通道模块，向交易柜台下达交易指令，从而完成一轮信号的生产执行的循环。目前策略引擎针对不一样类型的策略实现上有一些区别，因此分红了3种策略引擎。
  须要注意的是，数据组件实际上是做为一个独立的伺服在运行的。目的也比较明确，就是要实现读写分离，而且能够同时向多个组合盘实例提供数据服务。数据组件经过调用DataWriter模块接口进行数据的落地，数据存储支持WT文件系统以及数据库两种模式。而策略则经过策略引擎调用数据管理器，经过DataReader从数据存储中读取文件到内存中，获得数据管理器中返回的数据切片。
  还有一个相对独立的模块，就是风控模块RiskMonitor。风控模块主要针对组合盘（策略引擎）的虚拟资金进行风控，目前内置的风控模块支持的指标主要包括最大日内回撤、最大多日回撤等风险指标进行控制。

三、策略基本流程

  上图是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...

---

市场有风险，投资需谨慎。以上陈述仅做为对于历史事件的回顾，不表明对将来的观点，同时不做为任何投资建议。