9

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

这些系统多种多样，包括多种操作系统（Linux、Solaris、Windows）、多种数据库（Oracle、sybase 和 mysql 的多个版本），甚至多种语言（C、C++、JSP、PHP 和许多其他语言）用过的。

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

管理层最近决定，我们应该调查如何让所有系统愉快地相互交谈和共享数据。

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

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

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

这大约是我被请来对整个混乱发表意见的时候了。

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

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

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

4

6 回答 6

8

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

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

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

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

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

祝你好运。

编辑：

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

于 2008-09-25T15:39:56.447 回答
4

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

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

于 2008-09-25T15:24:27.250 回答
0

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

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

于 2008-09-25T15:22:45.553 回答
0

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

您必须决定的第一件事是“主数据库”将驻留的平台，对于提供急需粘合剂的中间件也是如此。我建议您考虑使用面向消息的中间件，而不是采用 API 级别的中间件集成（例如 CORBA）。MS Biztalk、Sun 的 eGate 和 Oracle 的 Fusion 可以是其中的一些选项。

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

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

于 2008-11-03T13:31:25.483 回答
0

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

我还强烈推荐一种迭代的集成方法。遗留系统存在如此多的不确定性，以至于试图一次性设计和实施它的风险太大。从小处着手，逐步实现合理集成的系统。“完全集成”几乎不值得追求。

于 2008-11-03T13:45:28.093 回答
0

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

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

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

于 2008-11-04T17:59:01.653 回答