用 Rust 开发交易平台和撮合引擎的公司：哪些部分需要 Rust，以及如何聘请专属团队

找这样一家公司：它自己的工程师已经用 Rust 构建过撮合引擎或订单路径上的其他部分，并让它在生产环境中持续运行。签约之前，先见见将加入你团队的那些人。Rust 值得用在延迟会让你损失金钱的地方：撮合引擎、交易前风控检查、连接交易所的网关，以及行情数据处理程序。界面、报表和后台工具可以继续使用你公司现有的语言。

哪些公司专做 Rust 交易平台和撮合引擎？

本文不给公司排名。所谓专业公司，是指它自己的工程师已经用 Rust 交付过交易系统，并在为客户运行。一家打算在你签约之后才去招 Rust 工程师的公司，给你的其实是一份招聘计划。

交易代码通常不公开：代码一般归客户所有，客户也会把它留在内部，所以一家实力很强的公司在 GitHub 上可能没有多少交易代码。不如请对方从头到尾介绍一套生产系统：它做什么、哪些部分是用 Rust 写的、速度怎么测量、现在由谁运维，以及上线后出过什么故障。如果保密协议让客户名称无法公开，就请这家公司安排你和那位客户通一次电话。

然后核实人。要到将参与你系统开发的工程师的名字和 Rust 经验，并在签约前和他们谈一谈。上面链接的关于专属团队的文章介绍了通用的核查方法：公开代码、付费试做，以及由独立工程师做评审。

交易平台的哪些部分应该用 Rust 来写？

位于订单路径上的那些部分，在那里几毫秒的停顿就可能改变客户拿到的价格：

• 撮合引擎，按价格和到达时间配对买单和卖单
• 交易前风控检查，在订单进入市场之前拦下突破限额的订单
• 网关，把订单发往交易所或经纪商，并接收它们的回复
• 行情数据处理程序，读取价格数据流，并把每一条更新传递下去

Rust 适合这些部分，因为它释放内存不需要垃圾回收器。有些语言用垃圾回收器来做这件事，而它可能在自己选定的时刻让程序暂停。Rust 官方教程《Rust 程序设计语言》（于 2026 年 10 月 27 日查阅）说，所有权，也就是背后的这套规则，“让 Rust 无需垃圾回收器即可保障内存安全”。

语言本身并不会让系统变快。Rust 程序照样可能停下来申请内存、等待另一个线程持有的锁，或者等待网络。关于撮合引擎设计的文章解释了团队如何把这些情况挡在订单路径之外。

平台的其余部分没有以毫秒计的时限：网页和移动端界面、客户账户、报表、后台和管理工具。这些可以继续使用你的开发人员或供应商现有的语言。如果有公司提议把它们用 Rust 重写，就应该说明这样做能给你带来什么。

我们已经有一个用 C++、Java 或 Go 写的平台。要用 Rust 重写吗？

通常不要一次全部重写。更稳妥的做法是先迁移一个边界清晰的组件，比如风控检查或行情数据处理程序，其余部分保持原样。

新组件可以作为一个独立服务运行，与系统其他部分通过消息交换数据。它也可以构建成一个库，由 C 或 C++ 代码直接调用。Rust 项目关于 unsafe 和底层代码的指南《Rustonomicon》在“Calling Rust code from C”一节中介绍了具体做法。

切换之前，让新组件和旧组件在同一段录制的订单流上并行运行，并比较每一个结果。确定性的撮合引擎，对按同样顺序到来的同样订单，总是给出同样的结果。这让比较变得简单：如果两个引擎采用同样的规则，任何差异都说明其中一个有 bug。

然后一次只迁一个市场或一组品种，并让旧组件随时准备接回流量。

撮合引擎的外包 Rust 专属团队包括哪些人？

专属团队在几个月甚至几年里只为你的系统工作，成员只有在你同意时才会变动。对于撮合引擎或订单路径上的其他部分，这样的团队通常包括：

• 把代码交付到生产环境过、懂得一笔订单如何流转的 Rust 工程师：订单类型、部分成交、改单和撤单
• 负责整体设计、审查订单路径上每一处改动的首席工程师
• 搭建回放录制订单流的测试环境并核对结果的测试工程师
• 负责服务器、网络设置和版本发布的人

你的公司也要承担一部分工作。你这边要有人来决定交易规则，比如最小报价单位、交易时段、费用，以及交易暂停时怎么处理，并且不拖延地回答团队关于这些规则的问题。

自由职业者也可能是出色的工程师，但和他们合作很难保证连续性。单个外包人员没有人审查他对订单路径的改动，而这个人一旦离开，他对你的系统的了解也跟着带走了。公司可以换人，并把知识留在团队里，合同也可以要求它这样做。

公司只有在看过你的交易规则、市场和交易量之后，才能估算团队规模，所以要问清楚它报出的人数是怎么得出的。

关于撮合引擎，应该问 Rust 团队哪些问题？

关于如何核查速度数据，请看介绍低延迟公司的那篇文章。下面这些问题针对的是 Rust 和订单路径：

• 你们的代码在哪些地方用了 unsafe，这些部分由谁审查？
• 除了回放录制的订单，你们还怎么测试这个引擎？
• 订单路径依赖哪些 crate，你们怎么检查它们有没有已知漏洞？
• 你们用哪个 Rust 版本构建，又怎么决定何时升级？
• 拟派团队中谁把 Rust 交付到过生产环境，是在什么系统上，那套系统现在还在运行吗？

Rust 在编译代码时就检查内存的使用方式。在标记为 unsafe 的代码块里，代码可以做五件编译器平时不允许的事，比如顺着裸指针去访问内存。《Rust 程序设计语言》还指出，unsafe “并不会关闭借用检查器，也不会禁用 Rust 的任何其他安全检查”。好的回答会说明 unsafe 代码在哪里、为什么那里需要它，以及由谁审查过。

说到测试，团队应当说得出自己用哪些工具。《Rust Fuzz Book》称 cargo-fuzz 是“对 Rust 代码做模糊测试的推荐工具”，它向程序输入大量自动生成的数据，找出会让程序崩溃的情况。Loom 是一个用于测试多线程代码的库，它会“多次运行测试，排列组合每个测试可能的并发执行顺序”。这样能找出只有在线程恰好以某种不走运的顺序运行时才会出现的 bug。

crate 是 Rust 里共享代码的包。RustSec Advisory Database 收录针对 crates.io 上已发布 crate 的安全公告。它的工具 cargo-audit 会检查项目的 Cargo.lock（列出每个依赖确切版本的文件），“查找存在安全漏洞的 crate”。负责订单路径的团队应当能告诉你，这样的检查是否在每次构建时都会运行。

Rust 每六周发布一个新的稳定版本，《Rust 程序设计语言》说，“你永远不必害怕升级到新的 Rust 稳定版”。即便如此，团队仍可以让所有构建固定在一个选定的版本上。Rust 安装工具 rustup 的文档介绍了一种 toolchain 文件，供那些“‘固定’在某个特定 Rust 版本上”、并希望把这一点记录在代码仓库里的项目使用。对订单路径来说，版本只应在有意为之、并且测试通过之后才变更。

与 Rust 团队的合同应该写明什么？

在合同中写入以下几点：

• 代码、测试、回放数据和构建脚本存放在你公司拥有的代码仓库中
• 构建和发布在以你公司名义开设的账户中进行
• 谁可以修改订单路径，谁审查每一处改动
• 团队负责覆盖的时段，以及在这些时段之外引擎出故障时由谁响应
• 合同终止时你能得到什么：文档、访问权限，以及团队向下一支团队交接所需的时间

amBrain 在其中处于什么位置？

发布本博客的 amBrain 用一句话这样描述自己：“amBrain是一家位于亚美尼亚埃里温的软件工程公司，用Rust构建低延迟交易平台、撮合引擎和实时竞价系统。”另一句是：“amBrain 构建算法交易基础设施：订单执行、行情数据和交易前风控。”

amBrain 自 2019 年起开发软件。用它自己的话说，它的团队是：“团队规模最多 40 人，其中约 75% 是资深人员。”它有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。它关于所有权的说法是：“客户拥有产品与代码的全部所有权，我们的可复用组件除外。”

本文不是案例研究，也不描述任何客户项目。文中没有说 amBrain 用 Rust 构建过哪些系统、为谁构建，也不给出 amBrain 的价格、工期或团队规模。如果 amBrain 在你的候选名单上，就给它和其他任何公司同样的问题。