究竟要不要ESB？

最近遇到乙個it專案，由於專案前期已經做了一些工作，系統功能被分散到了各個預先定義好的子系統中，後面接手的設計師根據這一現實，以及專案中需要用到一些業務流程，堅持要用esb來整合這些子系統。

一定要用esb嗎？

究竟esb是什麼，適用於什麼開發場景？我們不得不回到最初的問題。

esb是什麼？

esb 是一種體系結構模式，而不是軟體產品。不同的軟體產品可以構成 esb。在某些情況下，公司在不同的區域中使用多種產品，利用特定的功能來滿足其獨特的需求。可以將這些不同的產品聯合在一起實現 esb 模式。

概括地講，esb 具有四個主要功能：

在給定的事務中，通常會合併這些主要高階功能。例如，傳入訊息可能是乙個使用 soap/http 的 web 服務呼叫，而目的地是需要使用 websphere mq 的固定長度訊息格式的遺留系統。必須轉換訊息、協調協議並且必須將訊息路由到正確的位置。

對 esb 程式設計通常涉及虛擬環境，並將邏輯表示為稱為訊息流或中介流的連線活動流。這些流都是事務型的，使用的是兩階段提交之類的機制，這樣在失敗時可以回滾整個流，或者在成功時提交整個流。這些流是無狀態的；通常情況下是訊息傳入，流對該訊息執行各種操作，然後傳送傳出訊息。

由於 esb 的無狀態事務特性，因此高效能是前提條件。在大型組織中，esb 每天處理數百萬條訊息的情況並不少見。

esb的優點

esb 的主要優點之一就是處理訊息。訊息的傳入和傳出也許會用到協議或格式中介。當這些需求明顯需要處理訊息時，使用 esb 可以提供許多優勢，其中包括在轉換中處理較複雜事務的能力。當這些需求需要使用 esb 基本功能（如訊息路由、轉換或協議中介）之一時，則 esb 是最佳選擇。

esb 的另乙個優點是效能。esb 在計畫上能夠處理大量的訊息。例如，如果需求是每天處理 200,000 條訊息，則 esb 顯然是較好的選擇。

如果需求是以資料為中心的，則顯然要選擇 esb。

需要思考的問題

就我們這個專案而言，沒有遺留系統，所有子系統間的邊界、訊息可以重新定義和設計（原有設計中有很多不合理之處）。首先可以通過資料整合、重新劃分業務的方式，減少子系統的數量。其次，通過把子系統間交換的資訊定義標準化來解決子系統間整合的問題。根本沒有必要一定要使用esb，這是典型的過度設計。