在ESB中实际使用的主题(队列)有多少

Question

在我看到的所有服务总线示例和教程中，它们都涉及将单个消息发布到单个侦听订阅者获取的单个主题。虽然这是一个简单的实用概述，但它并没有真正解释如何在现实世界中使用主题。

我有一个大型电子商务应用程序，它跨越许多子域，例如订单、客户和产品管理(举几个例子)，并且将使用ESB在这些不同的系统之间通信事件。我将通过主题使用Pub-Sub。

最初，我只是针对我发送的每种不同的消息类型使用一个主题，但是我可以看到这将变得难以管理，因为系统只需要发送太多类型的消息来证明1到1的消息类型是正确的。例如ProductCreate主题，ProductDelete主题。

然后，我想我可以在系统中每个集合使用一个主题。但是，由于域中的多个有界上下文，一个系统中的聚合可能与另一个系统中具有相同名称的聚合不同。所以这个实现可能会很混乱。

因此，每个无处不在的模型都有一个主题似乎是一个更好的解决方案，这可以基于用于跨服务总线转换消息的规范数据模型。这是一种常见的做法吗？还是按功能关注点来划分主题是一种更好的方法？

我可以看到，无论我选择哪种实现，都会有妥协，所以我正在寻找好的技巧、成功的历史例子和需要避免的陷阱。

Answer 1

我们面临着同样的选择/挑战。只将1种消息类型映射到ASB的主题是不实际的。但是，使其过于通用(例如在消息体中发送字符串，在任何地方使用自定义和动态序列化)也没有吸引力。

我们最终在ASB之上构建了一个轻量级的框架。它允许在使用ASB的本机序列化时，通过同一主题和所有订阅发送和接收多种类型的消息。诀窍是捕获在消息的ContentType中发送的类的类型。多个订阅客户端(每个订阅客户端都知道他们所关心的类型)将同时侦听同一主题。特定客户端只处理其类型的消息，而忽略(放弃)其他消息。我们的框架使用幕后的反射来调用消息处理程序--这是无法避免的。但是它是从依赖它的代码中抽象出来的--所有东西都是从客户端的POV中强类型的。这既适用于分区主题，也适用于非分区主题。

我还没有关于这种方法可以引入多少开销以及它对大容量消息传递系统意味着什么的数据。我们从前提应用程序开始使用ASB，其中ASB延迟首先很高。在我们完全搬到Azure之后的几个月内应该会知道更多。

顺便说一句，你不能百分之百确定“聚合”或“规范数据模型”是什么意思，但希望这能有所帮助。