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...

---

市場有風險，投資需謹慎。以上陳述僅做爲對於歷史事件的回顧，不表明對將來的觀點，同時不做爲任何投資建議。