ESB架構(gòu)之企業(yè)實施案例

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

2、整個結(jié)構(gòu)進行裁減，在開始時，可能只需要一個部門域，部門域內(nèi)支持水平擴展。當(dāng)達到瓶頸之后，則可能需要部署到多個部門域，這樣就可以擴展出多個水平擴展的節(jié)點，減少單個節(jié)點的職責(zé)。ESB的質(zhì)量屬性可用性ESB是企業(yè)內(nèi)應(yīng)用之間及對外第三方系統(tǒng)之間交互的集中點，它集中管理了交互的所有服務(wù)。它還提供服務(wù)查找、管理、審計、監(jiān)控、分析等功能。當(dāng)ESB服務(wù)出現(xiàn)故障，就將會影響企業(yè)內(nèi)所有應(yīng)用的正常運行。所以，可用被性放在了第一位。性能隨著企業(yè)內(nèi)部整合的推進，ESB內(nèi)部的服務(wù)交易量應(yīng)該不會少，高性能對于ESB來說也是非常重要的。可修改性因為SOA的企業(yè)治理是一個循序漸進的過程，在ESB部署之初，很難準(zhǔn)確估計未來的交易

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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