第二章：系统架构设计——高频交易系统的骨架
做高频交易，说白了就是在跟时间赛跑。你想想看，别人还在犹豫要不要下单，你的系统已经完成了一整套从行情接收到订单成交的流程。这背后靠的是什么？就是一套精心设计的系统架构。
我个人习惯把架构设计比作盖房子。地基没打好，后面装修得再漂亮也没用。今天我们就来聊聊高频交易系统的核心组件、低延迟架构的设计原则，以及事件驱动和微服务这些概念到底该怎么用。
核心观点：高频交易系统的架构设计，目标只有一个——在保证正确性的前提下，把延迟压到最低。其他所有考虑，都得为这个目标让路。
2.1 核心组件：系统里都有哪些零件？
一个典型的高频交易系统，至少包含这几个模块：
- 行情网关：负责接收交易所的实时行情数据。这东西很关键，因为它是整个系统的数据入口。
- 策略引擎：根据行情数据做出交易决策。这是系统的"大脑"。
- 订单管理：负责生成、发送、跟踪订单状态。
- 风控模块：在交易前和交易后做检查，防止出现异常交易。
- 日志与监控：记录所有关键事件，方便事后复盘和实时告警。
我在项目中遇到过一个问题：行情网关和策略引擎之间的数据传输延迟太高。后来发现是序列化方式选错了。嗯，这里要注意，高频场景下千万别用 JSON，用 Protobuf 或者直接共享内存。
我的建议：核心路径上的数据传递，尽量用零拷贝技术。比如用内存映射文件（mmap）或者共享内存，能省掉一次甚至多次数据复制的开销。
2.2 低延迟架构设计原则
低延迟不是一句口号，它体现在每一个设计决策里。我总结了几个关键原则：
- 减少上下文切换：线程不是越多越好。高频交易系统里，核心线程最好绑定到固定的 CPU 核心上，避免被操作系统调度来调度去。
- 避免锁竞争：能用无锁数据结构就用无锁的。比如用环形缓冲区（Ring Buffer）代替队列，用 CAS 操作代替互斥锁。
- 数据局部性：把经常一起访问的数据放在内存的相邻位置，充分利用 CPU 缓存。
- 预分配资源：不要在交易过程中动态分配内存。所有对象在系统启动时就创建好，运行时只复用。
为什么会这样？因为一次内存分配可能触发垃圾回收，而 GC 暂停对高频交易来说是致命的。我曾经见过一个系统，因为 Java 的 GC 导致订单延迟从 10 微秒飙升到 100 毫秒，直接错过了好几个交易机会。
避坑指南：我曾经在项目里用了一个看起来很优雅的锁机制，结果压测时发现延迟抖动特别大。后来换成无锁队列，问题就解决了。记住，在高频交易里，"看起来优雅"不如"跑起来稳定"。
2.3 事件驱动架构
高频交易系统天然适合事件驱动架构。为什么？因为整个交易过程就是一系列事件的组合：行情到达、信号触发、订单生成、成交回报……
事件驱动架构的核心是事件循环。一个典型的事件循环长这样：
while (running) {
event = event_queue.dequeue(); // 取出下一个事件
if (event.type == MARKET_DATA) {
strategy.on_market_data(event.data);
} else if (event.type == ORDER_UPDATE) {
order_manager.on_update(event.data);
}
// ... 其他事件处理
}这个模式的好处是：没有线程切换，没有锁竞争，所有处理都在一个线程里完成。延迟非常可控。
我个人习惯把事件分为两类：
- 外部事件：来自交易所的行情和成交回报。这些事件优先级最高，必须第一时间处理。
- 内部事件：比如定时任务、风控检查结果。这些可以稍微延后处理。
你想想看，如果行情事件和日志事件在同一个队列里，万一日志写入慢了，行情处理就会被阻塞。所以，我建议把不同优先级的事件放到不同的队列里，用优先级调度来保证关键路径的延迟。
2.4 微服务与单体架构的权衡
这个问题我经常被问到。很多人觉得微服务是"先进"的，单体是"落后"的。但在高频交易领域，事情没那么简单。
先说说单体架构的优势：
- 延迟最低：所有模块在同一个进程里，函数调用就是几条指令的事。
- 调试方便：出问题了一个 GDB 就能搞定。
- 部署简单：就一个二进制文件，扔到服务器上就能跑。
微服务呢？
- 可扩展性好：哪个模块负载高了，单独加实例就行。
- 容错性强：一个服务挂了，不影响其他服务。
- 团队协作方便：不同团队可以独立开发和部署自己的服务。
但微服务的代价也很明显：服务间通信有网络延迟，序列化/反序列化有开销，分布式事务处理起来很麻烦。
我在实际项目中是怎么做的？
核心交易链路用单体架构。行情接收、策略计算、订单发送这些关键步骤，全部放在一个进程里。非核心功能，比如日志存储、监控告警、历史数据回放，拆成独立的微服务。
这样既保证了核心路径的低延迟，又享受了微服务在扩展性和维护性上的好处。
一句话总结：核心链路用单体，外围功能用微服务。别为了"架构先进"而牺牲延迟。
2.5 架构全景图
下面这张图展示了高频交易系统的整体架构。你可以看到各个组件之间的关系，以及数据流动的方向。
从这张图你可以看到，核心交易链路是一条直线：行情从交易所进来，经过行情网关、策略引擎、订单管理，最后回到交易所。风控和日志模块是旁路，它们不参与核心路径，但提供了必要的安全保障和可追溯性。
2.6 一些实战经验
最后分享几个我在项目中踩过的坑：
- 别信"理论延迟"：纸上算出来的延迟和实际跑出来的延迟，差距可能很大。一定要做压测，而且要在生产环境的硬件上做。
- 关注尾部延迟：平均延迟 10 微秒看起来很漂亮，但如果 P99 延迟是 100 微秒，那你的系统在极端情况下会出问题。
- 硬件也很重要：同样的代码，在普通服务器和专用低延迟服务器上跑，延迟能差一个数量级。别在硬件上省钱。
嗯，架构设计这部分内容就到这里。记住一句话：没有完美的架构，只有适合你场景的架构。高频交易的核心是延迟，所有设计都要围绕这个目标来展开。