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

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

如果我是你,我会尽最大努力避免直接从系统B访问系统A的数据。 更新 系统A的数据库来自系统B是非常不明智的。使您的业务逻辑如此分散恰恰与良好实践相反。你会后悔的。

中央数据库的概念并不一定是坏的…但是所涉及的工作量可能在从头重写系统的数量级之内。这肯定不是我想尝试的,至少以你描述的形式。它可以成功,但比点对点集成方法更困难,需要更多的规则。很有趣的是,听到它和“牛仔式”的直接将数据推送到其他系统的方法是一样的。

总的来说,你的直觉很好。有几种方法。您提到一个:实现服务。这不是一个糟糕的方法,特别是如果你需要实时更新。另一个是一个单独的集成应用程序,负责处理周围的数据。这是我通常采用的方法,但通常是因为我无法更改正在集成的系统来请求它所需的数据;我必须将数据推入。在您的案例中,服务方法并不糟糕。

我想说的一件事,对于第一次进入系统集成的人来说,可能并不明显,那就是系统中的每一个数据都应该有一个单一的、权威的事实点。如果数据是重复的(并且是重复的),并且副本之间不一致,那么必须将数据的真实副本视为正确副本。如果没有复杂度以指数级的速度向上尖叫,就没有其他方法可以集成系统。意大利面集成就像意大利面代码,应该不惜一切代价避免。

祝你好运。

编辑:

中间件解决了传输问题,但这不是集成中的核心问题。如果系统之间的距离足够近,一个应用程序可以直接将数据推送到另一个应用程序,那么它们之间的距离可能足够近,一个应用程序提供的服务可以由另一个应用程序直接调用。在您的案例中,我不推荐中间件。您可能会从中获得一些好处,但这将被日益增加的复杂性所抵消。你需要一次解决一个问题。

听起来你可能想调查一下 Message Queuing 和 message-oriented middleware .

MSMQ 和 Java Message Service 就是例子。

看来你在征求意见,所以我会提供我的意见。

我同意其他开发人员的观点,即为所有不同的系统编写API是多余的。如果采纳创建单个数据库的其他建议,您可能会更快地完成任务,并对其拥有更多的控制权。

您将面临的一个挑战是将每个不同系统中的数据对齐,以便在第一时间将其集成。可能是要集成的每个系统都包含完全不同的数据集,但更可能是重叠的数据。在开始编写api:s(这是我将采用的路线,并给出您的描述)之前,我建议您尝试为需要集成的数据建立一个逻辑数据模型。然后,此数据模型将帮助您利用不同系统中的数据,使其对其他数据库更有用。

我还强烈推荐一种迭代的集成方法。对于遗留系统来说,存在着太多的不确定性,试图一次性设计和实现这些系统太冒险了。从小处做起,努力建立一个合理集成的系统。”“完全整合”几乎不值得瞄准。

通过推/戳数据库直接接口将一个系统的许多内部细节暴露给另一个系统。有明显的缺点:升级一个系统会破坏另一个系统。此外,在一个系统如何访问另一个系统的数据库方面可能存在技术限制(考虑在UNIX上用C编写的应用程序如何与在Windows2003服务器上运行的SQL Server2005数据库交互)。

首先你要决定的是“master数据库”将驻留在哪个平台上,对于提供非常需要的粘合的中间件也是如此。我建议您考虑使用面向消息的中间件,而不是使用API级中间件集成(如CORBA)。Biztalk女士、Sun的Egate和Oracle的Fusion是其中的一些选择。

您对新数据库的想法是朝着正确的方向迈出的一步。你可能想读点关于 Enterprise Entity Aggregation 模式。

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

如果您打算采用中间件+单中心数据库策略,您可能需要考虑在多个阶段实现这一点。这是一个逻辑步骤,可以考虑:

1. 为不同的系统实现服务/API,这些系统公开每个系统的功能
2. 中间件的实现,它访问这些API并向所有系统提供接口,以便从其他系统访问数据/服务(如果可用,从中心源访问数据,否则从其他系统获取数据)
3. 仅实现中央数据库,无数据
4. 中间件级缓存/数据存储服务的实现,当从任何系统访问数据时,可以将数据存储/缓存在中央数据库中,例如,如果系统A的记录1-5是由系统B通过中间件获取的,中间件数据缓存服务可以将这些记录存储在中央数据库和下次从中央数据库中提取这些记录时
5. 数据清理可以并行进行
6. 您还可以创建导入机制,每天将数据从多个系统推送到中央数据库(自动或手动)

通过这种方式,工作分布在多个里程碑上,数据在第一次访问第一次存储的基础上逐渐存储在中央数据库中。