1、本文講述了ESB架構在企業內的實際運用，包括在部門內、部門間以及企業級ESB架構的設計和案例；分享了ESB設計過程需要考慮的關鍵問題；描述了不同ESB域的實施重心。概述ESB的存在主要是為了整合企業內部的應用，使企業內的應用能融為一體，而不是成為一個個信息孤島。可以說ESB是企業內所有服務的中心點，其它系統間的交互都需要通過ESB來完成。為此，它需擁有如下質量屬性：可用性、性能、可修改性、可測試性、易用性。參考“ESB的質量屬性”一節。為了解釋這些架構屬性，我們可以從企業域、部門域、ESB內部視角三個層次來進行說明。ESB除了高可用性和性能之外，高可伸縮性也很重要，在實際實施過程中，讀者可以對

2、整個結構進行裁減，在開始時，可能只需要一個部門域，部門域內支持水平擴展。當達到瓶頸之后，則可能需要部署到多個部門域，這樣就可以擴展出多個水平擴展的節點，減少單個節點的職責。ESB的質量屬性可用性ESB是企業內應用之間及對外第三方系統之間交互的集中點，它集中管理了交互的所有服務。它還提供服務查找、管理、審計、監控、分析等功能。當ESB服務出現故障，就將會影響企業內所有應用的正常運行。所以，可用被性放在了第一位。性能隨著企業內部整合的推進，ESB內部的服務交易量應該不會少，高性能對于ESB來說也是非常重要的?？尚薷男砸驗镾OA的企業治理是一個循序漸進的過程，在ESB部署之初，很難準確估計未來的交易

3、量，所以，對性能的擴展性要求也比較高。在實際的生產運維過程中，我們還是會常常發現，服務可能會出現這樣或那樣的問題。為了不影響服務消費者對服務的正常使用，快速的修改和部署，是一個很重要的問題。ESB項目是隨著SOA治理的發展而一次次迭代的，這也就要求了很高的可修改性?？蓽y試性ESB上線既然是一個迭代的過程，服務會根據SOA理念的深入而增多。在迭代過程中，要保證以前的服務能順利通過測試，可測試性是一個很重要的保障。企業內的應用應該只需面向ESB，它們交互時并不需要知道這個服務位于哪里或是誰在使用該服務。這時，ESB測試就是一個很大的問題，因為當一筆交易開始的時候，你可能并不知道它會在哪里，但我們卻

4、要保證這筆交易是正確的，這樣才能保持服務的正確性。易用性實現易用性需要提高服務的開發效率，即能快速開發和部署服務。因為它對生產上的活動沒有影響，所以將它放在末尾。企業域視圖在大多數據情況下，如果交易量不大，你大可以只使用一個部門域來支撐整個企業內的服務。但如果只是一個ESB的部門域的話，是沒有辦法支撐后來交易量的逐年增長的。雖然每一個部門域都可以自行進行水平的擴展，但這還是有一個度的，超過這個度后，水平擴展的難度就會提高，此時可能需要在業務上進行垂直拆分，這種方式當然沒有水平擴展來得廉價，但它能更容易的支撐更大的業務量。在企業域中，最大的特點就是有多個部門子域（圖2.1），每個部門子域都是高度

5、自治的。它們可以獨立地處理域內各個系統的整合，只有當需要使用其他域中的服務時，才會請求其它的域。為了防止部門域之間變成一個蜘蛛網，這里我們引入了企業域管理器，來統一管理域內的服務與及對這些部門域進行必要的監控。在企業域管理器中主要有以下的幾個組件：· 企業服務查找注冊組件：這個組件一般情況下是獨立部署的，而且應該有很高的可用性，在理想狀態下，應該可以查找到所有部門域中的所有交易?？缬虻慕灰锥夹枰ㄟ^這個組件來查找到對應域的服務。· 監控組件：這個組件可以查看各個部門域的運行情況。圖 2.1元素企業域管理器企業服務查找注冊組件這個是企業域管理器的核心組件，使用它來管理企業內的

6、所有服務，這個組件應該有以下幾個功能。· 服務注冊：注冊服務地址、服務描述及服務規約。· 服務版本管理：管理服務的多個版本。· 服務客戶端代碼的生成：根據服務地址及說明生成服務客戶端，在我們的實施中，一般為java 版本。· 服務路由表的查找：主要作用是查找對應的服務地址，而且可以推送給服務路由器。· 服務的使用方注冊：要調用服務，就必須到注冊組件中進行注冊，沒有注冊的使用方不允許進行服務的調用。這樣就可以通過此組件找到此服務的使用路徑，從而當服務進行更改后，可以有效的通知相應的服務使用方。監控組件這個組件可以查看各個部門域內的運行情況，并在部

7、門域的運行超過閥值時發出預警。必要時，操作域內流控組件。具體的功能如下：· 查看各個部門域的運行情況。如硬件資源、交易信息、流控信息和配置信息。· 對資源使用情況進行預警。· 根據情況操作部門域內的配置參數，比如流控的配置參數。· 操作域內的流控組件，保證重要交易，放棄次要交易。· 定時收集各個域內的信息。信息保存之后，為報表、決策分析等提供信息支持。部門域部門域是企業內的一個個ESB節點，每個部門域內會根據項目群，或者根據部門來進行劃分，在各個部門域內都有一個ESB組件，通過這個ESB來整合部門內的服務及應用。這個組件我們將會在部門域的視角中

8、詳細描述。場景子域間交互所有服務都會注冊到企業管理器的服務查找組件中，這個組件擁這些服務的描述及地址信息。圖2.2描述了一個流程示例，部門域A如果要發起一個跨域的服務請求，就必須要使用企業域管理器的服務查找組件，通過這個組件的路由表獲取此服務提供者所在的部門域B的服務地址后，才能請求對應的服務。為了提高性能，在這個場景里，也可以在啟動的時就獲取所有路由信息，并緩存起來，服務請求時通過緩存來找到部門域B的地址。在這里有一點需要注意，當部門域改變了服務地址之后的通知機制，我們的實施中有下以幾種策略：· 服務查找組件進行推送· 如果服務請求地址出錯，重新請求服務查找組件·

9、; 定時清空路由緩存 圖 2.2部門域視圖部門域是企業ESB實施的基本組成單元，在一定交易量范圍內，它甚至可以獨立存在于企業內。部門域ESB可以獨立地進行水平擴展，以進行性能的伸縮，而且，這種性能的伸縮在一定程度上應該是相對廉價的。在部門域的視角，我們不用關心ESB的內部實現，在一般情況下，只有以下四個場景· 同步請求服務· 異步請求服務· 同步提供服務· 異步提供服務同一域內的系統只需要知道以上四種場景就足夠了，其它工作會在ESB內部進行整合。比如，與某個遺留系統的交易，ESB會通過適配器與之整合，我們會在ESB內部視圖進行闡述這一內容。部門域內主要涉

10、及多種應用系統和ESB兩種元素（圖3.1），所有應用系統之間的交互都要經過ESB，它們是星型拓撲結構，所以，ESB成了一個單點故障點，出了問題會影響到整個部門域的各個子系統，這也是為什么在ESB的系統中可用性的質量屬性如此重要的原因。圖 3.1元素ESB組件ESB組件是核心，這個元素內部的功能將在ESB內部視圖中詳細闡述。它位于部門域內，其主要作用是：· 減少各應用間的依賴：ESB最大的好處是可以把蜘蛛網結構的依賴關系理順，使各個應用只依賴于ESB。· 整合現有應用：ESB可以通過自身的一些技術組件，對現有的應用進行協議轉換，讓現有的應用能快速融入到企業整合的大環境中，不至

11、于形成一個個的信息孤島。· 流控：保證高優先級服務的高可用性。域內應用系統域內應用系統是企業內部信息/服務的實際提供者和消費者，當它需要為其它消費者提供信息/服務，或者要消費其它系統的信息/服務時，就會和ESB產生關系。企業外系統當今企業大多會與企業外部系統產生關系。我們不應在應用系統內部直接和外部的系統產生關系，這樣會耗費更多的時間在安全管理上，而且很多時候這些外系統并不是只有一個應用在使用。此時，不但會增加了單個應用系統的復雜度，而且還會出現一些冗余。我們完全可以通過ESB來統一完成這些工作，簡化應用系統消費服務的過程。BPMBPM系統實際上是應用系統的一部分，把BPM獨立出來進

12、行管理，是因為BPM在ESB架構中占有比較大的成分。在ESB實際實施過程中，我們可以使用ESB內部的各種路由和端點的組合實現一定程度上的的BPM功能，但這樣實際上會復雜化ESB。如果能使用BPM產品來做這個交易的流程編排，就能減化ESB內部的復雜性。如果應用系統中沒有BPM這類的應用系統，如果可能的話，我們最好能使在企業域中加入一個BPM組件來實現業務流程。此時，ESB需要能很好地與BPM應用系統進行交互。場景在以下場景中，一次請求實際上會通過兩個或更多的組件，之所以會這樣，是因為ESB會屏蔽ESB的請求方和服務方的細節，當系統要與外部系統進行交互時，只應知道ESB這個系統。這也是為什么可測試

13、性在ESB系統很重要的原因。在ESB系統中，整合測試是非常重要的。在同異步服務提供的場景下，因為交易的請求方只知道ESB，或者有時候根本沒有請求方，在這種場景下的測試就顯得非常重要了，ESB不但要滿足技術上的測試功能，還要和服務方一起完成業務測試，這樣才能保證這筆交易的正確性。同步請求下圖是一個最簡單的應用場景（圖 3.2），在這個場景中ESB只做交易轉發，當然中間也可能做了報文轉換的工作。這一切應該在部門級視角上看應該透明的，在部門域內服務的使用者只需要依賴ESB提供的服務接口，而不需要依賴服務的最終實現。此處的細節會在ESB的內部視角中進行闡述。 圖 3.2異步請求如果服務不能在短時間能完

14、成操作，就不應該使用同步請求，而應該使用異步請求。當該服務完成操作后，再回調一個方法來獲取處理結果，當然，也可能不需要返回結果。 圖 3.3同步提供服務 圖 3.4異步提供服務 圖 3.5ESB內部視圖靜態看ESB系統，它主要由三部分組成（圖 4.1）· 端點（Endpoint）：它的職責可分為兩部分，一部分是接收服務請求，另一部分是調用服務提供者· 路由器（Router）：主要是消息的路由。當端點接收到一個請求后，會交由路由器來選擇相應的消息服務方。· 基礎組件：支持通用ESB模式的通用組件。圖 4.1從動態地看ESB系統，你會發現，我們可以將ESB內部看作一個

15、個有組織的消息通道（圖 4.2），客戶端請求ESB時選擇一個相應的消息通道。在這個消息通道中，會有很多的消息處理器，它們根據處理器自己的職責對消息流進行相應的處理。圖 4.2元素消息處理通道消息處理通道是ESB架構的核心部分，ESB核心的消息處理器分為兩部分，一部分是路由處理器，一部分是端點處理器。當然，我們的基礎組件也會適時地在兩個處理器中間，攔截加入多個基礎組件處理器。例如，日志組件會加入日志處理器，以記錄ESB運行的日志。圖 4.2中描述的是一個簡單通道，在這個通道中沒有分支，路由處理器也只有一個，在實際使用過程中當然沒有這么簡單，路由處理器可能有多個，Endpoint也可能有多個。當整

16、個通道的分支過于復雜的時候，建議還是把它看成一個業務流程，交給專業的BPM產品來做，這樣不但可以減少ESB實施的復雜度，還還可以大大提升其可修改性。在實際開發過程中，我們可以使用責任鏈模式（Chain of Responsibility Pattern圖 4.3）。一條責任鏈就是一個通道，消息處理器就是責任鏈中的一個個處理器（handler）。我們可以使用配置組件，在ESB初始化的時候就完成一個個消息處理器初始化工作。圖 4.3消息對象因為使用了消息通道，通道內的消息流必然是要有統一的消息對象（圖4.4）來進行良好的定義，這個消息對象，不但帶有消息內容，還應該包含消息狀態，以及消息所處通道的上

17、下文信息。 圖4.4MessageObject：消息載體Context：上下文，所有的組件和配置都會注冊到Context中Session：主要記錄用戶請求的信息。Endpoint(端點)Endpoint可以分為兩種，一種集成在ESB內部，另一種嵌入到使用ESB的應用系統中。理想情況下，推薦使用第二種，因為它的可操作范圍要大一些。而且還支持一些特性，比如，支持SOA分布式事務和實現負載均衡的功能。在嵌入式的端點中實現負載均衡的一個優點是可以避免出現水平擴展的負載均衡所帶來的單點故障問題，可以在一定的程度上提高可用性。雖然理想是美好的，但現實情況卻不允許我們在所有的應用系統中嵌入端點。在ESB系統

18、中我們可看到兩類的端點Inbound Endpoint和Outbound Endpoint，這兩類的端點一類是接收用戶的消息，一類是發送消息的服務方。典型的Endpoint可以分為Transport、Transformer和Filter三個功能塊，如下：TransportTransport的最主要的功能是接收和發送數據，提供通訊協議適配器的功能。圖 4.5是一個典型結構，它主要由三部分組成· Connector：主要職責是處理通訊協議的連接，此連接可以是一個TCP連接也可以是VM內部的一個虛擬連接。· MessageRecerver：主要職責是通過Connector的連接，

19、監聽連接并獲得用戶請求的消息，并把數據組成一個ESB內部消息對象，并把這個消息對象交由ESB管道來進行處理。· MessageDispatcher：主要職責是把消息發送給服務方，并接收消息服務方的響應。它將被組成一個消息處理的節點，放入到管道中。圖 4.5Transformer 其主要職責是對異構的消息格式進于轉換，使其成為ESB內部能識別的消息格式。它本身是一個消息處理器，可以在初使化時置入到消息處理管道中去。為了減化消息轉換的次數，一般來說，ESB內部會定義一個通用的消息格式，如果進來的消息不符合通用消息格式，它將被轉換成通用格式。目前，我們喜歡采用的做法是使用SOAP

20、作為一個通用的消息格式。如果企業內的部分系統使用XML作為消息載體，那么建議使用XSLT來把XML消息轉換成SOAP格式。XSLT是一個相對便捷的報文轉換技術/工具，并且XSLT本身也是XML，對其進行修改也較方便，這對提升ESB的可修改性有一定的幫助。隨著XSLT的普及，現在已經有大量的輔助的開發工具來提高XSLT開發效率。Filter 它的主要職責是進行消息過濾。其普通的使用場景是這樣的，根據數據的某些信息來判定是否要把消息送到下一個消息處理器進行處理。這個判定的過程，最好的做法是使用基礎組件中的規則引擎來判定，這樣會實現很好的可修改性。路由在架構上，路由應該和Transform

21、er一樣，只是一個消息的處理節點，它必須實現消息處理器的接口。這樣，它才能成為消息通道的一部分。其最大的職責是，讓消息找到正確的消費者。路由是可以聯合工作的，例如，我可以先使用路由的分解器分解消息，再使用內容路由來決定各部分消息的走向，使用filter來對消息進行過濾。這樣，通過一層層的嵌套完成路由工作，不過這嚴重增加了路由的復雜性，雖然，我們支持這種做法，但并不建議這么做，專業的事應該交給專門的系統來進行處理，這些處理應該屬于流程的編排，那就交給BPM來做吧。我們的原則是，如果路由超過了三層嵌套，就建議放到BPM中去?；A組件基礎組件主要是為了保障整個ESB能更好地完成ESB任務的組件，每個

22、組件都需要進行良好的設計，在這里，只是對一些組件進行一下必要的說明，在實際實施中可能還會增加一些基礎組件。· 日志組件：主要是記錄ESB交易產生的日志，這些日志用來追蹤業務交易。· 流控組件：保障ESB內部不會因為交易量突然超過其承受能力而出現宕機。· 規則引擎：用在需要執行filter或是基于內容的路由的情況，可以提升可修改性。· 線程池：對ESB很重要，它是最基礎組件之一· 對象池：在ESB的實現中，有一些對象不是線程安全的，而實例化這種對象要消耗大量的資源，這時，我們就會使且對象池來提高性能。它也是最基礎組件之一。· 消息隊列：

23、消息隊列可以是內部隊列，也可以是外部隊列，它也是非?；A的組件之一。· 配置組件：因為ESB實際上是一個可以做水平擴展的系統，而且，還要接受企業域的控制，所以配置組件需要有很高的可修改性，最好能應用JMX來對配置進行管理。· 監控組件：這個組件實際上只是監控平臺的一個客戶端，它主要是為監控平臺收集一些ESB內部的信息而存在。· SEDA組件：(Staged Event-Driven Architecture)的核心思想是把請求處理的過程分成幾個階段，不同階段使用不同數量的線程來處理，階段間使用事件驅動的異步通信模式。場景簡單同步處理在ESB實施當中，有很大一部分是

24、簡單的同步處理，在簡單的中的流程圖如下所示（圖4.6）。這是一個最簡單流程，當然ESB框架也會自動在這些消息處理器中間加入一些處理，比如記錄日志等基礎消息處理組件。圖 4.6簡單異步處理簡單異步處理需要使用公共組件SEDA，SEDA會把消息對象放入消息隊列中，然后直接就返回給請求方。接著SEDA的線程池會去處理隊列中的消息對象，后面的處理與同步處理一樣，這種簡單的異步處理，只適合于無返回消息的情況。SEDA的典型結構如圖4.7所示，它需要一個事件隊列，當某個請求消息是異步時，處理完報文轉換后就會把消息放入到管道內的事件隊列中。管道內的線程池監聽該隊列，取出隊列內的消息傳給下一步路由組件。也就是說，我們只是在簡單