系统架构设计：分层架构与消息队列选型
做衍生品做市商系统，我第一个要跟你聊的就是架构。
为什么？因为这东西直接决定了你的系统能不能扛住极端行情，能不能快速迭代。我在2018年帮一家做市商重构系统时，他们用的还是单体架构，每次上线都提心吊胆。后来我们花了三个月拆成微服务，效果立竿见影。
分层架构：各司其职
我个人习惯把系统分成四层。你想想看，每一层只干一件事，出了问题也好定位。
| 层级 | 职责 | 典型组件 |
|---|---|---|
| 接入层 | 处理外部连接、协议转换 | WebSocket网关、REST API |
| 逻辑层 | 定价、订单管理、策略执行 | 做市引擎、订单管理器 |
| 风控层 | 实时监控、限额检查、熔断 | 风控引擎、阈值计算器 |
| 数据层 | 行情存储、交易记录、回测数据 | 时序数据库、消息队列 |
接入层说白了就是门面。交易所的行情通过WebSocket进来，你的订单也要通过它发出去。我建议这里做一层协议适配，把不同交易所的差异屏蔽掉。逻辑层是核心，做市策略、报价生成都在这里。风控层是个独立的存在，它不参与交易，但有权随时叫停。数据层负责把一切记录下来，方便事后复盘。
关键原则：每一层只能跟相邻层通信。逻辑层不能直接访问数据库，必须通过数据层。这样耦合度最低。
微服务 vs 单体架构
这个问题我纠结过很久。说实话，没有银弹。
单体架构适合团队小、业务简单的场景。你想想，就两三个人开发，搞微服务纯粹是给自己找麻烦。部署、监控、服务发现，这些都要额外投入。我早期做的一个项目就是单体，上线快，调试方便。但后来业务量上来，每次改个报价逻辑都要重新部署整个系统，太痛苦了。
微服务的好处是独立部署、独立扩展。比如行情接入压力大，你可以单独给接入层加机器。风控层需要高稳定性，可以单独做容错。但代价是复杂度飙升。我记得有一次排查一个订单丢失问题，跨了四个服务，日志追了一整天。
我的建议：初期用单体，但代码结构按分层来写。等业务验证通过，再拆成微服务。别一上来就搞分布式，容易把自己绕进去。
这里我画了一张架构图，帮你理清思路：
消息队列选型：Kafka vs Pulsar
消息队列在交易系统里扮演什么角色？说白了就是解耦和缓冲。行情数据、订单状态变更、风控告警，这些都需要异步传递。
Kafka 是目前最主流的方案。吞吐量高，延迟低，生态成熟。我在项目中用 Kafka 处理行情数据，单机就能扛住每秒几十万条消息。但 Kafka 有个问题：分区数量有限，扩展起来比较麻烦。而且它的消费模型是拉模式，实时性不如推模式。
Pulsar 是后起之秀。它用 BookKeeper 做存储，支持多租户、分层存储。我记得有个场景需要保留7天的行情数据做回测，Kafka 的磁盘占用太大了。Pulsar 可以把冷数据自动迁移到 S3，成本低很多。但 Pulsar 的社区和工具链不如 Kafka 成熟，遇到问题可能得自己啃源码。
避坑指南：我曾经在选型时只看吞吐量，忽略了消息顺序。做市商系统对订单顺序要求极高，一旦乱序可能导致报价错误。Kafka 在分区内保证顺序，Pulsar 需要额外配置。这个坑我踩过，你一定要注意。
给你一个简单的选型建议：
- 团队熟悉 Kafka，业务量中等：选 Kafka，稳
- 需要多租户、数据长期保留：选 Pulsar，灵活
- 对消息顺序要求极高：优先考虑 Kafka 分区内顺序
- 预算有限，不想维护复杂集群：先用 Redis Stream 过渡
嗯，这里要注意一点。无论选哪个，消息的幂等性一定要处理好。网络抖动、消费者重启，都可能导致重复消费。我习惯在消息里加一个唯一ID，消费端做去重。
最后说一句，架构设计没有标准答案。你现在的团队规模、业务复杂度、技术栈，都会影响最终选择。关键是理解每个方案的优缺点，然后做出权衡。
公众号:蓝海资料掘金营，微信deep3321