legacy-code - 如何最好地集成几个系统？

Question

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

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

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

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

请记住，尽管我们可以对任何单个系统进行软件更改，但是完全不可能对任何一个(或多个)系统进行完全重写。

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

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

这是关于我被带入对整个困惑状况发表意见的时间。

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

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

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

Answer 1

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

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

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

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

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

祝你好运。

编辑:

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