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

./本文講述了ESB架構(gòu)在企業(yè)的實(shí)際運(yùn)用,包括在部門、部門間以及企業(yè)級(jí)ESB架構(gòu)的設(shè)計(jì)和案例；分享了ESB設(shè)計(jì)過程需要考慮的關(guān)鍵問題；描述了不同ESB域的實(shí)施重心。概述ESB的存在主要是為了整合企業(yè)部的應(yīng)用,使企業(yè)的應(yīng)用能融為一體,而不是成為一個(gè)個(gè)信息孤島。可以說ESB是企業(yè)所有服務(wù)的中心點(diǎn),其它系統(tǒng)間的交互都需要通過ESB來完成。為此,它需擁有如下質(zhì)量屬性：可用性、性能、可修改性、可測試性、易用性。參考"ESB的質(zhì)量屬性"一節(jié)。為了解釋這些架構(gòu)屬性,我們可以從企業(yè)域、部門域、ESB部視角三個(gè)層次來進(jìn)行說明。ESB除了高可用性和性能之外,高可伸縮性也很重要,在實(shí)際實(shí)施過程中,讀者可以對(duì)整個(gè)結(jié)構(gòu)進(jìn)行裁減,在開始時(shí),可能只需要一個(gè)部門域,部門域支持水平擴(kuò)展。當(dāng)達(dá)到瓶頸之后,則可能需要部署到多個(gè)部門域,這樣就可以擴(kuò)展出多個(gè)水平擴(kuò)展的節(jié)點(diǎn),減少單個(gè)節(jié)點(diǎn)的職責(zé)。ESB的質(zhì)量屬性可用性ESB是企業(yè)應(yīng)用之間及對(duì)外第三方系統(tǒng)之間交互的集中點(diǎn),它集中管理了交互的所有服務(wù)。它還提供服務(wù)查找、管理、審計(jì)、監(jiān)控、分析等功能。當(dāng)ESB服務(wù)出現(xiàn)故障,就將會(huì)影響企業(yè)所有應(yīng)用的正常運(yùn)行。所以,可用被性放在了第一位。性能隨著企業(yè)部整合的推進(jìn),ESB部的服務(wù)交易量應(yīng)該不會(huì)少,高性能對(duì)于ESB來說也是非常重要的。可修改性因?yàn)镾OA的企業(yè)治理是一個(gè)循序漸進(jìn)的過程,在ESB部署之初,很難準(zhǔn)確估計(jì)未來的交易量,所以,對(duì)性能的擴(kuò)展性要求也比較高。在實(shí)際的生產(chǎn)運(yùn)維過程中,我們還是會(huì)常常發(fā)現(xiàn),服務(wù)可能會(huì)出現(xiàn)這樣或那樣的問題。為了不影響服務(wù)消費(fèi)者對(duì)服務(wù)的正常使用,快速的修改和部署,是一個(gè)很重要的問題。ESB項(xiàng)目是隨著SOA治理的發(fā)展而一次次迭代的,這也就要求了很高的可修改性。可測試性ESB上線既然是一個(gè)迭代的過程,服務(wù)會(huì)根據(jù)SOA理念的深入而增多。在迭代過程中,要保證以前的服務(wù)能順利通過測試,可測試性是一個(gè)很重要的保障。企業(yè)的應(yīng)用應(yīng)該只需面向ESB,它們交互時(shí)并不需要知道這個(gè)服務(wù)位于哪里或是誰在使用該服務(wù)。這時(shí),ESB測試就是一個(gè)很大的問題,因?yàn)楫?dāng)一筆交易開始的時(shí)候,你可能并不知道它會(huì)在哪里,但我們卻要保證這筆交易是正確的,這樣才能保持服務(wù)的正確性。易用性實(shí)現(xiàn)易用性需要提高服務(wù)的開發(fā)效率,即能快速開發(fā)和部署服務(wù)。因?yàn)樗鼘?duì)生產(chǎn)上的活動(dòng)沒有影響,所以將它放在末尾。企業(yè)域視圖在大多數(shù)據(jù)情況下,如果交易量不大,你大可以只使用一個(gè)部門域來支撐整個(gè)企業(yè)的服務(wù)。但如果只是一個(gè)ESB的部門域的話,是沒有辦法支撐后來交易量的逐年增長的。雖然每一個(gè)部門域都可以自行進(jìn)行水平的擴(kuò)展,但這還是有一個(gè)度的,超過這個(gè)度后,水平擴(kuò)展的難度就會(huì)提高,此時(shí)可能需要在業(yè)務(wù)上進(jìn)行垂直拆分,這種方式當(dāng)然沒有水平擴(kuò)展來得廉價(jià),但它能更容易的支撐更大的業(yè)務(wù)量。在企業(yè)域中,最大的特點(diǎn)就是有多個(gè)部門子域〔圖2.1,每個(gè)部門子域都是高度自治的。它們可以獨(dú)立地處理域各個(gè)系統(tǒng)的整合,只有當(dāng)需要使用其他域中的服務(wù)時(shí),才會(huì)請(qǐng)求其它的域。為了防止部門域之間變成一個(gè)蜘蛛網(wǎng),這里我們引入了企業(yè)域管理器,來統(tǒng)一管理域的服務(wù)與及對(duì)這些部門域進(jìn)行必要的監(jiān)控。在企業(yè)域管理器中主要有以下的幾個(gè)組件：企業(yè)服務(wù)查找注冊(cè)組件：這個(gè)組件一般情況下是獨(dú)立部署的,而且應(yīng)該有很高的可用性,在理想狀態(tài)下,應(yīng)該可以查找到所有部門域中的所有交易?？缬虻慕灰锥夹枰ㄟ^這個(gè)組件來查找到對(duì)應(yīng)域的服務(wù)。監(jiān)控組件：這個(gè)組件可以查看各個(gè)部門域的運(yùn)行情況。圖2.1元素企業(yè)域管理器企業(yè)服務(wù)查找注冊(cè)組件這個(gè)是企業(yè)域管理器的核心組件,使用它來管理企業(yè)的所有服務(wù),這個(gè)組件應(yīng)該有以下幾個(gè)功能。服務(wù)注冊(cè)：注冊(cè)服務(wù)地址、服務(wù)描述及服務(wù)規(guī)約。服務(wù)版本管理：管理服務(wù)的多個(gè)版本。服務(wù)客戶端代碼的生成：根據(jù)服務(wù)地址及說明生成服務(wù)客戶端,在我們的實(shí)施中,一般為java版本。服務(wù)路由表的查找：主要作用是查找對(duì)應(yīng)的服務(wù)地址,而且可以推送給服務(wù)路由器。服務(wù)的使用方注冊(cè)：要調(diào)用服務(wù),就必須到注冊(cè)組件中進(jìn)行注冊(cè),沒有注冊(cè)的使用方不允許進(jìn)行服務(wù)的調(diào)用。這樣就可以通過此組件找到此服務(wù)的使用路徑,從而當(dāng)服務(wù)進(jìn)行更改后,可以有效的通知相應(yīng)的服務(wù)使用方。監(jiān)控組件這個(gè)組件可以查看各個(gè)部門域的運(yùn)行情況,并在部門域的運(yùn)行超過閥值時(shí)發(fā)出預(yù)警。必要時(shí),操作域流控組件。具體的功能如下：查看各個(gè)部門域的運(yùn)行情況。如硬件資源、交易信息、流控信息和配置信息。對(duì)資源使用情況進(jìn)行預(yù)警。根據(jù)情況操作部門域的配置參數(shù),比如流控的配置參數(shù)。操作域的流控組件,保證重要交易,放棄次要交易。定時(shí)收集各個(gè)域的信息。信息保存之后,為報(bào)表、決策分析等提供信息支持。部門域部門域是企業(yè)的一個(gè)個(gè)ESB節(jié)點(diǎn),每個(gè)部門域會(huì)根據(jù)項(xiàng)目群,或者根據(jù)部門來進(jìn)行劃分,在各個(gè)部門域都有一個(gè)ESB組件,通過這個(gè)ESB來整合部門的服務(wù)及應(yīng)用。這個(gè)組件我們將會(huì)在部門域的視角中詳細(xì)描述。場景子域間交互所有服務(wù)都會(huì)注冊(cè)到企業(yè)管理器的服務(wù)查找組件中,這個(gè)組件擁這些服務(wù)的描述及地址信息。圖2.2描述了一個(gè)流程示例,部門域A如果要發(fā)起一個(gè)跨域的服務(wù)請(qǐng)求,就必須要使用企業(yè)域管理器的服務(wù)查找組件,通過這個(gè)組件的路由表獲取此服務(wù)提供者所在的部門域B的服務(wù)地址后,才能請(qǐng)求對(duì)應(yīng)的服務(wù)。為了提高性能,在這個(gè)場景里,也可以在啟動(dòng)的時(shí)就獲取所有路由信息,并緩存起來,服務(wù)請(qǐng)求時(shí)通過緩存來找到部門域B的地址。在這里有一點(diǎn)需要注意,當(dāng)部門域改變了服務(wù)地址之后的通知機(jī)制,我們的實(shí)施中有下以幾種策略：服務(wù)查找組件進(jìn)行推送如果服務(wù)請(qǐng)求地址出錯(cuò),重新請(qǐng)求服務(wù)查找組件定時(shí)清空路由緩存圖2.2部門域視圖部門域是企業(yè)ESB實(shí)施的基本組成單元,在一定交易量圍,它甚至可以獨(dú)立存在于企業(yè)。部門域ESB可以獨(dú)立地進(jìn)行水平擴(kuò)展,以進(jìn)行性能的伸縮,而且,這種性能的伸縮在一定程度上應(yīng)該是相對(duì)廉價(jià)的。在部門域的視角,我們不用關(guān)心ESB的部實(shí)現(xiàn),在一般情況下,只有以下四個(gè)場景同步請(qǐng)求服務(wù)異步請(qǐng)求服務(wù)同步提供服務(wù)異步提供服務(wù)同一域的系統(tǒng)只需要知道以上四種場景就足夠了,其它工作會(huì)在ESB部進(jìn)行整合。比如,與某個(gè)遺留系統(tǒng)的交易,ESB會(huì)通過適配器與之整合,我們會(huì)在ESB部視圖進(jìn)行闡述這一容。部門域主要涉及多種應(yīng)用系統(tǒng)和ESB兩種元素〔圖3.1,所有應(yīng)用系統(tǒng)之間的交互都要經(jīng)過ESB,它們是星型拓?fù)浣Y(jié)構(gòu),所以,ESB成了一個(gè)單點(diǎn)故障點(diǎn),出了問題會(huì)影響到整個(gè)部門域的各個(gè)子系統(tǒng),這也是為什么在ESB的系統(tǒng)中可用性的質(zhì)量屬性如此重要的原因。圖3.1元素ESB組件ESB組件是核心,這個(gè)元素部的功能將在ESB部視圖中詳細(xì)闡述。它位于部門域,其主要作用是：減少各應(yīng)用間的依賴：ESB最大的好處是可以把蜘蛛網(wǎng)結(jié)構(gòu)的依賴關(guān)系理順,使各個(gè)應(yīng)用只依賴于ESB。整合現(xiàn)有應(yīng)用：ESB可以通過自身的一些技術(shù)組件,對(duì)現(xiàn)有的應(yīng)用進(jìn)行協(xié)議轉(zhuǎn)換,讓現(xiàn)有的應(yīng)用能快速融入到企業(yè)整合的大環(huán)境中,不至于形成一個(gè)個(gè)的信息孤島。流控：保證高優(yōu)先級(jí)服務(wù)的高可用性。域應(yīng)用系統(tǒng)域應(yīng)用系統(tǒng)是企業(yè)部信息/服務(wù)的實(shí)際提供者和消費(fèi)者,當(dāng)它需要為其它消費(fèi)者提供信息/服務(wù),或者要消費(fèi)其它系統(tǒng)的信息/服務(wù)時(shí),就會(huì)和ESB產(chǎn)生關(guān)系。企業(yè)外系統(tǒng)當(dāng)今企業(yè)大多會(huì)與企業(yè)外部系統(tǒng)產(chǎn)生關(guān)系。我們不應(yīng)在應(yīng)用系統(tǒng)部直接和外部的系統(tǒng)產(chǎn)生關(guān)系,這樣會(huì)耗費(fèi)更多的時(shí)間在安全管理上,而且很多時(shí)候這些外系統(tǒng)并不是只有一個(gè)應(yīng)用在使用。此時(shí),不但會(huì)增加了單個(gè)應(yīng)用系統(tǒng)的復(fù)雜度,而且還會(huì)出現(xiàn)一些冗余。我們完全可以通過ESB來統(tǒng)一完成這些工作,簡化應(yīng)用系統(tǒng)消費(fèi)服務(wù)的過程。BPMBPM系統(tǒng)實(shí)際上是應(yīng)用系統(tǒng)的一部分,把BPM獨(dú)立出來進(jìn)行管理,是因?yàn)锽PM在ESB架構(gòu)中占有比較大的成分。在ESB實(shí)際實(shí)施過程中,我們可以使用ESB部的各種路由和端點(diǎn)的組合實(shí)現(xiàn)一定程度上的的BPM功能,但這樣實(shí)際上會(huì)復(fù)雜化ESB。如果能使用BPM產(chǎn)品來做這個(gè)交易的流程編排,就能減化ESB部的復(fù)雜性。如果應(yīng)用系統(tǒng)中沒有BPM這類的應(yīng)用系統(tǒng),如果可能的話,我們最好能使在企業(yè)域中加入一個(gè)BPM組件來實(shí)現(xiàn)業(yè)務(wù)流程。此時(shí),ESB需要能很好地與BPM應(yīng)用系統(tǒng)進(jìn)行交互。場景在以下場景中,一次請(qǐng)際上會(huì)通過兩個(gè)或更多的組件,之所以會(huì)這樣,是因?yàn)镋SB會(huì)屏蔽ESB的請(qǐng)求方和服務(wù)方的細(xì)節(jié),當(dāng)系統(tǒng)要與外部系統(tǒng)進(jìn)行交互時(shí),只應(yīng)知道ESB這個(gè)系統(tǒng)。這也是為什么可測試性在ESB系統(tǒng)很重要的原因。在ESB系統(tǒng)中,整合測試是非常重要的。在同異步服務(wù)提供的場景下,因?yàn)榻灰椎恼?qǐng)求方只知道ESB,或者有時(shí)候根本沒有請(qǐng)求方,在這種場景下的測試就顯得非常重要了,ESB不但要滿足技術(shù)上的測試功能,還要和服務(wù)方一起完成業(yè)務(wù)測試,這樣才能保證這筆交易的正確性。同步請(qǐng)求下圖是一個(gè)最簡單的應(yīng)用場景〔圖3.2,在這個(gè)場景中ESB只做交易轉(zhuǎn)發(fā),當(dāng)然中間也可能做了報(bào)文轉(zhuǎn)換的工作。這一切應(yīng)該在部門級(jí)視角上看應(yīng)該透明的,在部門域服務(wù)的使用者只需要依賴ESB提供的服務(wù)接口,而不需要依賴服務(wù)的最終實(shí)現(xiàn)。此處的細(xì)節(jié)會(huì)在ESB的部視角中進(jìn)行闡述。圖3.2異步請(qǐng)求如果服務(wù)不能在短時(shí)間能完成操作,就不應(yīng)該使用同步請(qǐng)求,而應(yīng)該使用異步請(qǐng)求。當(dāng)該服務(wù)完成操作后,再回調(diào)一個(gè)方法來獲取處理結(jié)果,當(dāng)然,也可能不需要返回結(jié)果。圖3.3同步提供服務(wù)圖3.4異步提供服務(wù)圖3.5ESB部視圖靜態(tài)看ESB系統(tǒng),它主要由三部分組成〔圖4.1端點(diǎn)〔Endpoint：它的職責(zé)可分為兩部分,一部分是接收服務(wù)請(qǐng)求,另一部分是調(diào)用服務(wù)提供者路由器〔Router：主要是消息的路由。當(dāng)端點(diǎn)接收到一個(gè)請(qǐng)求后,會(huì)交由路由器來選擇相應(yīng)的消息服務(wù)方?；A(chǔ)組件：支持通用ESB模式的通用組件。圖4.1從動(dòng)態(tài)地看ESB系統(tǒng),你會(huì)發(fā)現(xiàn),我們可以將ESB部看作一個(gè)個(gè)有組織的消息通道〔圖4.2,客戶端請(qǐng)求ESB時(shí)選擇一個(gè)相應(yīng)的消息通道。在這個(gè)消息通道中,會(huì)有很多的消息處理器,它們根據(jù)處理器自己的職責(zé)對(duì)消息流進(jìn)行相應(yīng)的處理。圖4.2元素消息處理通道消息處理通道是ESB架構(gòu)的核心部分,ESB核心的消息處理器分為兩部分,一部分是路由處理器,一部分是端點(diǎn)處理器。當(dāng)然,我們的基礎(chǔ)組件也會(huì)適時(shí)地在兩個(gè)處理器中間,攔截加入多個(gè)基礎(chǔ)組件處理器。例如,日志組件會(huì)加入日志處理器,以記錄ESB運(yùn)行的日志。圖4.2中描述的是一個(gè)簡單通道,在這個(gè)通道中沒有分支,路由處理器也只有一個(gè),在實(shí)際使用過程中當(dāng)然沒有這么簡單,路由處理器可能有多個(gè),Endpoint也可能有多個(gè)。當(dāng)整個(gè)通道的分支過于復(fù)雜的時(shí)候,建議還是把它看成一個(gè)業(yè)務(wù)流程,交給專業(yè)的BPM產(chǎn)品來做,這樣不但可以減少ESB實(shí)施的復(fù)雜度,還還可以大大提升其可修改性。在實(shí)際開發(fā)過程中,我們可以使用責(zé)任鏈模式〔ChainofResponsibilityPattern圖4.3。一條責(zé)任鏈就是一個(gè)通道,消息處理器就是責(zé)任鏈中的一個(gè)個(gè)處理器〔handler。我們可以使用配置組件,在ESB初始化的時(shí)候就完成一個(gè)個(gè)消息處理器初始化工作。圖4.3消息對(duì)象因?yàn)槭褂昧讼⑼ǖ?通道的消息流必然是要有統(tǒng)一的消息對(duì)象〔圖4.4來進(jìn)行良好的定義,這個(gè)消息對(duì)象,不但帶有消息容,還應(yīng)該包含消息狀態(tài),以及消息所處通道的上下文信息。圖4.4MessageObject：消息載體Context：上下文,所有的組件和配置都會(huì)注冊(cè)到Context中Session：主要記錄用戶請(qǐng)求的信息。Endpoint<端點(diǎn)>Endpoint可以分為兩種,一種集成在ESB部,另一種嵌入到使用ESB的應(yīng)用系統(tǒng)中。理想情況下,推薦使用第二種,因?yàn)樗目刹僮鲊笠恍?。而且還支持一些特性,比如,支持SOA分布式事務(wù)和實(shí)現(xiàn)負(fù)載均衡的功能。在嵌入式的端點(diǎn)中實(shí)現(xiàn)負(fù)載均衡的一個(gè)優(yōu)點(diǎn)是——可以避免出現(xiàn)水平擴(kuò)展的負(fù)載均衡所帶來的單點(diǎn)故障問題,可以在一定的程度上提高可用性。雖然理想是美好的,但現(xiàn)實(shí)情況卻不允許我們?cè)谒械膽?yīng)用系統(tǒng)中嵌入端點(diǎn)。在ESB系統(tǒng)中我們可看到兩類的端點(diǎn)InboundEndpoint和OutboundEndpoint,這兩類的端點(diǎn)一類是接收用戶的消息,一類是發(fā)送消息的服務(wù)方。典型的Endpoint可以分為Transport、Transformer和Filter三個(gè)功能塊,如下：TransportTransport的最主要的功能是接收和發(fā)送數(shù)據(jù),提供通訊協(xié)議適配器的功能。圖4.5是一個(gè)典型結(jié)構(gòu),它主要由三部分組成Connector：主要職責(zé)是處理通訊協(xié)議的連接,此連接可以是一個(gè)TCP連接也可以是VM部的一個(gè)虛擬連接。MessageRecerver：主要職責(zé)是通過Connector的連接,監(jiān)聽連接并獲得用戶請(qǐng)求的消息,并把數(shù)據(jù)組成一個(gè)ESB部消息對(duì)象,并把這個(gè)消息對(duì)象交由ESB管道來進(jìn)行處理。MessageDispatcher：主要職責(zé)是把消息發(fā)送給服務(wù)方,并接收消息服務(wù)方的響應(yīng)。它將被組成一個(gè)消息處理的節(jié)點(diǎn),放入到管道中。圖4.5Transformer其主要職責(zé)是對(duì)異構(gòu)的消息格式進(jìn)于轉(zhuǎn)換,使其成為ESB部能識(shí)別的消息格式。它本身是一個(gè)消息處理器,可以在初使化時(shí)置入到消息處理管道中去。為了減化消息轉(zhuǎn)換的次數(shù),一般來說,ESB部會(huì)定義一個(gè)通用的消息格式,如果進(jìn)來的消息不符合通用消息格式,它將被轉(zhuǎn)換成通用格式。目前,我們喜歡采用的做法是使用SOAP作為一個(gè)通用的消息格式。如果企業(yè)的部分系統(tǒng)使用XML作為消息載體,那么建議使用XSLT來把XML消息轉(zhuǎn)換成SOAP格式。XSLT是一個(gè)相對(duì)便捷的報(bào)文轉(zhuǎn)換技術(shù)/工具,并且XSLT本身也是XML,對(duì)其進(jìn)行修改也較方便,這對(duì)提升ESB的可修改性有一定的幫助。隨著XSLT的普及,現(xiàn)在已經(jīng)有大量的輔助的開發(fā)工具來提高XSLT開發(fā)效率。Filter它的主要職責(zé)是進(jìn)行消息過濾。其普通的使用場景是這樣的,根據(jù)數(shù)據(jù)的某些信息來判定是否要把消息送到下一個(gè)消息處理器進(jìn)行處理。這個(gè)判定的過程,最好的做法是使用基礎(chǔ)組件中的規(guī)則引擎來判定,這樣會(huì)實(shí)現(xiàn)很好的可修改性。路由在架構(gòu)上,路由應(yīng)該和Transformer一樣,只是一個(gè)消息的處理節(jié)點(diǎn),它必須實(shí)現(xiàn)消息處理器的接口。這樣,它才能成為消息通道的一部分。其最大的職責(zé)是,讓消息找到正確的消費(fèi)者。路由是可以聯(lián)合工作的,例如,我可以先使用路由的分解器分解消息,再使用容路由來決定各部分消息的走向,使用filter來對(duì)消息進(jìn)行過濾。這樣,通過一層層的嵌套完成路由工作,不過這嚴(yán)重增加了路由的復(fù)雜性,雖然,我們支持這種做法,但并不建議這么做,專業(yè)的事應(yīng)該交給專門的系統(tǒng)來進(jìn)行處理,這些處理應(yīng)該屬于流程的編排,那就交給BPM來做吧。我們的原則是,如果路由超過了三層嵌套,就建議放到BPM中去。基礎(chǔ)組件基礎(chǔ)組件主要是為了保障整個(gè)ESB能更好地完成ESB任務(wù)的組件,每個(gè)組件都需要進(jìn)行良好的設(shè)計(jì),在這里,只是對(duì)一些組件進(jìn)行一下必要的說明,在實(shí)際實(shí)施中可能還會(huì)增加一些基礎(chǔ)組件。日志組件：主要是記錄ESB交易產(chǎn)生的日志,這些日志用來追蹤業(yè)務(wù)交易。流控組件：保障ESB部不會(huì)因?yàn)榻灰琢客蝗怀^其承受能力而出現(xiàn)宕機(jī)。規(guī)則引擎：用在需要執(zhí)行filter或是基于容的路由的情況,可以提升可修改性。線程池：對(duì)ESB很重要,它是最基礎(chǔ)組件之一對(duì)象池：在ESB的實(shí)現(xiàn)中,有一些對(duì)象不是線程安全的,而實(shí)例化這種對(duì)象要消耗大量的資源,這時(shí),我們就會(huì)使且對(duì)象池來提高性能。它也是最基礎(chǔ)組件之一。消息隊(duì)列：消息隊(duì)列可以是部隊(duì)列,也可以是外部隊(duì)列,它也是非?；A(chǔ)的組件之一。配置組件：因?yàn)镋SB實(shí)際上是一個(gè)可以做水平擴(kuò)展的系統(tǒng),而且,還要接受企業(yè)域的控制,所以配置組件需要有很高的可修改性,最好能應(yīng)用JMX來對(duì)配置進(jìn)行管理。監(jiān)控組件：這個(gè)組件實(shí)際上只是監(jiān)控平臺(tái)的一個(gè)客戶端,它主要是為監(jiān)控平臺(tái)收集一些ESB部的信息而存在。SEDA組件：<StagedEvent-DrivenArchitecture>的核心思想是把請(qǐng)求處理的過程分成幾個(gè)階段,不同階段使用不同數(shù)量的線程來處理,階段間使用事件驅(qū)動(dòng)的異步通信模式。場景簡單同步處理在ESB實(shí)施當(dāng)中,有很大一部分是簡單的同步處理,在簡單的中的流程圖如下所示〔圖4.6。這是一個(gè)最簡單流程,當(dāng)然ESB框架也會(huì)自動(dòng)在這些消息處理器中間加入一些處理,比如記錄日志等基礎(chǔ)消息處理組件。圖4.6簡單異步處理簡單異步處理需要使用公共組件SEDA,SEDA會(huì)把消息對(duì)象放入消息隊(duì)列中,然后直接就返回給請(qǐng)求方。接著SEDA的線程池會(huì)去處理隊(duì)列中的消息對(duì)象,后面的處理與同步處理一樣,這種簡單的異步處理,只適合于無返回消息的情況。SEDA的典型結(jié)構(gòu)如圖4.7所示,它需要一個(gè)事件隊(duì)列,當(dāng)某個(gè)請(qǐng)求消息是異步時(shí),處理完報(bào)文轉(zhuǎn)換后就會(huì)把消息放入到管道的事件隊(duì)列中。管道的線程池監(jiān)聽該隊(duì)列,取出隊(duì)列的消息傳給下一步路由組件。也就是說,我們只是在簡單同步的基礎(chǔ)上,在transp