如何最好地集成多个系统？

Question

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

系统的多样性包括多个操作系统（Linux，Solaris，Windows），多个数据库（oracle，sybase和mysql的几个版本），甚至多种语言（C，C ++，JSP，PHP和主机）其他）使用。

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

管理层最近决定我们应该调查让所有系统愉快地互相交流和共享数据所需的内容。

请记住，虽然我们可以对任何单个系统进行软件更改，但完全重写任何一个系统（或更多）都不是管理层可能会接受的。

这里的几个开发人员的第一个想法是直截了当：如果系统A需要来自系统B的数据，它应该只连接到系统B的数据库并获得它。同样，如果需要提供B数据，则应将其插入B的数据库中。

由于使用的数据库（和版本）混乱，其他开发人员认为我们应该有一个新的数据库，结合来自所有其他系统的表，以避免不得不兼顾多个连接。通过这样做，他们希望我们能够整合一些表并摆脱冗余数据输入。

这是关于我对整个烂摊子的看法。

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

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

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

Answer 1

整合不同的系统是我的日常工作。

如果我是你，我会尽力避免直接在系统B中访问系统A的数据。更新系统A的系统数据库是非常不明智的。与使业务逻辑如此分散的良好实践完全相反。你最后会后悔的。

中央数据库的想法并不一定很糟糕......但所涉及的工作量可能在一定程度上从头开始重写系统。这肯定不是我想要的，至少在你描述的形式。它可以成功，但它更加困难，并且比点对点集成方法需要更多的纪律。很有趣的是听到它与“牛仔”方法一样，只是将数据直接推送到其他系统中。

总的来说，你的直觉似乎很好。有几种方法。你提到一个：实施服务。这不是一个糟糕的方式，特别是如果您需要实时更新。另一个是一个单独的集成应用程序，负责改组数据。这是我通常采用的方法，但通常是因为我无法更改我正在集成的系统以询问所需的数据;我必须推送数据。在你的情况下，服务方法并不坏。

我想说的一件事情，对于第一次参加系统集成的人来说可能并不明显，系统中的每一段数据都应该具有单一的，权威的真实点。如果数据是重复的（并且是重复的），并且副本彼此不一致，则必须认为该数据的真实点的副本是正确的。没有其他方法可以在没有复杂性尖叫的情况下以指数速率整合系统。 Spaghetti集成就像意大利面条代码，应该不惜一切代价避免它。

祝你好运。

编辑：

中间件解决了传输问题，但这不是集成中的核心问题。如果系统足够接近，一个应用程序可以直接将数据推送到另一个应用程序，它们可能足够接近，一个服务提供的服务可以由另一个直接调用。在你的情况下，我不建议使用中间件。您可能会从中获益，但复杂性会增加。你需要一次解决一个问题。

Answer 2

听起来您可能想要调查消息队列和面向消息的中间件。

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

Answer 3

看来你正在寻找意见，所以我会提供我的意见。

我同意其他开发人员认为为所有不同系统编写API过多。如果您只是采用创建单个数据库的其他建议，您可能会更快地完成它并对其进行更多控制。

Answer 4

您将面临的挑战之一是对齐每个不同系统中的数据，以便首先将其集成。可能是您要集成的每个系统都拥有完全不同的数据集，但更可能是重叠的数据。在深入编写API：s（这是我将采取的描述的路线）之前，我建议您尝试为需要集成的数据提供逻辑数据模型。这个数据模型将帮助您利用您在不同系统中拥有的数据，并使其对其他数据库更有用。

我还强烈建议采用迭代方法进行整合。对于遗留系统而言，存在很大的不确定性，试图一次性设计和实现它的风险太大。从小处着手，一路走向合理集成的系统。 “完全整合”几乎没有值得瞄准的目标。

Answer 5

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

您必须首先决定的是“主数据库”平台。将驻留，并为中间件提供所需的胶水。我建议您考虑使用面向消息的中间件，而不是采用API级别的中间件集成（例如CORBA）。 MS Biztalk，Sun的eGate和Oracle的Fusion可以作为一些选择。

您对新数据库的想法是朝着正确方向迈出的一步。您可能希望阅读企业实体聚合模式。

“数据集成”的组合。使用中间件是可行的方法。

Answer 6

如果您要使用中间件+单中心数据库策略，您可能需要考虑在多个阶段实现此目标。这是一个逻辑分步过程，可以考虑：

1. 为不同系统实施服务/ API，公开每个系统的功能
2. 访问这些API的中间件的实现，并为所有系统提供接口以访问来自其他系统的数据/服务（如果可用，则从中央源访问数据，否则从其他系统获取）
3. 仅实施中央数据库，无数据
4. 在中间件级别实施缓存/数据存储服务，只要从任何系统访问数据，就可以将数据存储/缓存在中央数据库中。如果系统A的记录1-5由系统B通过中间件提取，则中间件数据缓存服务可以将这些记录存储在集中式数据库中，并在下次从中央数据库中提取这些记录时
5. 数据清理可以并行发生
6. 您还可以创建导入机制，每天将数据从多个系统推送到中央数据库（自动或手动）

这样，工作分布在多个里程碑上，数据逐渐存储在首先访问的中央数据库中。