好吧，在我工作的地方，在过去的几十年中，我们维护了相当数量的系统。

该系统的多样性在于，可以使用多种操作系统(Linux，Solaris，Windows)，多种数据库(oracle，sybase和mysql的多个版本)，甚至多种语言(C，C ++，JSP，PHP和许多其他语言)。用过的。

每个系统都是相当自治的，即使是以将相同数据输入到多个系统中为代价的。

管理层最近决定，我们应该研究如何使所有系统快乐地互相交谈并共享数据。

请记住，尽管我们可以对任何单个系统进行软件更改，但是完全不可能重写任何一个(或者多个)系统都是管理人员可能无法接受的事情。

这里的一些开发人员的第一个想法是简单明了：如果系统A需要系统B的数据，则它应该只连接到系统B的数据库并获取它。同样，如果需要提供B数据，则应将其插入B的数据库中。

由于使用的数据库(和版本)一团糟，其他开发人员认为我们应该有一个新的数据库，将所有其他系统中的表合并在一起，以避免麻烦多个连接。通过这样做，他们希望我们可以合并一些表并摆脱冗余数据条目。

这是我被带入对整个混乱状态发表意见的时间。

使用数据库作为系统通信手段的整个想法对我来说很可笑。必须将业务逻辑放入多个系统中(如果系统A要向系统B添加数据，则它在执行插入操作之前可以更好地理解B与数据有关的规则)，那么多个系统很可能必须进行某种形式的数据库轮询才能找到对其数据的任何更改，继续维护将是一件令人头疼的事，因为对数据库架构的任何更改现在都会传播多个系统。

我的第一个想法是花时间为不同的系统编写API /服务，一旦编写API /服务，就可以轻松地用于来回传递/检索数据。许多其他开发人员认为，这比仅仅使用数据库还要多，而且工作量大得多。

那么，使这些系统互相通信的最佳方法是什么？

解决方案

看来我们在寻求意见，所以我会提供我的意见。

我同意其他开发人员的观点，即为所有不同的系统编写API都是多余的。如果我们仅接受创建单个数据库的其他建议，则可能会更快地完成它并对其进行更多控制。

听起来我们可能想研究消息队列和面向消息的中间件。

MSMQ和Java消息服务就是示例。

集成不同的系统是我的日常工作。

如果我们是我，我将竭力避免直接从系统B中访问系统A的数据。从系统B更新系统A的数据库是极其不明智的。使业务逻辑如此分散与优良作法恰恰相反。我们最终会后悔的。

中央数据库的想法不一定很糟糕……但是所涉及的工作量可能在从头开始重写系统的数量级之内。至少在我们描述的形式中，我当然不会尝试。它可以成功，但要困难得多，而且比点对点集成方法要花更多的纪律。听到它与将数据直接推入其他系统的"牛仔"方法一样的建议，真是有趣。

总体而言，直觉似乎还不错。有两种方法。我们提到一个：实施服务。这不是一个坏方法，特别是如果我们需要实时更新。另一个是单独的集成应用程序，负责对数据进行混排。这是我通常采用的方法，但是通常是因为我无法更改要集成的系统以请求所需的数据；我必须推送数据。在情况下，服务方法不是一个坏方法。

我想说的是，对于第一次进入系统集成的人来说可能并不明显，那就是系统中的每个数据都应具有一个单一的权威性事实。如果数据是重复的(并且是重复的)，并且副本彼此不一致，则必须以该数据的真实性为准将副本视为正确。如果没有复杂性以指数级的速度飙升，没有其他方法可以集成系统。意大利面条集成就像意大利面条代码一样，应该不惜一切代价避免。

祝你好运。

编辑：

中间件解决了传输问题，但这不是集成中的中心问题。如果系统之间的距离足够近，一个应用程序可以将数据直接推送到另一个应用程序中，那么它们可能足够接近，因此一个应用程序可以直接调用另一个应用程序提供的服务。我不建议我们使用中间件。我们可能会从中获得一些好处，但是增加的复杂性将无法弥补这一点。我们需要一次解决一个问题。

通过推/拨数据库直接接口将一个系统的许多内部细节暴露给另一个系统。有明显的缺点：升级一个系统可能会破坏另一个系统。此外，在一个系统如何访问另一个系统的数据库方面可能存在技术限制(考虑在Unix上用C编写的应用程序如何与Windows 2003 Server上运行的SQL Server 2005数据库进行交互)。

我们必须决定的第一件事是"主数据库"将驻留的平台，并且与提供所需胶水的中间件相同。我建议我们不要考虑API级别的中间件集成(例如CORBA)，而应该考虑使用面向消息的中间件。可以选择MS Biztalk，Sun的eGate和Oracle的Fusion。

我们对新数据库的想法是朝正确方向迈出的一步。我们可能希望阅读一些有关企业实体聚合模式的信息。

结合使用"数据集成"和中间件是必经之路。

我们将面临的挑战之一是在每个不同的系统中对齐数据，以便首先将其集成。可能是我们要集成的每个系统都持有完全不同的数据集，但是更有可能是重叠的数据。在开始编写API：s之前(我会根据描述使用它)，建议我们尝试为需要集成的数据提出一个逻辑数据模型。然后，该数据模型将利用不同系统中拥有的数据，并使它对其他数据库更有用。

我也强烈建议采用迭代方法进行集成。对于遗留系统，存在太多不确定性，一口气尝试设计和实施它的风险太大。从小处着手，逐步构建合理的集成系统。 "完全集成"几乎是不值得追求的。

如果要采用中间件+单一中央数据库策略，则可能需要考虑分多个阶段实现这一目标。这是可以考虑的合乎逻辑的分步过程：

• 不同系统的服务/ API的实现，公开了每个系统的功能
• 中间件的实现，该中间件访问这些API并为所有系统提供接口以从其他系统访问数据/服务(如果可用，则从中央源访问数据，否则从另一个系统获取数据)
• 仅实现中央数据库，无数据
• 在中间件级别上实现高速缓存/数据存储服务，每当从任何一个系统中访问数据时，就可以在中央数据库中存储/高速缓存数据。如果系统B通过中间件获取了系统A的记录1-5，则中间件数据缓存服务可以将这些记录存储在集中式数据库中，下一次将从中央数据库中获取这些记录时
• 数据清理可以并行进行
• 我们还可以创建导入机制，每天将数据从多个系统推送到中央数据库(自动或者手动)

这样，工作量将分布在多个里程碑中，并且数据将按照先到先得的方式逐渐存储在中央数据库中。