[转]vnpy乱乱谈 02架构

vnpy乱乱谈 02架构

转自：http://101.132.65.227/?p=51

听到架构这个词先不要害怕. 其实这部分内容还是挺简单的. 一般而言, 一个交易系统我们可以简单的分成输入, (系统)处理, 输出三个部分.

常见的输入就是交易所出来的行情(还有回报)了, 行情有很多其他叫法quote, tick, market data 反正都是差不多的意思.

而输出呢, 无非就是下单, 或者撤单, 或者查询.

整个处理流程是, 系统接收到一个quote, 然后系统内的模型会评估这个quote, 看看是否后面要下单, 或者撤单. 比如收到一个quote价格很便宜, 模型算出来这个quote价格被严重低估, 那么系统就会发出买入指令.好这里引入了一个新的东西叫模型, 或者叫策略. 所以现在架构看起来是这样的, 我们的交易系统里面有一个东西叫模型

更进一步, 是不是还缺点东西? 试想一下如果你的model不小心写错了, 会疯狂的下单, 那么会导致怎么样的后果? 或者是本来要买100手的变成10000手, 不用想都知道后果基本都挺严重的对吧. 所以我们需要一个东西来审查一下我们下的单子是否是正常的, 一般而言这个东西叫做风控, 对应的还有一个东西叫做流控.

风控一般是做安全检查的, 比方说检查你的单子价格是否正确, 是不是负数啊, 数量是否正确, 是否等于0或者是过大啊之类的. 而流控呢则是控制单位时间内可以下多少单子, 很多地方风控流控不做严格区分的, 讲风控一般也包含流控. 所以现在我们的交易系统变成了下面这样

试想一下, 如果不同的交易所的行情和交易指令有不同的格式, 那么如果我们的交易系统要支持多个交易所, 是不是还缺点什么? 一般来讲我们都比较喜欢把不同但是类似的东西统一来处理. 对行情来讲一般我们不直接处理交易所过来的原始数据, 而是做一下转化, 转化为我们内部的一种数据结构来处理, 这样多家不同的交易所的行情最终都是转化为我们自己的数据结构处理的. 而对交易来说, 则是我们内部的下单指令转化到各个交易所特有的指令. 这个转化的部件可以叫adapter也可以叫gateway. 所以我们的结构演变成下面这样了.

麻雀虽小五脏俱全, 现在基本上重要的东西都有了, 复杂一点的系统其实也就多拓展了一些内如, 下面是来自于AlgoTrader官方的架构图.

看着挺唬人但其实没多出来太多东西.

我们再来看看vnpy的, 大概是这样

EventEngine是整个事件引擎, 相当于AlgoTrader里面的Esper complex Event Processing Engine, 但要简单很多. 负责事件的分发处理.

gateway对外适配了CTP, FEMAS等金融接口, 对内转化为一致的数据结构.

DrEngine是行情数据记录引擎, 相当于AlgoTrader的Database部分, 主要做的事情:

1. 记录tick数据
2. 由tick数据生产并记录bar数据

CtaEngine模块是CTA策略引擎, 相当于algotrader的strategy模块.

RmEngine是风控引擎.

看起和AlgoTrader基本没差太多对吧? 但是呢仔细看一下, 还是有一些区别的, 在vnpy里面:

• 界面与逻辑耦合到一起
• IO(数据落地的mango db)和逻辑耦合到一起

这两点异同其实是会照成比较大的性能问题的. 这个问题留在后续的篇幅中继续.

本篇完.

参考:

SYSTEM ARCHITECTURE

The architecture of AlgoTrader is composed of the following components which is shown as the 1st figure

The AlgoTrader Server provides the infrastructure for all strategies running on top of it. The AlgoTrader Server holds the main Esper Complex Event Processing (CEP) engine. It is responsible for all domain model objects and their persistence in the database. Different market data adapters are available to process live and historical market data. On the other end adapters for different execution brokers and exchanges are available, which are responsible for placing orders and receiving executions.

The AlgoTrader Server also provides business components for back testing, parameter optimization, analysis, execution management, risk management, reporting, reconciliation and hedging.

On top of the AlgoTrader Server any number of strategies can be deployed. Strategies can either be coded purely in Java or in a combination of Java and Esper code. Esper based strategies make use of a dedicated Esper CEP engine. A strategy can deploy any number of SQL-like Esper statements for time-based market data analysis and signals generation. Esper statements can invoke any number of procedural actions, such as placing an order or closing a position, which are coded in Java. The combination of Esper statements and Java Code provides a best-of-both-worlds approach.

For management and monitoring of the system different GUI clients exist. The AlgoTrader HTML5 Frontend provides trading related functionality like charting, orders, positions & market data. Eclipse or IntelliJ IDE’s are used for strategy development. The EsperHQ client manages the Esper CEP engine.

For productive installations and deployment AlgoTrader uses Docker.

https://github.com/vnpy/vnpy