第三章 系统架构设计

第三章 · 系统架构设计

章节摘要：前两章解决了"看懂市场"，本章开始解决"建起系统"。架构设计回答的是一个问题：在一台或多台机器上，行情接收、订单簿重建、信号计算、风控、报单这些职责如何切分、如何摆放、如何互相对话。它决定的不只是性能——架构是一次性的决定，策略可以天天换，架构换一次要伤筋动骨。本章先给出整体范式与核心组件的职责切分，再深入组件之间的通信与同步机制。读完你应当能为一条策略链路画出完整的组件图，并说清每个箭头为什么是现在的样子。

学习目标

1. 说明单机紧凑架构与分布式架构各自的适用场景，以及切换的触发条件；
2. 列出热路径上的核心组件及其职责边界，说明为什么风控必须内联在热路径上；
3. 理解共享内存与无锁队列两种进程间通信手段的原理与代价；
4. 区分阻塞、轮询、事件驱动三种收发模型的延迟特征；
5. 画出一条典型做市策略的组件数据流图，标注每个环节的预算。

核心概念速览

一句金句：好的架构不追求组件各处都快，而追求数据流上没有一次多余的等待——齿轮之间的间隙，才是走时误差的来源。

图：一条策略链路的标准组件布局

子章节导航

3.1 整体架构范式与核心组件——从单机范式讲起：为什么行业主流是"一台机器装下整条热路径"，职责如何切分成行情接入、订单簿、策略、风控、网关五个组件，什么情况下才值得走向分布式。组件边界切错的地方，就是日后延迟与故障的藏身处。

3.2 组件间通信与同步——组件定了，如何对话：共享内存与无锁队列的原理，单写单读环形缓冲为什么是核间通信的主力，事件驱动与轮询的取舍，以及时钟与顺序这两个容易被低估的同步问题。

子章节之间的逻辑关系

本节的论点是：组件切分决定通信需求，通信机制反过来约束组件设计。3.1 切出的五个组件里，任何两个之间的一次跨机跳、一次系统调用、一把锁，都是 3.2 要消灭的对象；而 3.2 给出的通信原语（无锁队列、共享内存快照区）又限定了组件间只能传值不能共享可变状态。两节合起来是一个完整的耦合设计，拆开读会丢掉一半信息。

┌────────────────┐   五个组件怎么切    ┌────────────────┐
│ 3.1 范式与组件   │ ─────────────────→ │ 3.2 通信与同步   │
│  职责与摆放      │   组件之间怎么说话   │  无锁与事件驱动  │
└────────┬───────┘                    └────────┬───────┘
         │ 硬件是通信物理极限的底座             │ 数据结构是队列的实现底座
         ▼                                    ▼
   第四章（网络与计算硬件）              第五章（数据结构与内核）
​

常见误区与辨析

误区一：架构越分布式越先进。 在微秒预算面前，分布式是不得已的成本项而非先进性标志。一条热路径跨机一次，预算就多出一大截；评审架构时先问"这一跳能不能免掉"，再问"分布了能不能扛住"，次序不能反。

误区二：风控闸门可以后补。 闸门生在热路径上，位置在组件图定稿时就该钉死。后补的闸门往往变成旁路检查——只拦得住事后对账里的异常，拦不住已经发出去的订单，防护价值损失大半。

误区三：共享内存等于不用设计通信。 共享内存只是把传输降格为拷贝，顺序、完整性与背压三件事一件没少。没有设计的共享内存比消息队列更危险，因为错误是静默的——数据错位不会报错，只会安静地污染下游每一个决策。

前置知识与后续延伸

前置知识：操作系统的进程与线程概念、内存与缓存的直观理解；第二章的订单簿状态是组件间传递的核心数据，最好先读。不要求并发编程经验，3.2 会从原理讲起。

后续延伸：本章的架构图是第四、五章的装配底板——硬件章节解释为什么通信的物理极限长那样，软件章节给出队列与数据结构的实现细节。第七章风控闸门的工程形态也直接挂在本章的组件图上。做架构评审时，本章两节加第七章第一节，是完整的检查清单。