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

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的System B数据库非常不明智。使您的业务逻辑如此分散的做法正好相反。你最终会后悔的。

中央数据库的想法不一定是坏的......但涉及的工作量可能在从头开始重写系统的一个数量级之内。这当然不是我想要的，至少在你描述的形式中。它可以取得成功，但要比点对点集成方法更为严格，而且需要更多的训练。这听起来很有趣，与“牛仔”的做法一样，只是将数据直接推送到其他系统中。

总的来说你的直觉看起来不错。有几种方法。你提到一个：实施服务。这不是一个坏的方法，特别是如果你需要实时更新。另一个是一个单独的集成应用程序，负责混洗数据。这是我通常采用的方法，但通常是因为我无法更改要集成的系统来请求所需的数据;我必须推入数据。在您的情况下，服务方法并不是一件坏事。

有一件事我想说的是，第一次来系统集成的人可能并不明显，因为系统中的每一块数据都应该有一个真实的权威点。如果数据是重复的（并且是重复的），并且这些副本彼此不一致，则必须认为该数据的真实点的副本是正确的。没有其他方式可以整合系统，而不会让指数速度的复杂性尖叫起来。意大利面条的整合就像意大利面代码，不惜一切代价避免。

祝你好运。

编辑：

中间件解决运输的问题，但不是在集成的核心问题。如果系统足够接近以至于一个应用程序可以直接将数据推送到另一个应用程序，则它们可能足够接近以至于由另一个应用程序提供的服务可以被另一个直接调用。我不会在你的情况下推荐中间件。你可能会从中获得一些好处，但这会被复杂性增加所抵消。您需要一次解决一个问题。

Answer 2

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

我同意其他开发人员为所有不同的系统编写API过多。如果你只是建议创建一个单一的数据库，那么你可能会更快地完成它，并有更多的控制权。

Answer 3

听起来像你可能想要调查Message Queuing和message-oriented middleware。

MSMQ和Java Message Service是示例。

Answer 4

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

您必须决定的第一件事是“主数据库”将驻留的平台，以及提供所需胶水的中间件的平台。我建议你考虑面向消息的中间件，而不是进入API级中间件集成（比如CORBA）。 MS Biztalk，Sun的eGate和Oracle的Fusion可以是一些选项。

您对新数据库的想法是向正确方向迈出的一步。您可能希望阅读Enterprise Entity Aggregation模式。

将“数据集成”与中间件相结合是一种可行的方法。

Answer 5

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

我也强烈推荐迭代方法来进行整合。对于遗留系统而言，存在如此多的不确定性，试图一次性设计和实施它的风险太大。从小处着手，以一种合理的集成系统的方式工作。 “完全整合”几乎永远不值得追求。

Answer 6

如果您打算采用中间件+单一中央数据库策略，则可能需要考虑分多个阶段实现此目标。下面是它可以被认为是一个合乎逻辑的阶梯式进程：

1. 针对暴露的功能为每个系统中间件的
2. 实现其访问这些API，并提供一个接口，所有的系统不同的系统服务/ API的实现从其他系统访问数据/服务（如果可用，则访问来自中央源的数据，否则从其他系统获取数据）
3. 仅实现中央数据库，不包含数据
4. 在中间件级别实施缓存/数据存储服务它可以在中央数据库中存储/缓存数据无论何时从任何系统访问该数据，例如如果系统B通过中间件获取系统A的记录1-5，那么中间件数据高速缓存服务可以将这些记录存储在集中式数据库中，并且下一次这些记录将从中央数据库中提取出来
5. 数据清理可以在并行
6. 您还可以创建一个导入机制，推动多个系统的数据到中央数据库每天（自动或手动）

这种方式，努力在多个里程碑分布和数据逐步存储在中央数据库中首次访问第一次存储的基础上。