2

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

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

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

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

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

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

4

2 回答 2

1

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

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

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

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

于 2013-01-24T12:33:00.617 回答
0

我在现在的公司做过很多类似的工作。我来自 C# 背景，对服务总线的概念很陌生。我一直在从事的项目主要使用 Java，所以我们最终选择了 Mule ESB 作为我们的解决方案。我强烈推荐它，但我意识到它可能无法与 .NET 代码一样开箱即用。

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

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

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

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

使用队列

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

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

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

拥有地图数据库

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

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

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

一般建议

做大量服务总线工作的一些技巧：

  1. 服务巴士不是灵丹妙药。根据我的经验，当您拥有多种技术时，它的效果最好。例如，我们有 MySQL、SQL Server、ActiveMQ、Mongo、CouchDb、Elastic Search 等。

  2. 我不知道公共交通是如何运作的，但骡子有流动的概念。流是从 A 点到 B 点的一种概念数据流。您可以有许多流。我尽我所能使这些非常简单。它使测试变得相当容易。由于它是集成工作，因此调试起来并不容易，因此我更愿意消除任何复杂性。

  3. 尝试让实体在源头尽可能靠近目的地。换句话说，如果我从 .NET Web 服务获取数据并将其写入 SQL，我希望对象在 90% 的情况下进入服务总线以实现完全转换。这再次使服务总线逻辑保持简单。

于 2013-01-24T05:38:09.010 回答