如何最好地集成多個系統？

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. 您還可以創建一個導入機制，推動多個系統的數據到中央數據庫每天（自動或手動）

這種方式，努力在多個里程碑分佈和數據逐步存儲在中央數據庫中首次訪問第一次存儲的基礎上。