系统架构总览：分层架构设计

做高频交易系统，说白了就是跟时间赛跑。我见过太多团队一上来就堆微服务、上K8s，结果延迟高得离谱。今天咱们聊聊系统架构的核心思路——怎么把这件事做对。

一、为什么必须分层？

高频交易系统不是普通的Web应用。它有三个截然不同的任务：拿数据、做决策、下订单。这三件事对性能的要求完全不同。

我个人习惯把系统拆成三层：

• 数据层：负责行情接入、数据清洗、缓存。延迟要求最苛刻，通常要微秒级。
• 策略层：负责信号计算、风险管理。这里需要灵活，但也不能太慢。
• 执行层：负责订单管理、路由、风控。稳定压倒一切，丢单就是丢钱。

为什么要这么分？我在项目中遇到过一件事：有一次策略层出了个bug，疯狂发单。如果数据层和执行层没分开，整个系统直接崩了。分层之后，执行层可以独立做流控，把损失降到最低。

二、数据层：地基要稳

数据层是系统的入口。行情数据进来，第一件事就是去重、对齐、打时间戳。嗯，这里要注意：不同交易所的时间戳格式可能不一样，有的用纳秒，有的用微秒。我建议统一转成纳秒，避免后续计算混乱。

数据层通常用内存数据库或者共享内存来缓存。为什么？因为磁盘IO太慢了。你想想看，一个行情包从网卡到应用，延迟可能只有几微秒，但一旦落盘，直接飙到毫秒级。这在高频交易里是不能接受的。

三、策略层：灵活但别乱

策略层是核心逻辑所在。这里我建议用插件化的方式设计。每个策略是一个独立的模块，可以热加载、热卸载。这样你上线新策略时，不需要重启整个系统。

策略层最怕什么？计算延迟抖动。比如某个策略突然触发了一次垃圾回收，延迟从10微秒跳到100毫秒，那这笔交易基本就废了。所以策略层最好用无GC语言（比如C++、Rust）或者预分配内存的方式。

我个人的经验是：策略层不要做太复杂的计算。复杂的模型放到离线环境去跑，线上只做轻量级的信号生成。你想想看，一个策略如果计算时间超过100微秒，那它基本不适合高频交易。

四、执行层：稳如磐石

执行层是系统的最后一道防线。它负责把策略生成的信号变成真实的订单。这里的要求很简单：不丢单、不重复、不乱序。

执行层通常需要对接多个交易所。每个交易所的API协议、限频规则都不一样。我建议在中间加一层适配器，把不同交易所的差异屏蔽掉。这样策略层只需要调用统一的接口，不用关心底层细节。

执行层还有一个重要任务：订单状态管理。一个订单从提交到成交，中间可能有多种状态（已提交、部分成交、全部成交、已撤销）。这些状态必须准确记录，否则风控会出大问题。

五、微服务 vs 单体架构

这个问题我经常被问到。我的回答是：看规模。

如果你只是做单一品种、单一交易所的交易，单体架构完全够用。甚至因为减少了网络开销，延迟反而更低。我见过一些团队，明明只有两个策略，非要拆成10个微服务，结果延迟从50微秒变成了500微秒。

但如果你做多品种、多交易所，微服务就有优势了。每个服务可以独立扩缩容，一个服务挂了不影响其他服务。比如数据层挂了，策略层还能用缓存的数据继续跑一段时间。

对比维度	单体架构	微服务架构
延迟	低（无网络开销）	高（有网络开销）
扩展性	差（整体扩缩容）	好（按需扩缩容）
维护性	简单	复杂（需要服务治理）
容错性	差（一个bug拖垮全局）	好（故障隔离）

六、关键性能指标

做高频交易，有三个指标你必须盯死：

• 延迟：从行情数据到达系统，到订单发出，总共花了多少时间。通常要求微秒级。
• 吞吐量：系统每秒能处理多少笔交易。这个取决于你的策略复杂度和硬件配置。
• 抖动：延迟的波动范围。抖动越小，系统越稳定。我见过最夸张的抖动是100倍——平时10微秒，偶尔1000微秒。这种系统根本没法用。

这三个指标是相互制约的。比如你追求极致的低延迟，可能就要牺牲吞吐量。你追求高吞吐量，抖动可能会变大。怎么平衡？嗯，这取决于你的交易策略。

七、架构图：一目了然

下面这张图展示了典型的高频交易系统分层架构。我特意把数据流和控制流分开画，这样更清晰。

八、总结

高频交易系统的架构设计，说白了就是在延迟、吞吐量、抖动之间找平衡。没有银弹，只有取舍。

我个人习惯先画架构图，把数据流和控制流理清楚。然后从数据层开始，一层一层往下做。每层都留好监控接口，这样出了问题能快速定位。

嗯，最后说一句：别迷信某个架构模式。适合你的业务场景的，才是最好的。