独家 | 搭建入门级高频交易系统（架构细节分享）

前言

在过去的几个月里，我们花费了很多时间构建属于自己的入门级高频交易系统。由于我们将学习机器学习应用金融领域已经很长一段时间了，并试图弄清楚其在现实世界中是如何工作的。互联网上的资源并不多。我们希望告诉你，如果你尝试类似的事情，可能会遇到一些坑。我们将努力用通俗的语言为你讲述深入的问题，希望你能喜欢。

问题开始

1、高频交易系统的基本原理是什么?

要建立搭建一个高频交易系统，你必须假设“存在低效率市场”的假设是正确的。因为每个人都在同一时间关注市场，所以会有一群人找出这些低效率（例如使用统计数据），并试图弥补它们。这意味着，等待的时间越长，在纠正这种低效率之前发现它的概率就越低。在不同的时间窗口上存在不同类型的低效率，你所看到的时间框架越小，效率就越低，面临的竞争就更多。

2、为什么要搭建加密货币高频交易系统?

在我看来，标准资产市场相当糟糕。为什么？如果你试图作为一个单一获取市场数据你会发现是很困难的（没有人会免费给你，如果他们这样做，我可以向你保证，你将比你更好的人竞争）。大多数加密货币的货币交换“借用”了已经为标准资产市场构建的基础设施，它们的FIX API的结构与标准资产市场上的结构完全相同。此外，由于在加密货币交换中存在许多竞争，你将发现您必须为交易这些工具支付的佣金比常规市场上的竞争要激烈得多。例如，你可以找到经纪人，他们会因为你为市场带来流动性而付给你钱。

为什么你需要原始访问市场？这用机器学习的座右铭来回答这个问题：

垃圾进，垃圾出

此外，如果你想进行任何类型的量化分析，你必须控制系统上的一切，也就是：你希望在使用的数据聚合平台上完成所有的分析。当你建立一个机器学习模型时你假设他们的预测在一组边界条件下是有效的，你越违反这些条件你的预测就越无效。因此，你拥有的最佳选择是让代理尽可能快地向你发送每笔交易（或订单更改）。

架构概述

我之后会解释为什么高频交易系统必须对故障具有巨大的容错度。当发现这一点时，我们采用了微服务架构，因为对我们来说，这是确保多组件系统具有容错性和可扩展性的最佳方法。可以向你保证，当你进行实时交易时，你的系统将出现无法预料的错误，其中一些错误与第三方相关，例如对代理的分布式拒绝服务（DDOS）攻击等。当使用微服务架构时，当服务失败时，调度程序会尝试立即重新启动服务，这是一个非常优雅的解决方案，当你尝试单独构建此类系统时。

小贴士：

分布式拒绝服务（DDoS：Distributed Denial of Service）攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。通常，攻击者使用一个偷窃帐号将DDoS主控程序安装在一个计算机上，在一个设定的时间主控程序将与大量代理程序通讯，代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术，主控程序能在几秒钟内激活成百上千次代理程序的运行。

组件简介：

数据库：高密度的时间序列数据库，需要能够处理每天数十万的数据写入（提示：选择一个物联网数据库marvels)。还需要具有可扩展性，以便能够以不可变的分布式方式执行非常高速的重新采样。

Scrapper：将新的流数据写入数据库。

量化模型：当Alpha出现时发出信号的量化模型。

订单执行器：接收量化模型的信号，与市场进行互动。有时市场流动性不强，或者你的策略必须满足某些类型的滑点要求。因此，为了使您的系统不可变，最好有一个微系统试图以最好的方式执行你的头寸，这可以让你节省佣金。例如：不使用市场订单，而尽可能去执行限价订单，这需要一些时间的消耗和根据市场流动性随时的调整。

量化分析：你必须开发一套工具来建立模型。由于这些数据来自你的基础架构，因此你有更好的方法来确保系统的边界条件。例如，你不能保证在高波动性的市场条件下你能完全进入市场，因此，通过建立基础架构，你可以准确地衡量发生了什么，什么时候发生，并记录下来。

为什么要采用这样的微服务架构？有时你的Scrapper会因为代理中断而失败（在高度不稳定的情况下，会有恶意的代理启动DDOS，使其他人更难进入市场）。我们推断这是一种DDOS攻击，但更准确地说，我们称之为代理不可用。这是市场有效时的情况：

具有良好利差的有效市场

由于broker不可用，市场效率非常低（注意下一幅图中的y轴刻度更大）：

你可以在最后一幅图中看到，在一个小的时间窗口中有巨大的开口。这是因为broker不可用。由于算法无法定期下限价单，从而给市场带来稳定和流动性，因此给出了一些较高的市场订单（无论市场条件如何，这些订单都是可以接受的，但不能保证你会得到什么价格），通过消耗现有的限价单来扩大价差。

更详细的架构概述

我们将尝试对这个系统做一个更详细的概述，并解释一些设计选择。我们建议开发服务的应用程序是Docker。Docker提供了非常好的管理工具，如果你想使用类似于Kubernetes的集群，那么Docker可以让你更轻松地进行部署。

REST API scrapper服务：该服务具有一个缓冲区，用于缓冲订单簿的Websocket API通过流提供最近的市场事务、报价和订单。它有多个worker的原因是为了减少broker基础设施的中断（如果broker服务器开始出现阻塞，这种情况发生在很长一段时间，那么有多个冗余的worker会增加你获得所有消息的机会)。例如，代理服务器可能会开始删除一些连接以保持其工作负载的运行，如果有更多的worker，那么在已经删除的worker重新启动时，至少保留一个连接的可能性更高。你还可以在多个IP中运行多个服务，这将带来更多的冗余。

Scrapper服务：Scrapper服务收集发布在REST API上的信息，并将其写入数据库。它能够跳过多个REST服务，如果检测到错误的行为，就触发其重启。

订单执行服务：通过执行市场订单或限价订单，从数据库的表中获取执行操作的信号并启动其执行。它还具有跳过多个REST服务的能力。

量化算法服务：有模型实现，利用数据库收集的数据生成交易信号。

数据库集群：从市场接收原始数据需要高带宽的数据传输。重新采样这些数据可能会非常密集，因为你需要相同的数据库进行开发和生产，所以确实需要具有高吞吐量。

开发和研究工具：通过在相同的系统上开发模型，你可以确保在满足必要的边界条件方面有更好的质量。毕竟，它现在是你的数据，你确切地知道花了多长时间来接收和处理它。

为什么REST API和scrapper服务是分开的?
这个决定是基于提高系统的速度，确保系统全天候可靠性。例如当你决定你想打开或关闭一个位置时，你不想不断查询数据库，通过查询REST API直接将信息存储在RAM（降低硬盘开销）你能够获得更高的汇集频率（这也很大程度上取决于你与交易所和所选择的编程语言的距离)。如果REST服务由于某种未知的原因失败，你可以重新启动，不会丢失任何正在进行的数据流，同时有足够的时间安全地重新启动它。这与触发交易信号并试图执行交易是不同的。你需要尽快完成交易。

总结

在实现这样的架构时，我们遇到了许多瓶颈，同时还试图为我们所做的模型预测获得最佳的边界条件。这是在实现全天候可靠性的同时获得最佳数据的流程。