系统架构总览：暗池系统的骨架设计
做暗池系统这几年，我最大的感受就是：架构设计就像搭积木，但每一块积木都不能随便选。今天咱们聊聊暗池系统的整体架构，我会结合自己踩过的坑，把分层、微服务、技术选型这些核心问题讲清楚。
一、暗池系统的整体架构设计
先说说暗池系统的核心目标。说白了，就是让大额订单在隐藏真实意图的前提下完成撮合。这要求系统必须做到三点：低延迟、高可用、强隐私。
我个人习惯把暗池系统分成四个核心域：
- 订单域：负责订单的接收、校验、路由
- 撮合域：核心引擎，执行价格优先、时间优先的匹配逻辑
- 清算域：成交后的资金与证券划转
- 风控域：实时监控异常交易行为
嗯，这里要注意，每个域之间必须通过异步消息解耦。我在项目中遇到过因为同步调用导致撮合引擎被风控拖垮的情况，后来改成事件驱动才解决。
核心架构原则：每个域只做一件事，并且做到极致。订单域不碰撮合逻辑，撮合域不关心清算细节。
二、分层架构模式：为什么我坚持用四层
分层架构不是什么新鲜事，但暗池系统对分层有特殊要求。我通常采用四层结构：
| 层级 | 职责 | 典型组件 |
|---|---|---|
| 接入层 | 协议转换、会话管理 | WebSocket网关、FIX引擎 |
| 业务层 | 订单处理、风控校验 | 订单服务、风控服务 |
| 核心层 | 撮合引擎、行情生成 | 撮合核心、OrderBook |
| 基础设施层 | 存储、网络、监控 | Redis、Kafka、Prometheus |
你想想看，为什么非得分这么细？因为每一层的故障隔离能力完全不同。我曾经见过一个系统，把撮合逻辑和订单校验写在一起，结果一次风控规则更新导致整个撮合服务重启了30秒——这在暗池交易里是致命的。
我的经验：接入层和业务层之间一定要加一层「流量整形」。暗池的订单洪峰可能瞬间达到正常值的100倍，没有这层保护，核心层直接被打穿。
三、微服务 vs 单体架构：我选微服务，但有前提
这个问题我纠结过很久。早期暗池系统很多是单体架构，因为撮合逻辑确实可以写在一个进程里。但后来我发现，单体架构在暗池场景下有三个硬伤：
- 部署耦合：改一行风控代码，整个系统要重新发布
- 资源隔离差：撮合引擎吃满CPU时，订单接收也会受影响
- 扩展性受限：无法单独扩容某个热点服务
所以我现在倾向于微服务架构。但注意，不是所有服务都适合微服务化。撮合引擎本身我建议保持单体——因为撮合逻辑需要极低延迟，服务间调用会引入不必要的网络开销。
避坑指南：我曾经把一个撮合引擎拆成3个微服务，结果订单匹配延迟从50微秒飙升到2毫秒。后来我学乖了：核心路径上的服务，能不分就不分。
微服务架构下，我推荐的服务拆分粒度：
- 订单服务：独立部署，可水平扩展
- 撮合引擎：单进程，但支持多实例分片
- 清算服务：异步处理，可批量操作
- 风控服务：独立部署，支持热更新规则
- 行情服务：推送型服务，需要高吞吐
四、技术选型原则：别追新，要追稳
做暗池系统，技术选型我有一条铁律：生产环境用成熟技术，实验环境可以玩新的。为什么？因为暗池交易涉及真金白银，一个bug可能造成数百万损失。
我常用的技术栈：
| 领域 | 推荐技术 | 选型理由 |
|---|---|---|
| 编程语言 | Java + C++ | Java做业务层，C++做撮合核心 |
| 消息队列 | Kafka | 高吞吐、持久化、支持回溯 |
| 缓存 | Redis Cluster | 毫秒级响应，支持原子操作 |
| 数据库 | PostgreSQL + TimescaleDB | 关系型+时序数据混合存储 |
| 服务发现 | Consul | 健康检查比Eureka更可靠 |
嗯，这里要特别说一下语言选择。我见过有人用Go写撮合引擎，理由是「性能好」。但Go的GC暂停在极端情况下会达到毫秒级，这对暗池来说是不可接受的。C++虽然开发慢，但能精确控制内存布局和延迟。
选型原则总结：
- 延迟敏感部分用C++/Rust
- 业务逻辑部分用Java/Go
- 存储层优先考虑成熟方案
- 网络层必须支持零拷贝
五、架构总览图：一张图看懂暗池系统
下面这张图是我自己画的暗池系统架构总览。它展示了各层之间的交互关系，以及关键数据流。
这张图里，数据流是从上到下的。订单从接入层进来，经过业务层校验，到达核心层撮合，最终结果通过事件总线广播到清算和行情服务。每一层之间都有明确的接口契约，互不干扰。
一个小技巧：在核心层和基础设施层之间，我习惯加一层「抽象存储接口」。这样即使将来从Redis换到Memcached，核心层代码一行都不用改。
好了，暗池系统的整体架构就聊到这里。记住，架构设计没有银弹，关键是根据业务场景做取舍。下一章我们会深入撮合引擎的细节，到时候再细聊。