为什么我们选择Java开发高频交易系统？

在高频交易领域，自动化应用程序每天需要处理数亿个市场交易信号，并在全球各交易所之间发送成千上万的订单。

 

为了保持竞争力，响应时间必须始终保持在微秒级，特别是在发生类似“黑天鹅”事件的异常高峰期。

 

在一个典型的架构中，金融市场的交易信号被转换成内部的市场数据格式(使用各种协议，如 TCP/IP、UDP 组播和多种格式，如二进制、SBE、JSON、FIX 等)。

 

这些规范化的消息被发送到算法服务器、统计引擎、用户界面、日志服务器和各种类型的数据库(内存数据库、物理数据库、分布式数据库)。

 

这条路径上的任何一个延迟都有可能带来严重后果（比如基于旧价格做出战略决策或订单到达交易市场的时间太迟），并为此付出惨重代价。

 

为了加快至关重要的几微秒，大多数券商投入了昂贵的硬件：服务器组配备了超频液冷的 CPU(在 2020 年，你可以买到单台配备了 56 核 5.6 GHz CPU 和 1 TB 内存的服务器)、靠近交易所的数据中心、纳秒级高端网络交换机、海底专线(Hibernian Express 是一家主要的供应商)，甚至是微波网络。

 

我们经常看到高度定制的可以绕过操作系统的 Linux 内核，数据可以直接从网卡“跳转”到应用程序、IPC(进程间通信)，甚至是 FPGA(可编程单用途芯片)。

 

在编程语言方面，C++似乎是服务器端应用程序的天然竞争者：它速度快，与机器码非常接近，而且一旦针对目标平台进行编译，就可以提供恒定的处理时间。

 

但是，我们做了一个不一样的选择。

 

在过去的14年里，我们一直在用Java开发外汇算法交易系统，并使用了很棒但价格实惠的硬件。

 

由于团队规模小，资源有限，技术能力强的开发人员难找，所以使用 Java 意味着我们可以快速地改进软件功能，因为 Java 生态系统比 C 语言生态系统的发布速度更快。上午讨论功能改进，下午就可以实现、测试并发布到生产环境。

 

与那些需要几周甚至几个月才能发布更新的大公司相比，这是一个关键的优势。在高频交易领域，一个漏洞可以在几秒钟内抹掉一整年的利润，所以我们不打算在质量上做任何妥协。我们搭建了一个严格的敏捷开发环境，包括 Jenkins、Maven、单元测试、夜晚构建和 Jira，使用了很多开源库和项目。

 

使用 Java，开发人员可以专注于直观的面向对象业务逻辑