第三章：系统架构总览——分层架构设计、模块划分、数据流向
好，咱们进入正题。报价路由系统，说白了就是一个「钱和订单的调度中心」。你想想看，一个订单进来，要去哪个交易所？走哪条路径？成本最低还是速度最快？这些决策，都得靠架构来支撑。
我个人习惯，做这种金融核心系统，第一件事就是画分层图。不是画着好看，是让团队一眼就能看懂：数据从哪来，到哪去，谁负责什么。
3.1 分层架构设计：四层模型
我参与过好几个报价路由项目，踩过不少坑。最后沉淀下来的，就是下面这个四层模型。嗯，这里要注意，每一层都有它的职责，千万别越界。
核心分层：
- 接入层（Gateway Layer）：负责协议转换、会话管理、安全认证。说白了，就是跟外部系统打交道的那层。
- 路由层（Routing Layer）：核心决策层。根据报价、成本、延迟等策略，决定订单去哪。
- 执行层（Execution Layer）：跟交易所、流动性提供商对接。发送订单、接收成交回报。
- 数据层（Data Layer）：存储报价、订单、成交、日志等所有数据。
为什么这么分？我在项目中遇到过一件事：有个同事把路由逻辑和接入逻辑混在一起写，结果每次改交易所协议，都得重新测试整个路由策略。那叫一个痛苦。从那以后，我坚持分层必须清晰，接口必须稳定。
3.2 模块划分：每个模块只做一件事
分层定好了，接下来就是模块划分。我建议遵循一个原则：高内聚、低耦合。每个模块只做一件事，并且做好。
| 模块名称 | 职责 | 关键接口 |
|---|---|---|
| 报价接收器 | 接收外部报价源，做格式校验和标准化 | onQuoteReceived(quote) |
| 路由引擎 | 根据策略选择最优路径 | route(order) -> path |
| 订单管理器 | 管理订单生命周期，状态机控制 | createOrder(), cancelOrder() |
| 风控模块 | 检查订单是否合规，防止异常交易 | validate(order) -> boolean |
| 日志审计 | 记录所有操作，用于事后追溯 | log(event) |
避坑指南：我曾经犯过一个错，把风控逻辑直接写在路由引擎里。结果每次改风控规则，都得重新部署整个路由模块。后来我把风控独立成一个模块，通过配置中心动态加载规则，这才算彻底解决。
3.3 数据流向：订单的「一生」
一个订单从进入系统到最终成交，到底经历了什么？我画了一张图，你跟着走一遍就明白了。
流程其实很简单：
- 客户端发起订单：比如一个买入请求，通过API发送到接入层。
- 接入层做第一道处理：校验格式、解析协议、做基础认证。我建议这里只做轻量级处理，别搞复杂了。
- 路由层做决策：根据当前报价、成本、延迟等，选择最优路径。这是整个系统的核心。
- 执行层发送订单：把订单发到选定的交易所，并等待成交回报。
- 数据层异步落盘：所有环节的数据，都异步写入日志和数据库，方便事后审计。
注意：数据流向中，最容易被忽略的是「回压机制」。我曾经遇到过一个场景：执行层处理不过来，结果接入层还在拼命接收新订单，最后整个系统OOM。所以，每一层之间都要有流量控制和背压机制。
3.4 关键设计原则
最后，分享几个我这些年总结出来的原则。不一定适合所有场景，但至少能帮你少走弯路。
- 无状态优先：路由引擎、执行层尽量设计成无状态，方便水平扩展。状态都丢到数据层去。
- 异步非阻塞：金融系统对延迟敏感，同步调用会阻塞线程。我习惯用事件驱动模型，配合消息队列。
- 可观测性：每一层都要有监控指标。延迟、吞吐量、错误率，缺一不可。没有监控的系统，就是盲人摸象。
- 优雅降级：某个交易所挂了，不能影响其他交易所的路由。我曾经见过一个系统，一个交易所超时，结果整个路由都卡住了。那叫一个惨。
总结一下：
分层架构是骨架，模块划分是肌肉，数据流向是血液。三者缺一不可。你想想看，骨架歪了，肌肉再强壮也没用；血液不通，整个系统就瘫痪了。
我个人习惯，每次设计新系统，都会先画这三张图：分层图、模块图、数据流图。画清楚了，代码怎么写就一目了然了。