共计 4879 个字符，预计需要花费 13 分钟才能阅读完成。
前言
《WonderTrader架构详解》系列文章，上周介绍了 WonderTrader 的数据处理机制。当平台解决了策略的数据问题当前，就须要向策略提供稳固牢靠的信号执行机制，保障策略的信号被正确的执行，是每一个平台最根本的性能。因而，本文作为系列文章的第三篇，将次要介绍WonderTrader 信号执行的解决机制。
往期文章列表：
- WonderTrader 架构详解之一——整体架构
- WonderTrader 架构详解之二——从数据说起
1+ N 执行架构
WonderTrader 设计了一种执行架构，该执行架构能够 将一个策略组合的信号，散发到若干个执行通道执行，咱们称之为1+ N 执行架构。为什么会把信号执行设计成这样呢？
- 基于策略最简化的根本准则
对于策略来说，最外围的工作是抓住赚钱的因子。然而交易的过程中，会波及到行情的接入和订单回报的解决。市面上有不少平台，抉择间接将这样的回报裸露给策略。在这类平台上，策略除了外围逻辑以外，还须要写很多反复的订单治理逻辑。有些平台甚至将底层接口的数据结构间接裸露给策略，这样做的后果是给策略引入了更多的复杂度，除了治理回报，还须要对不同的接口做数据的兼容解决。
WonderTrader的一个设计指标就是是要给策略研发人员做减法，让他们将更多的精力放到策略自身，而不是如何和接口打交道。1+ N 执行架构 ，也正是基于这条根本准则。因为 信号和执行彻底剥离 ，所以策略不须要关注任何回报，因为底层会将执行这块解决得很好，策略只须要关注本人的指标头寸和进出场的价格即可。这样就 大大简化了策略的编写 ，只须要 将信号计算的外围逻辑实现好 就能够了。
- 大规模产品治理的理论需要
当咱们只有一个策略时，最简略的形式，就是把策略写成一个小型的平台，本人解决行情回报和交易回报，再针对特定的需要做一些性能扩大即可。而这种做法，容易把平台做成一个“玩具”，不具备治理大规模产品的根底，有很多量化交易框架都相似这种。
对于大规模的产品治理，最根本的需要就是 多个策略造成一个组合独特交易，而一个策略组合又同时在多个产品进行交易 。而不同资金规模的产品，在收回交易指令的时候，所须要的执行算法也是不一样的。比方 买入 100 手和买入 1 手某期货合约，显然就不能用齐全一样的形式下单 。
1+ N 执行架构 很重要的一方面就是 针对大规模产品治理的需要 。雷同的策略组合，在 不同的交易通道 下，会依据产品的资金规模和危险偏好 配置不同的交易数量放大倍数 。而交易数量的不同，有须要针对不同的交易通道 配置不同的执行算法 ，这样能力让各个产品都能 取得更好的执行价格。
- 策略逻辑和执行的重复衡量
1+ N 执行架构 下，须要把策略分为两类策略：重逻辑轻操作的策略 和轻逻辑重操作的策略 。 大多数趋势类策略都属于前者，而简直所有的高频策略都属于后者 。
重逻辑轻操作的策略 ，最显著的特点就是 信号呈现时必须要执行到位 。这类策略，还体现出频率较低（绝对高频而言）， 对滑点敏感度低 等特点。而这类策略就是 1+ N 执行架构 次要服务的策略，这类策略也很容易通过 1+ N 执行架构 扩大到更多的交易通道。
绝对的，轻逻辑重操作的策略 ，最显著的特点就是 信号呈现时，要看执行的状况，能力决定下一步如何应答 。这类策略最常见的就是 套利策略 和高频策略 ，它们须要 不停地挂单试探盘口的状况，能力做出更无利的决策 。显然1+ N 执行架构 无奈满足这类策略，所以 WonderTrader 专门针对这类策略提供了 HFT 引擎，该引擎将交易接口和交易 回报间接裸露给策略，这样策略就能依据回报执行治理订单。
- 投研人员的编码程度的考量
在量化畛域中，对从业人员的成分划分，有一个很乏味的分类办法：P-Quant和 Q-Quant。P-Quant 的独特属性是这些从业人员根本都有软件开发的 技术背景 ，领有绝对 较好的编码能力 。而Q-Quant 则相同，个别 没有技术背景，编码能力绝对较弱 ，然而在 策略建模、金融工程方面绝对较强 。
因为两类从业人员的背景和能力树的不同，所以他们对于平台的需要也不大一样。P-Quant编码能力绝对较强，偏向于 平台提供外围的根底性能 即可，他们能够 自行开发本人须要的各种性能 ，同时心愿 平台可能尽可能低延时 （P-Quant 从事高频策略开发的比例更高）；Q-quant 编码能力绝对较弱，则偏向于 平台提供更欠缺的基础设施和策略开发 API，绝对的，他们 对延时不那么敏感 （当然如果平台可能做到更低延时，对他们同样无利），然而心愿 平台反对的利用场景更丰盛一些（要满足不同类型的策略的回测、实盘等需要）。
鉴于以上提到的几个方面，WonderTrader最终决定针对 CTA 策略，基于信号和执行的剥离，采纳 1 + N 执行架构进行实盘交易。而针对HFT 策略，则抉择将交易接口间接裸露给策略（不同交易接口的差别被封装到交易模块中，策略解决的交易接口是无差别的），让策略自行治理订单，转而在数据需要上提供反对。这样就能兼顾不同类型的策略的不同的利用场景，让不同类型的策略都能在WonderTrader 中能够更高效的治理起来。
如何同步信号
对于 CTA 引擎，既然采纳 1+ N 执行架构，就意味着 平台须要治理两套头寸 ，一套是策略的 实践头寸 ，一套是交易通道的 理论头寸。在实盘运行中，咱们须要对两套头寸别离进行治理。
- 实践头寸的治理
实践头寸 的治理，也分为两个层面。第一个是 策略层面 ，即 每个策略有本人的实践头寸 ，包含进出场的工夫、价格、方向、数量等。策略能够治理的也只能是本人的实践部位， 每个策略都是相互隔离的 。持有的头寸，再实时计算浮动盈亏，并核算最大潜在浮盈和最大潜在浮亏等数据。 回测的时候 ，数据都在内存中， 不须要实时保留 。而 实盘环境 下，要思考策略重启等各种状况，所以数据须要 实时保留到文件中 。
第二个是 组合层面 ，即策略的指标头寸整合到一起当前，造成一个 净头寸 。这个净头寸实质上和策略的实践头寸是统一的，只不过是轧平过相同的头寸当前， 归属于策略组合治理 。策略组合也要实时计算浮动盈亏，同时依据预设的资金规模，计算资金危险指标，进行实时风控。 实盘环境下，数据也要实时保留到文件中（回测引擎针对单策略，所以不存在策略组合的概念）。
- 理论头寸的解决
策略组合的头寸是最终散发到各个交易通道的 根底指标头寸 。每个交易通道，会依据所对应产品的资金规模和危险需要别离配置本人的放大倍数，根底为 1 倍，反对小数倍数，会主动做四舍五入的解决。
每个执行通道确定了本人的 理论指标头寸 当前，跟本人以后 理论持有的头寸 进行比拟，将有 差异的头寸 ，依据预设的 执行算法 （WonderTrader 内置的是以最新价、最优价和对手价三个价格作为 根底价格，再加上一个滑价跳数 作为限价，基本上满足了绝大部分资金规模无限的策略需要）收回下单指令。并依据 订单回报 和成交回报实 时更新 持仓状态 和订单状态。
- 滑点如何解决
正如后面所说，不同资金规模的策略，最终成交的价格是不同的 ，更何况不同的交易通道还是依赖雷同的信号进行交易的，并发执行的前提下，不同交易通道的订单最终也会在交易所进行竞争。这就造成一个主观的事实： 雷同策略在不同产品中的实盘体现肯定是有差别的，而差别的起源就是滑点 。
回测 的时候，咱们个别用小手数进行回测，所以个别状况下都 不思考滑点 。然而 实盘环境下，滑点问题就不可避免 。这也是咱们内置的执行算法，都是以限价单下单的根本原因。个别状况下，笔者倡议 放大倍数大的交易通道 ，执行算法中 预设的滑价 能够绝对放大倍数小的交易通道 设置得更大一些（最终要依据流动性判断）。这样即便产生滑点，也在能够承受的范畴之内。如果应用市价单收回下单指令，极其行情下，最终产生的滑点可能会压缩掉全副的利润。
1+ N 执行架构的意义
后面根本介绍了 1+ N 执行架构 基本原理。从 WonderTrader 的角度来说，所谓的 1+N 其实也有两层意思： N 个策略在 1 个组合中独特运行，而 1 个组合又同时在 N 个交易通道进行交易 。所以一开始的时候笔者无意称之为N+1+ N 执行架构。显然，不论从哪方面来说，1+ N 执行架构 的意义是不凡的：
- 策略和执行剥离，对研发人员更敌对，团队治理更高效
投研人员的技术栈其实是策略
coding的外围问题，咱们抉择一个平台的时候，应该 尽量的缩小技术栈的引入 。而个别交易接口都是异步回调的，如果强行要策略投研人员深刻理解这类纯技术技能，从团队治理的角度来说，是低效的。同时对于投研人员来说，花太多的精力到本身技能树的分支上，也不是一个聪慧的抉择，更何况技术自身也并不那么容易。
所以 策略和执行的剥离 ，对大部分投研人员，尤其是Q-Quants 来说，是一种十分敌对的设计。这样的设计当然也不是 WonderTrader 独创的，笔者也从共事的理论需要中和其余的量化平台排汇了一些教训。
- 净头寸执行，不存在自成交危险
对于策略来说，风控是必不可少的 ，同样策略组合的风控也是平台的重点之一。风控中，除了 资金风控 以外，还有一个 合规风控 。绩效回撤了，能够再赚，然而如果合规风控过线了，可能会引起十分大的麻烦。其中最重要的合规风控点就是自成交。 自成交次数过多，手数过大，很容易被认定为对敲操控市场，相应的处罚也是十分严格的 。
WonderTrader 须要解决多策略在多产品经营的问题，首要思考的就是合规性的问题 。如果两个策略同时收回相同的交易信号，并且散发到多个产品同时下单，自成交的危险就会被放大。所以WonderTrader 通过在策略组合中 轧平相同头寸 ，最终以 净头寸的形式收回下单指令 。除了人造防止自成交的问题，同时还能 节俭佣金 、 缩小保证金 的占用。策略组合外部，策略有本人的实践头寸，不受组合头寸的影响。
- 同一个策略组合的多产品，能够保障信号的一致性
笔者此前，常常会被投资人问：你们怎么保障各个产品绩效的一致性的？笔者没有太多去钻研别家是怎么解决的，然而对于 WonderTrader 的1+ N 执行架构 来说，这样的问题就显得太简略了。
即便两个规模一样的产品，用同一套策略交易，绩效也不可能齐全一样。因为即便同时下单，也受到交易通道速度的影响。然而不能保障绩效的齐全一致性，保障信号的齐全一致性却是没有问题的。
- 满足大规模治理产品的需要
业余投资机构对于交易平台的需要，和集体投资者还是有很大差异的。最外围的一点就是 大规模的产品如何治理 的问题。例如某些头部私募，发了数百只产品，假如只有一百只产品须要实际操作，而每只产品都须要交易股票、期货、期权等标的。
如果不从架构上解决这样的需要，对于这些机构的IT来说，这基本上是一个劫难：在不同的服务器上部署策略运行环境，每天还要监控各台服务器在收盘前是否失常运行。甚至有些柜台要到收盘前才会启动，这就使得运维人员的查看工夫窗口只能限定在半个小时甚至更短的工夫范畴内。
WonderTrader的需要就从大规模产品治理中来，一开始的设计指标也是要满足大规模产品治理的需要。而 1+ N 执行架构 正是针对这样的需要的外围机制。
结束语
本文对 WonderTrader 的信号执行机制的介绍就到此结束了，置信通过本文，各位读者可能对 WonderTrader 的1+ N 执行架构 有一个更深刻的理解，也心愿本文可能在各位读者在遇到相似问题的的时候，对大家有所启发。笔者程度无限，不免有错漏之处，还请各位朋友多多包涵斧正。下一篇，笔者将围绕平台如何兼容不同的策略，来介绍 WonderTrader 不同的策略引擎的底层逻辑，望各位读者届时多多捧场。
最初再安利一下 WonderTrader
WonderTrader 旨在给各位量化从业人员提供更好的轮子，将技术相干的货色都封装在平台中，力求给策略研发带来更好的策略开发体验。
WonderTrader的 github 地址：https://github.com/wondertrad…
WonderTrader官网地址：https://wondertrader.github.io
wtpy的 github 地址：https://github.com/wondertrad…
市场有危险，投资需谨慎。以上陈说仅作为对于历史事件的回顾，不代表对将来的观点，同时不作为任何投资倡议。
