架构误区系列 17：“总线”模式

ESB，是 SOA 年代比较流行的一个技术组件，也体现了当时非常流行的一种企业架构模式：服务总线。相对于微服务的点对点通讯，服务总线的集中式通讯模式似乎有天然的优势：

• 系统之间的交互比较“干净”，不像微服务是一种蜘蛛网的通讯和依赖。

• 比较容易做服务的治理。只需要在总线上对服务进行定义和管控就可以。

• ESB 之外的系统和系统之间似乎是“解耦”的，大家都和总线交互，彼此之间没有耦合。

但是，为什么微服务会选择点对点的通讯，为什么 ESB 会没有流行起来呢？除了非功能性上，ESB 作为一个集中式的总线，和分布式天然的价值观不合，同时也比较容易引起性能上的瓶颈之外。在功能架构上，ESB 作为一个无端出现的技术架构，没有业务领域为之背书，同时也没有任何的业务语意，这个可能是更重要的原因。

最近，在进行架构 review 的时候，就遇到了一类类似引入“总线”进行解耦的例子。

在国际业务中，我们存在两类业务：支付和兑换业务，分为两个应用由两个团队进行维护。在这两类业务中，都有部分业务是先进行交易再进行打款的“后打款”业务。这类业务在需要用户打款的时间，需要提前一天给到用户邮件提醒。原先的做法是每笔交易发一封邮件进行提醒。对用户的打扰比较大，很多用户反馈希望收到一封汇总的邮件。这就引入了一个聚合的诉求：需要将支付和兑换相关的打款提醒合并。

开发同学考虑到如果任何一方来进行这个合并，都会引起这两个系统的相互依赖。所以，一线的架构师给出的架构方案是在门户系统建设这个聚合能力。但是，这个方案被门户的 PD 拒绝了，同时我也不认为这是一个合适的方案。

我们仔细琢磨一下这方案背后的思路，就会发觉这就是 ESB 的死灰复燃。首先，门户本质上是一个没有业务含义的 Baas 系统。门户提供的沟通服务也只是一个通道：提供邮件、短信、站内信等触达用户的能力。门户不应该理解催款的业务语意。门户对于邮件服务的升级，应该集中在用户对于邮件类别的筛选、邮件延迟接收等非业务类的用户偏好能力。

对比打款提醒的聚合，是需要感知后打款业务的业务模型，包括：

• 金额；

• 打款时间；

• 超期时间等。

这些如果要聚合，需要有一个“欠款管理”中心之类有业务语意的组件来承载。有明确的领域模型，会接收各方（包括收、付、兑、贷等）的用户欠款数据，落单、提醒，并且处理用户来账对于所欠款项的平账优先级。

在这个“欠款管理”中心没有建设的规划之前，临时方案可以在付和兑中选择对于欠款感知更强烈的域（例如兑换中心）先行建设这个能力，等能力做大再独立出来。

我们要理解这个原则：基于微服务的理念，根据业务领域来切分应用（康威定律），有业务依赖的应用之间通过服务进行交互。没有业务语意不要引入新的应用，没有业务语意不要引入依赖。