第1章：技术架构总览
大家好，我是老张。在银行间做市这个领域摸爬滚打了十几年，今天咱们聊聊技术架构这件事。
很多人问我：做市系统的核心到底是什么？我的回答很简单——快、稳、准。快是低延迟，稳是高可用，准是数据一致。这三者缺一不可。
这一章，我会把整个交易系统的分层架构、网络设计原则、以及灾备方案给你讲透。嗯，都是我在实战中踩过的坑和总结的经验。
一、交易系统分层架构
我个人习惯把做市系统分成三层：接入层、业务层、数据层。为什么这么分？说白了，每一层解决不同的问题，耦合度低，出了问题也好定位。
核心原则：层与层之间通过标准协议通信，不跨层调用。我曾经见过一个项目，业务层直接操作数据库，结果一次慢查询把整个系统拖垮了。
1. 接入层
接入层是系统的门面。它负责处理所有外部连接，包括交易所、经纪商、以及内部客户端的请求。
- 协议转换：FIX、Binary、WebSocket 等协议统一转为内部消息格式
- 会话管理：维护连接状态，处理心跳、重连、登录认证
- 流量控制：限流、熔断、降级，防止突发流量打垮后端
- 安全校验：IP白名单、API密钥验证、数据加密
我记得有一次，某个交易所突然推送了10倍于正常量的行情数据。幸好接入层做了限流，不然业务层直接崩了。从那以后，我要求所有接入层必须配置熔断阈值。
2. 业务层
业务层是系统的核心大脑。所有交易逻辑、风控检查、订单管理都在这里完成。
| 模块 | 功能 | 延迟要求 |
|---|---|---|
| 定价引擎 | 根据市场行情实时计算报价 | < 10μs |
| 风控模块 | 检查敞口、限额、异常交易 | < 50μs |
| 订单管理 | 订单生命周期管理、成交回报处理 | < 100μs |
| 策略引擎 | 执行做市策略、对冲逻辑 | < 1ms |
这里有个坑：很多人把风控和定价放在同一个线程里。我建议分开，因为风控一旦阻塞，定价也会受影响。我曾经因为一个风控规则里调用了外部数据库，导致定价延迟飙升了20倍。
3. 数据层
数据层负责所有数据的持久化和查询。包括行情数据、交易记录、账户信息等。
- 行情数据库：使用时序数据库（如InfluxDB、ClickHouse）存储Tick级数据
- 交易数据库：使用关系型数据库（如PostgreSQL）存储订单、成交、持仓
- 缓存层：使用Redis或内存数据库加速热点数据访问
- 日志系统：所有操作记录到日志，用于审计和复盘
我的经验：数据层一定要做读写分离。写库用SSD，读库用内存。我曾经见过一个团队把所有数据都放在同一个MySQL实例里，结果一次大查询把整个系统锁死了。
二、低延迟网络设计原则
做市系统对延迟极其敏感。你想想看，别人比你快1微秒，可能就抢走了你的订单。所以网络设计是重中之重。
1. 物理层优化
- 就近部署：服务器放在交易所机房或同城数据中心，减少物理距离
- 光纤直连：使用暗光纤或专线，避免公网抖动
- 硬件选型：使用Solarflare、Mellanox等低延迟网卡，开启DPDK
我记得有一次，我们把服务器从上海搬到交易所机房，延迟从2ms降到了200μs。嗯，物理距离就是这么重要。
2. 协议层优化
- 放弃TCP：使用UDP或RDMA，减少协议栈开销
- 自定义协议：二进制编码，避免JSON/XML解析
- 零拷贝：数据从网卡直接到应用内存，不经过内核
注意：UDP虽然快，但需要自己处理丢包和重传。我建议在关键路径上用RDMA，非关键路径上用UDP+应用层ACK。
3. 架构层优化
- 事件驱动：使用Reactor模式或Proactor模式，避免线程切换
- 无锁编程：使用CAS、内存屏障替代锁
- CPU亲和性：绑定核心，避免上下文切换
- 内存池：预分配内存，避免动态分配
说白了，低延迟就是跟操作系统抢时间。你想想看，一次系统调用就要几百纳秒，一个锁竞争可能几微秒就没了。所以我们要尽可能绕过操作系统。
三、系统高可用与灾备方案
做市系统不能停。停了就是钱。我见过一个团队因为单点故障，一天损失了几百万。所以高可用和灾备必须从设计之初就考虑。
1. 高可用设计
| 层级 | 方案 | 切换时间 |
|---|---|---|
| 接入层 | 多活负载均衡（LVS/HAProxy） | < 1s |
| 业务层 | 主备切换（Keepalived + VIP） | < 5s |
| 数据层 | 主从复制 + 自动故障转移 | < 30s |
这里要注意：主备切换不是万能的。我曾经遇到一个情况，主节点挂了，备节点因为数据同步延迟，导致部分订单丢失。所以建议使用同步复制，虽然会牺牲一点性能，但数据一致性更重要。
2. 灾备方案
- 同城双活：两个数据中心同时提供服务，距离< 50km
- 异地灾备：第三个数据中心做冷备，距离> 500km
- 数据同步：使用Kafka或Pulsar做跨数据中心消息同步
- 演练机制：每月一次灾备演练，确保切换流程可用
我的建议：灾备方案一定要做自动化。我曾经见过一个团队，灾备切换需要手动执行20多个步骤，结果真正出问题时，操作员紧张得忘了步骤。嗯，那次事故之后，我们写了一套自动化切换脚本。
3. 监控与告警
没有监控的高可用是假的。我要求系统必须监控以下指标：
- 延迟：端到端延迟、各模块处理延迟
- 吞吐量：每秒处理订单数、行情数
- 错误率：订单失败率、连接断开次数
- 资源使用：CPU、内存、网络、磁盘IO
- 数据一致性：主从延迟、数据校验结果
告警阈值要设置合理。太敏感了会被忽略，太迟钝了又起不到作用。我一般设置三级告警：黄色（预警）、橙色（严重）、红色（紧急）。
四、架构总览图
下面这张图是我画的一个简化版架构总览。你可以看到三层之间的数据流向，以及网络和灾备的布局。
这张图虽然简化了，但核心思想都在里面。三层之间通过消息队列或共享内存通信，网络层使用专线或RDMA，灾备层通过数据同步实现。
五、总结
好了，这一章的内容就到这里。我带你看了做市系统的三层架构、低延迟网络的设计原则、以及高可用灾备方案。说白了，这些都不是什么高深的理论，而是我在实战中一点一点积累出来的经验。
你可能会问：这些方案都靠谱吗？我的回答是：没有完美的方案，只有最适合你的方案。关键是要理解每个设计背后的权衡，然后根据你的业务场景做选择。
最后说一句：架构设计不是一蹴而就的。我建议你先从最简单的方案开始，然后根据实际运行情况逐步优化。别一开始就想搞个大而全的系统，那样反而容易出问题。