总线架构设计原则：单一职责、接口隔离、依赖倒置

做低延迟回测系统，总线设计是核心中的核心。我见过太多团队，一上来就堆功能，结果总线变成了一个大杂烩——数据流、控制流、状态同步全塞在一起。跑起来倒是能跑，但延迟一上去，定位问题能让你怀疑人生。

今天咱们聊聊三个设计原则。这三个原则，说白了就是让总线变得「好拆、好改、好调」。我自己的经验是，只要把这三点想清楚，总线架构基本不会出大乱子。

单一职责原则：总线只做一件事

单一职责原则（SRP）听起来简单：一个模块只负责一件事。但在总线设计里，很多人会跑偏。

举个例子。有人把数据总线设计成既能传行情，又能传订单，还能传日志。嗯，看着挺全能。但你想过没有？行情数据要求极低延迟，订单数据要求强一致性，日志数据要求高吞吐。三种需求混在一起，总线调度策略怎么写？

我在项目中遇到过这样一个坑：某团队把行情预处理逻辑直接塞到了总线接收回调里。结果行情波动一大，总线处理不过来，订单数据也跟着卡顿。后来拆出来一个独立的预处理模块，问题就解决了。

具体怎么做？我建议这样划分职责：

• 数据总线：只做数据搬运，不做任何业务处理
• 预处理模块：负责数据清洗、格式转换
• 策略引擎：负责信号生成、订单管理
• 风控模块：负责合规检查、限额控制

每个模块各司其职，总线只关心一件事——把数据从A点送到B点，越快越好。

接口隔离原则：别让消费者看到不该看的东西

接口隔离原则（ISP）在总线设计里特别实用。说白了就是：你给不同消费者提供的接口，应该是不一样的。

举个例子。策略模块只需要订阅行情数据，它不应该看到订单路由的接口。风控模块需要监控所有数据流，但它不应该能修改数据内容。

为什么会这样？因为接口暴露得越多，耦合就越深。耦合一深，改一个地方就得动一片。在低延迟系统里，这种「牵一发而动全身」的情况是致命的。

我曾经在一个项目里，把总线接口设计成了一个大而全的 BusAPI，里面包含了订阅、发送、查询、管理、监控等几十个方法。结果呢？每个模块都依赖这个庞然大物，改一个方法就要重新编译所有模块。后来拆成 DataSubscriber、OrderSender、BusMonitor 三个小接口，编译时间从5分钟降到了30秒。

接口隔离还有个好处：方便测试。每个模块只需要 mock 它依赖的那几个接口，不用搞一个巨大的 mock 对象。

依赖倒置原则：面向接口编程，别面向实现

依赖倒置原则（DIP）可能是这三个原则里最容易被忽视的。它的核心思想是：高层模块不应该依赖低层模块，两者都应该依赖抽象接口。

在总线设计里，这意味着什么？

意味着你的策略代码不应该直接依赖某个具体的消息队列实现（比如 Kafka 或 ZeroMQ）。它应该依赖一个抽象的 MessageBus 接口。至于底层是用共享内存、TCP 还是 RDMA，那是总线实现的事。

// 不好的设计：直接依赖具体实现
class Strategy {
    private KafkaBus bus;  // 耦合了Kafka
}

// 好的设计：依赖抽象接口
class Strategy {
    private MessageBus bus;  // 只依赖接口
}

这样做的好处很明显：换底层实现的时候，策略代码一行都不用改。我见过一个团队，从 Kafka 切到 Aerospike 做事件总线，因为接口抽象得好，只花了半天就完成了切换。

三个原则如何协同工作？

这三个原则不是孤立的。它们配合起来，效果是1+1+1>3。

我画了一张图，展示它们之间的关系：

你看，这三个原则是层层递进的。单一职责让你把总线拆成独立模块；接口隔离让你给每个模块只暴露必要接口；依赖倒置让你面向抽象编程，换实现不换逻辑。

在实际项目中，我通常这样落地：

1. 先画职责边界：明确总线该做什么、不该做什么
2. 再定义接口：给每个消费者画一个「最小接口」
3. 最后做抽象：把可能变化的部分抽象成接口

顺序别搞反。我见过有人一上来就搞抽象，结果抽象了半天，连总线该干什么都没想清楚。嗯，那是浪费时间。

好了，这一章就聊到这儿。这三个原则看着简单，但真正用好需要反复实践。下次你设计总线的时候，不妨拿这三条来对照一下，看看有没有违反的地方。相信我，你会发现自己之前踩了不少坑。

公众号:蓝海资料掘金营，微信deep3321