使用服务总线架构在不同系统之间关联/映射实体的方法有哪些？

Question

我正在研究在我们的企业中使用服务总线架构来协调环境中系统之间的数据和业务流程。

我们的情况很典型：面向客户的Web应用程序将消息传递到内部系统以进行计费，库存等。我们在大多数或所有这些系统中都有几个常见的业务实体;这些系统中的每一个都在自己的数据库中维护这些实体的版本。

应用于服务总线概念，我们可以从代表订单的客户门户网站向总线发布消息。每个感兴趣的系统（计费，库存等）都可以使用此消息，以在其自己的数据库中创建相应的客户记录。但是，当其中一个内部系统需要发布有关订单状态的消息时，它将从其自己的数据库中携带订单ID。如果我们的门户网站需要使用该消息，则它不知道如何将从内部系统发送给它的订单ID与保存到门户网站数据库的订单ID相关联。

由于没有其他系统本身知道等效实体如何跨系统相关，因此似乎需要某种类型的映射机制来允许系统将消息中包含的ID转换为与其相关的ID。例如，可以创建一个数据库表，将ID从一个系统映射到另一个系统。可以查询此表以检索目标系统的适当ID。我们的业务目前不利用实体聚合或其他“360视图”类型存储库作为公共实体信息的单一权威来源，通用ID可以在所有系统之间传递和使用。

是否正在使用这种实体映射方法来配合服务总线实现一种有效的方法？如果是这样，是否有指导设计的既定指南？如果没有，我有兴趣了解跨系统链接实体的替代方法，以促进通过服务总线的集成。

PS：如果有帮助，我目前正在评估用于构建公交车的MassTransit框架，所以如果有特定信息提供给它，那也非常受欢迎。

Answer 1

如果没有更多细节，我会考虑一种类似于这样的方法......

1. 网站发布SubmitNewOrder消息
2. MiddleManager服务将获取SubmitNewOrder消息并将其转换为每个系统的任务;通过该转换，您可以进行ID翻译
3. 每个系统都有一个端点，它会使用正确的消息/命令并采取相应的行动

所以这里的一些事情是发送命令而不是发送你的实体。现在您可以发送实体的子集（这是从实体中提取接口并组成消息类型的好时机）。从高层次来看，这似乎是解决这个问题的一种完全有效的方法。

如果您想更深入地了解这一点，Enterprise Service Bus: Theory in Practice是一本很棒的书。它与MassTransit没有任何关系，但许多理论都适用并奠定了良好的基础。

Answer 2

我在现在的公司做了很多类似的工作。我来自C＃背景，并且是服务总线概念的新手。我一直在研究的项目主要是Java，所以我们最终选择了Mule ESB作为我们的解决方案。我强烈推荐它，但我意识到它可能不会与.NET代码一起开箱即用。

问题：如何跨系统管理实体？

我们目前有两种类型的实体。那些存在于一个权威系统中并被复制到其他系统的实体，以及跨系统共享的实体。

当一个实体来自一个系统时，我发现最好跨系统创建该实体的副本。服务总线将提取数据，对其进行转换，然后将其加载到适当的系统中。源和目标具有固定的实体数据格式，服务总线执行转换。这对我们来说非常有效。

对于共享实体，它有点棘手。我们允许部分更改（一个系统修改5个属性/字段，另一个系统管理另外3个属性/字段）到目前为止工作正常。我们试图最小化共享实体，因为存在数据不一致的风险。 （例如，“为什么这个实体看起来很奇怪？哦，是的，有些系统修改了状态字段，我忘了它可以做到这一点。”）

使用队列

我们使用ActiveMQ和主题的概念将数据从系统发送到系统。主题类似于队列，但许多订阅者可以监听主题。例如，我们有一个内部CMS，可以生成文章实体。当用户发布文章时，它会转到ActiveMQ主题。

然后，服务总线可以有许多正在观看该主题的听众。每个监听器都会获得自己的实体副本。然后每个监听器也可以进行自己的转换，然后将副本发送到适当的系统。

事实证明，它很容易理解/编码/测试/维护。

拥有地图数据库

令我遗憾的是，我最近通过将值硬编码到脚本中来完成此操作。实际上我写了一个工具为我生成代码，但它仍然在脚本文件中。原因是我们进行了大量的批处理，我们将大量的消息发送到服务总线上。每次消息必须通过时，我都不想付出代价来进行数据库查找。

所以我的工具生成一个脚本来管理实体的映射/协调，而且速度非常快。如果进行了更改，我只需重新运行该工具，即可开始使用新脚本。我的映射信息变化非常非常慢，所以没关系。

但是，如果您可以制作具有实体映射的数据存储（XML，数据库，平面文件等），我认为这很好。

一般建议

进行大量服务总线工作的一些提示：

1. 服务总线不是银弹。根据我的经验，当您拥有各种各样的技术时，它最有效。例如，我们有MySQL，SQL Server，ActiveMQ，Mongo，CouchDb，弹性搜索等。

2. 我不知道公共交通是如何运作的，但是Mule有流量的概念。流是从A点到B点的一个概念数据流。您可以拥有多个流。我会尽力使这些非常简单。它使测试变得更加容易。由于它是集成工作，因此调试并不容易，因此我更倾向于采用任何复杂性。

3. 尝试让实体尽可能靠近目的地。换句话说，如果我从.NET Web服务获取数据并将其写入SQL，我希望该对象在完全转换的90％的路径上进入服务总线。这再次使服务总线逻辑变得简单。