在解耦系统之间同步数据的最佳方法是什么？

Question

我已经说过2（但是他们将来会变得更多）完全解耦的系统：系统A和系统B.

假设每个系统上的每条信息都有一个信息ID。没有什么能阻止信息ID在不同系统上保持一致。在所有系统中单义识别信息的是Source-informationID对。

假设我需要将一条信息从系统A导出到系统B.然后我想从系统B导出相同的信息并将其重新导入系统A，我需要能够识别出相同的信息。

在人们的经历中，这样做的最佳方式是什么？

这就是我的想法：

1. 在。之间设置消息总线 具有消息队列的系统。
2. 为每个系统设置端点 这将监视变化和 生成包含的命令 将被抽取的消息 进入队列（例如 当一条信息是 创建/删除/更新）。
3. 为端点分配排名 相对于创建/删除/更新 命令不依赖 系统名称，但仅限于一般情况 层次结构 - 使每个系统 不需要知道 他人。
4. 指定阈值 每个更新/删除/创建命令 端点，以便命令不 达到门槛要求 将被过滤掉而不是 加工

这不能解决我仍然需要携带originalSource + originalSourceID的事实。

任何帮助表示感谢。

Answer 1

正如有人已经写过的，这听起来像是一个典型的EAI问题。即使EAI工具过去昂贵，现在有各种各样的免费开源工具。下面列出了我最喜欢的那些

1. OpenESB
2. Mule
3. Apache ServiceMix
4. Apache Camel

我最喜欢的是OpenESB，我最了解它，它有一个完整的IDE（Netbeans），来自大型供应商的可选支持和huge amount of additional components。因为它的简单性和有效性，我喜欢Apache Camel，但你可以尝试其中的一些，并决定哪一个更适合你。然后你甚至可以决定为所有这些服务购买支持服务。

Answer 2

此问题已由EAI（企业应用集成）供应商解决，如Tibco和webMethods（现为Software AG的一部分）。我之前从未使用过Tibco，但我使用webMethods来解决这些问题所以我只关注web方法。例如，在企业中，有关员工的数据可以驻留在Active Directory和PeopleSoft中。 webMethods可用于确保一个系统（应用程序）中的更改，添加，删除将实时反映在另一个系统中。在其他一些组织中，有关员工的数据也可能位于Oracle或SQL Server数据库中。再次，不是问题。像webMethods这样的EAI工具可以与各种各样的后端进行通信。 webMethods不仅限于单个源和单个目标，而是因为它具有发布 - 订阅体系结构，来自单个源的数据可以流向订阅特定信息的多个感兴趣的目标。在这些产品中可以找到保证交付和其他功能。回到员工示例，最终如果做得对，在任何给定时间，企业中的所有系统和应用程序都可以包含有关员工的相同信息而没有任何差异。

因此，您不会使用C＃或Java进行编程，而是进行webMethods编程，这非常类似于4GL语言。我称它为编程因为仍然涉及逻辑，循环，如果那么其他，分支，变量，包等，但它是非常面向过程的，即根本没有OOP的概念。

这些EAI工具在构建时考虑的目的有限，其中一个目的是轻松地在企业中的不同系统之间同步数据。而且他们的工作做得很好。

缺点是这些工具需要花费很多钱。在投资这些工具之前，公司通常都有长期战略。

Answer 3

我们正在做的几乎就是A - ＆gt; B - ＆gt;你描述的一件事。我们最初考虑过让所有A，B，C等都成为同行，但这太难了，所以我们现在指定一个作为主人，其他人指奴隶。它仍然很容易从一个奴隶到另一个奴隶，但通过主人。

这一切都是通过Web服务完成的 - 数据集从slave到master，从上到下，反之亦然，slave从属运行导出，并调用master上的import。然后它告诉主人进行导出，并自行运行导入。

因此每个系统的代码都是相同的。只有奴隶才能打电话回家。

导出和导入过程告诉相关业务对象执行所有列表和保存工作，因为他们已经知道如何从DataRows实例化和保留自己。

这不是每秒数十次的交易架构，但它可以工作，并且可以实现几乎实时的同步。

顺便说一下，我们没有改进Source / Id唯一性：）

Answer 4

如果您为GUID分配每条信息，这将大大简化。如果您需要跟踪来源和其他ID，那很好，但信息shuold总是随其指定的GUID一起旅行。

当机器再次看到该信息时，它会看到GUID并将其与现有数据相关联，然后您就可以决定要做什么了。但是你已经知道它是相同的数据 - 只是更好的旅行。

请记住，GUID的创建方式是每台计算机都会创建自己的GUID，并且它们不会与在另一台计算机上创建的GUID或不同的计算机上的GUID冲突（对于所有实际意图和目的）时间。

这是创建GUID的更大原因之一。

- 亚当

Answer 5

除非在系统设计中存在某些特定限制，否则我建议将共享/可共享信息分解为一个单独的数据库，其他两个数据库可以引用或仅在本地复制。那么你不需要双元素密钥，也不需要任何复杂的ESB装置......