ESB項(xiàng)目需求分析和方案設(shè)計(jì)淺談

1、.：.；好像其它IT工程一樣，企業(yè)效力總線類工程的實(shí)施也要閱歷需求分析、方案設(shè)計(jì)、編碼和測(cè)試、上線部署等階段。下面我們將針對(duì)ESB工程的設(shè)計(jì)和實(shí)施過(guò)程中各個(gè)階段要完成的主要任務(wù)內(nèi)容和一些最正確實(shí)際跟大家作一些討論，進(jìn)而希望大家在企業(yè)ESB工程實(shí)施過(guò)程中自創(chuàng)科學(xué)的方法論的指點(diǎn)來(lái)保證其勝利。ESB的需求分析需求分析階段是梳理工程中相關(guān)功能需求和非功能需求的重要步驟，它是整個(gè)工程成敗的關(guān)鍵。在這個(gè)階段我們將從企業(yè)業(yè)務(wù)需求出發(fā)，梳理端到端的跨系統(tǒng)業(yè)務(wù)流程；基于業(yè)務(wù)流程，根據(jù)科學(xué)的方法論進(jìn)展效力鑒別；由效力列表出發(fā)，梳理效力的消費(fèi)和提供關(guān)系；然后根據(jù)SOA的最正確實(shí)際，定義效力的接口，包括效力的Sche

2、ma描畫，字段的類型，編碼的規(guī)那么；根據(jù)效力的消費(fèi)提供關(guān)系，梳理ESB中的效力映射和轉(zhuǎn)換規(guī)那么和戰(zhàn)略。概括而言，我們需求從功能性和非功能性兩個(gè)方面來(lái)進(jìn)展ESB的需求分析。針對(duì)ESB的功能性需求，我們要偏重了解以下方面的問(wèn)題：1. 梳理出要被集成的系統(tǒng)的稱號(hào)，個(gè)數(shù)。2. 針對(duì)每個(gè)系統(tǒng)而言，要了解：該系統(tǒng)的對(duì)外接口是向外調(diào)用，被他人調(diào)用，還是二者都有； 接口的實(shí)時(shí)性要求，是實(shí)時(shí)的還是批量的，還是二者皆有？ 接口的調(diào)用方式，是同步的還是異步的，還是二者皆有？ 運(yùn)用系統(tǒng)所運(yùn)轉(zhuǎn)的操作系統(tǒng)平臺(tái)。 運(yùn)用系統(tǒng)本身的編程言語(yǔ)？C/C+, Java. 這些系統(tǒng)現(xiàn)有接口的情況，能否曾經(jīng)可以提供對(duì)外接口，接口的方式是

3、什么，包括接口的通訊協(xié)議是什么，/MQ/Socket/ 其它？接口的數(shù)據(jù)格式是什么，XML/ 自定義格式 / 其他行業(yè)規(guī)范格式？接口的編程言語(yǔ)是什么，Java/C/C+？假設(shè)本身不能提供接口，那么要做接口開(kāi)發(fā)時(shí)有什么要求或限制條件？ 這些運(yùn)用后臺(tái)數(shù)據(jù)庫(kù)的情況，數(shù)據(jù)庫(kù)能否直接訪問(wèn)？ 每個(gè)運(yùn)用跟其他運(yùn)用交換數(shù)據(jù)時(shí)，源數(shù)據(jù)格式和目的數(shù)據(jù)格式，比如從文本格式轉(zhuǎn)換為 XML 格式？ 買賣特征：哪些處置要采用兩階段提交；能否需求多個(gè)音訊組成一個(gè)買賣；能否要保證音訊之間的處置順序； 適配器的情況：對(duì)于一些特殊系統(tǒng)，能否曾經(jīng)具備現(xiàn)成的適配器；適配器是單向的還是雙向的； 音訊通訊的方式：是Send and Fo

4、rget、Request/Reply還是Pub/Sub? 針對(duì)ESB的非功能性需求，我們要確認(rèn)：1. ESB平臺(tái)的擴(kuò)展性和高可用性需求，包括HA和集群等；2. ESB平臺(tái)的性能需求，主要包括系統(tǒng)間數(shù)據(jù)交換的頻率，要交換的數(shù)據(jù)的大小 ( 音訊大小將直接對(duì)效率呵斥影響 )；峰值時(shí)候?qū)SB數(shù)據(jù)吞吐量、呼應(yīng)時(shí)間的要求等；3. 哪些買賣要保證數(shù)據(jù)傳輸?shù)母呖煽啃裕?. ESB平臺(tái)的可管理性需求，如效力的生命周期管理，ESB 平臺(tái)的維護(hù)和管理；假設(shè)企業(yè)曾經(jīng)設(shè)立了SOA管控方面的規(guī)范，那么要服從規(guī)范的制約，比如要思索能否有規(guī)定的命名規(guī)那么，企業(yè)能否有企業(yè)級(jí)的數(shù)據(jù)規(guī)范和底層通訊協(xié)議的規(guī)范等；5. 平安性方面的

5、要求：能否采用SSL傳輸加密，能否對(duì)音訊進(jìn)展加密/解密處置等；6. 錯(cuò)誤處置和日志以及平臺(tái)本身的運(yùn)轉(zhuǎn)監(jiān)控等方面的要求等。ESB的方案設(shè)計(jì)方案設(shè)計(jì)的主要內(nèi)容包括：ESB涉及IT運(yùn)用環(huán)境分析，定義ESB與相關(guān)運(yùn)用的接口方式； ESB架構(gòu)概要設(shè)計(jì)，并定義架構(gòu)原那么； ESB相關(guān)產(chǎn)品選擇，包括與外圍系統(tǒng)的適配器選擇和ESB產(chǎn)品選擇； ESB組件模型設(shè)計(jì)，分解ESB的相關(guān)模塊，滿足SOA的分別關(guān)注點(diǎn)等架構(gòu)原那么； ESB運(yùn)作模型設(shè)計(jì)，滿足平臺(tái)的非功能性需求； ESB平臺(tái)的效力流設(shè)計(jì)，涉及路由、轉(zhuǎn)換和映射等； ESB的同步、異步或者發(fā)布/訂閱方式設(shè)計(jì)； ESB平臺(tái)的接入渠道和數(shù)據(jù)接口設(shè)計(jì)，包括XML/JM

6、S、SOAP/、EDI/MQ 等； ESB相關(guān)的適配器設(shè)計(jì)，包括技術(shù)適配器或者自開(kāi)發(fā)的適配器； ESB平臺(tái)的容錯(cuò)和重試機(jī)制設(shè)計(jì)，包括日志等的一致管理等； 圖 1 是一個(gè)采用ESB整合的高層架構(gòu)設(shè)計(jì)舉例：圖 1. ESB參考架構(gòu) 如圖 1 所示，ESB架構(gòu)設(shè)計(jì)時(shí)主要要思索通訊協(xié)議接入和轉(zhuǎn)換、數(shù)據(jù)接入和轉(zhuǎn)換、數(shù)據(jù)處置流程以及效力的注冊(cè)和管理等方面的內(nèi)容。其中通訊協(xié)議接入和轉(zhuǎn)換是指對(duì)各種被集成的運(yùn)用系統(tǒng)的通訊協(xié)議的支持和轉(zhuǎn)換才干，例如HTTP、JMS、Socket、FTP等；數(shù)據(jù)接入和轉(zhuǎn)換是指對(duì)各種被集成的運(yùn)用系統(tǒng)提供的數(shù)據(jù)格式的支持和轉(zhuǎn)換才干，例如XML、SOAP、自定義格式以及符合某些行業(yè)規(guī)范的

7、專有格式SWIFT、EDI、HL7 等；數(shù)據(jù)處置流程是指路由、格式轉(zhuǎn)換、數(shù)據(jù)庫(kù)讀寫等對(duì)數(shù)據(jù)的各種處置；一致效力注冊(cè)存儲(chǔ)管理是指對(duì)效力的注冊(cè)、發(fā)布、查詢，以及對(duì)運(yùn)營(yíng)時(shí)效力的管控，并且提供效力運(yùn)營(yíng)形狀的統(tǒng)計(jì)分析數(shù)據(jù)。ESB的組件模型圖 2. ESB組件模型 圖 2 給出了一個(gè)ESB組件模型的例如，其中包含的各主要組件及其功能如下：1. Message Broker Runtime組件提供音訊路由、格式轉(zhuǎn)換、音訊日志等操作的運(yùn)轉(zhuǎn)時(shí)環(huán)境。該運(yùn)轉(zhuǎn)環(huán)境由IBM Message Broker提供；2. Messaging Broker Instance組件是處置基于MQ音訊業(yè)務(wù)懇求的容器。它是作為一個(gè)Bro

8、ker實(shí)例運(yùn)轉(zhuǎn)在Message Broker Runtime上的。該實(shí)例提供了MQ音訊的業(yè)務(wù)懇求處置器、效力日志、效力定位等功能的運(yùn)轉(zhuǎn)容器；3. Web Service Broker Instance組件是處置基于Web Service的業(yè)務(wù)懇求的容器，它是作為一個(gè)Broker實(shí)例運(yùn)轉(zhuǎn)在Message Broker Runtime上的。該實(shí)例提供了Web Service的業(yè)務(wù)懇求處置、效力日志、以及效力定位等功能。4. Event Broker Instance組件是平臺(tái)內(nèi)部處置Pub/Sub事件的容器。它是作為一個(gè)Broker實(shí)例運(yùn)轉(zhuǎn)在Message Broker Runtime上的。該容器

9、提供了Event Handler組件的運(yùn)轉(zhuǎn)環(huán)境，將基于MQ/JMS的事件分發(fā)到不同平臺(tái)組件的目的隊(duì)列上。5. Message Handler組件是處置基于MQ音訊的業(yè)務(wù)懇求，包括音訊解析、格式轉(zhuǎn)換，效力鑒權(quán)與認(rèn)證、效力路由、效力日志等功能。Message Handler組件處置MQ音訊的典型流程如下：首先對(duì)MQ音訊進(jìn)展解析，對(duì)解析后的業(yè)務(wù)懇求進(jìn)展分析，之后經(jīng)過(guò)Authentication 與 Authorization組件判別該懇求者的業(yè)務(wù)懇求能否可以進(jìn)展后續(xù)處置； 經(jīng)過(guò)Service Locating組件對(duì)該業(yè)務(wù)懇求進(jìn)展效力定位與路由；將基于MQ的業(yè)務(wù)懇求音訊轉(zhuǎn)換成Web Service的業(yè)

10、務(wù)懇求音訊； 經(jīng)過(guò)Service Logging組件對(duì)整個(gè)業(yè)務(wù)懇求進(jìn)展日志記錄； 前往業(yè)務(wù)懇求處置結(jié)果給業(yè)務(wù)發(fā)起者，假設(shè)失敗，前往錯(cuò)誤音訊。 6. Web Service Handler組件是處置基于Web Service的業(yè)務(wù)懇求，與Message Handler組件功能類似，也包括音訊解析、格式轉(zhuǎn)換，效力鑒權(quán)與認(rèn)證、效力路由、效力日志等功能。Web ServiceHandler組件處置Web Service懇求的典型流程如下：首先對(duì)Web Service懇求音訊進(jìn)展解析，對(duì)解析后的業(yè)務(wù)懇求進(jìn)展分析，之后經(jīng)過(guò)Authentication與Authorization組件判別該懇求者的業(yè)務(wù)懇求能

11、否可以進(jìn)展后續(xù)處置； 經(jīng)過(guò)Service Locating組件對(duì)該業(yè)務(wù)懇求進(jìn)展效力定位與路由； 經(jīng)過(guò) Service Logging 組件對(duì)整個(gè)業(yè)務(wù)懇求進(jìn)展日志記錄； 前往業(yè)務(wù)懇求處置結(jié)果給業(yè)務(wù)發(fā)起者，假設(shè)失敗，前往錯(cuò)誤音訊。 7. Event Handler組件實(shí)現(xiàn)對(duì)Pub/Sub的處置。8. Service Locating組件擔(dān)任根據(jù)業(yè)務(wù)懇求定位詳細(xì)的效力提供者。Service Locating經(jīng)過(guò)對(duì)效力目錄的查詢選擇適宜的效力進(jìn)展后續(xù)的調(diào)用，該查詢?nèi)蝿?wù)可以經(jīng)過(guò)實(shí)時(shí)的效力目錄查詢獲得結(jié)果。9. Service Logging組件擔(dān)任記錄整個(gè)業(yè)務(wù)懇求處置過(guò)程中的情況，該組件的實(shí)現(xiàn)可以經(jīng)過(guò)文

12、件或者數(shù)據(jù)庫(kù)的方式。10. Authentication組件擔(dān)任對(duì)業(yè)務(wù)懇求者進(jìn)展鑒權(quán)，判別該業(yè)務(wù)懇求者能否可以訪問(wèn)平臺(tái)效力，該鑒權(quán)的任務(wù)在企業(yè)效力總線的外部進(jìn)展，Authentication組件只是調(diào)用外部功能完成。11. Authorization組件判別業(yè)務(wù)懇求者能否具備訪問(wèn)某特定效力的權(quán)限，該驗(yàn)證權(quán)限的任務(wù)在企業(yè)效力總線的外部進(jìn)展，Authorization 組件只是調(diào)用外部功能完成。以處置基于MQ音訊輸入為例，ESB的組件交互圖如圖 3 所示：圖 3. ESB組件交互圖 ESB方案設(shè)計(jì)時(shí)的最正確實(shí)際根據(jù)我們以往工程設(shè)計(jì)和開(kāi)發(fā)時(shí)的一些閱歷，我們建議進(jìn)展ESB的方案設(shè)計(jì)時(shí)要遵照下述最正確實(shí)

13、際：確定規(guī)范的運(yùn)用：運(yùn)用與否、運(yùn)用到什么程度； 確定在ESB上實(shí)現(xiàn)的業(yè)務(wù)邏輯：ESB是一個(gè)效力路由和轉(zhuǎn)換中心，而不是一個(gè)運(yùn)用效力器，因此它并不能取代應(yīng)有效力器。復(fù)雜的音訊解析和轉(zhuǎn)換相比簡(jiǎn)單的路由操作所需耗費(fèi)的本錢要高的多，因此在ESB上應(yīng)該主要思索路由、格式轉(zhuǎn)換、效力調(diào)用等問(wèn)題，而對(duì)于數(shù)據(jù)本身的處置應(yīng)該交給相應(yīng)的運(yùn)用來(lái)完成； 確定音訊格式：從規(guī)范化的角度而言，XML當(dāng)然是首選，但是從解析 / 處置性能、行業(yè)規(guī)范以及對(duì)現(xiàn)有運(yùn)用的最大兼容性的角度而言，能夠會(huì)采用某些特定格式，例如EDI、SWITF、平文本或者自定義格式等； 區(qū)別音訊頭和音訊體：把數(shù)據(jù)的Meta-data，例如：平安相關(guān)的信息、日志

14、的等級(jí)、懇求端的標(biāo)識(shí)等放在音訊頭中，而不要放在音訊體中。這樣可以很容易地改動(dòng)其內(nèi)容及其對(duì)其的處置邏輯。在ESB中只處置音訊頭，防止對(duì)音訊體的解析； 設(shè)計(jì)時(shí)參考ESB相關(guān)的成熟Patterns； 運(yùn)用效力注冊(cè)庫(kù)：如需求效力Endpoint的查找：引薦從效力注冊(cè)中心進(jìn)展查找，這樣的益處在于：效力提供者可以容易地發(fā)布新的效力，效力提供者和ESB之間的耦合度可以更低，經(jīng)過(guò)關(guān)于效力本身的Metadata來(lái)進(jìn)展效力的查找和路由； 注重性能和高可用性的思索； 在必需的情況下思索買賣完好性； 適配器的采用：運(yùn)用系統(tǒng)經(jīng)過(guò)適配器實(shí)現(xiàn)與 ESB 的雙向交互，適配器主要分為技術(shù)適配器、運(yùn)用適配器兩種，適配器的物理部署

15、可以與EIS部署在一同、或者與ESB部署在一同，也可以單獨(dú)部署，在適配器設(shè)計(jì)時(shí)要思索通訊協(xié)議和音訊格式兩個(gè)方面；多 ESB 的設(shè)計(jì)：ESB 也是一個(gè)邏輯的組件，在一個(gè)企業(yè)里能夠需求多個(gè)ESB，例如：企業(yè)內(nèi)部ESB銜接企業(yè)內(nèi)部各個(gè)系統(tǒng)，外部ESB實(shí)現(xiàn)企業(yè)與協(xié)作同伴等的外部銜接；再如：企業(yè)內(nèi)部能夠存在假設(shè)干個(gè)部門級(jí)ESB和一個(gè)全企業(yè)ESB； 確定效力版本控制戰(zhàn)略； 確定端到端的QoS準(zhǔn)那么； 注重平安性； 確定IT部門ESB平臺(tái)的擔(dān)任主體，長(zhǎng)期的投入。 ESB的平安性思索對(duì)于ESB的平安性思索，主要有兩種方式，第一種方式是經(jīng)過(guò)ESB內(nèi)部的Mediation節(jié)點(diǎn)來(lái)進(jìn)展效力懇求者的認(rèn)證 / 授權(quán)；另一

16、種是調(diào)用一個(gè)外部效力進(jìn)展效力懇求者的認(rèn)證 / 授權(quán)，如圖4所示，圖中給出了這兩種方式的表示圖，詳細(xì)實(shí)施時(shí)可以進(jìn)展選擇。圖 4. ESB的兩種平安實(shí)現(xiàn)方式 運(yùn)轉(zhuǎn)在ESB平臺(tái)上的效力的管理和監(jiān)控當(dāng)一個(gè)企業(yè)開(kāi)場(chǎng)它的SOA之旅時(shí)，開(kāi)場(chǎng)階段通常會(huì)選取一個(gè)詳細(xì)的工程進(jìn)展 SOA 的嘗試，然后便會(huì)逐漸走向全企業(yè)采用，這時(shí)，大多數(shù)企業(yè)都會(huì)面臨一個(gè)問(wèn)題，那就是效力越來(lái)越多，對(duì)這些效力目錄的管理出現(xiàn)了很多問(wèn)題，例如：一切與效力相關(guān)的信息是如何被管理的，包括存儲(chǔ)、管理、維護(hù)、存取等？效力懇求者如何決議運(yùn)用哪個(gè)效力？效力懇求者如何定位效力的 Endpoint？當(dāng)效力信息發(fā)生改動(dòng)時(shí)如何得到通知？因此我們建議用戶在盡能夠

17、早的情況下思索效力注冊(cè)中心的建立，所謂效力注冊(cè)中心是一個(gè)企業(yè)范圍內(nèi)的效力信息的存儲(chǔ)庫(kù)，該存儲(chǔ)庫(kù)存儲(chǔ)了企業(yè)中注冊(cè)的效力和效力相關(guān)的信息，它的主要功能包括：采用集中的方式來(lái)管理效力相關(guān)的信息，為效力元數(shù)據(jù)同時(shí)提供“注冊(cè)中心功能，允許用戶存儲(chǔ)、管理和查詢包含效力描畫的效力元數(shù)據(jù)構(gòu)件； 提供效力的治理功能，實(shí)現(xiàn)整個(gè)效力生命周期的管理； 提供效力間依賴、包容關(guān)系的管理； 提供分類和版本控制等功能； 提供效力發(fā)現(xiàn)和通知等才干等。 除了效力注冊(cè)中心的思索之外，我們還要思索對(duì)效力的管理。效力不僅具有特定的功能，還應(yīng)該滿足一些諸如性能、可用性、平安性等QoS目的。效力呼應(yīng)的快慢、什么時(shí)間可用、可以被誰(shuí)調(diào)用、在某

18、個(gè)時(shí)間段里能被調(diào)用多少次、哪些事件要記錄日志，這些都是效力管理要思索的問(wèn)題。經(jīng)過(guò)效力注冊(cè)中心和效力監(jiān)控平臺(tái)的有機(jī)配合，我們可以根據(jù)效力的呼應(yīng)時(shí)間、效力可用與否等戰(zhàn)略來(lái)實(shí)現(xiàn)對(duì)效力的動(dòng)態(tài)訪問(wèn)。讓我們來(lái)看一個(gè)例子：圖 5. 運(yùn)用效力監(jiān)控平臺(tái)之前ESB的效力懇求和呼應(yīng)圖 6. 運(yùn)用效力監(jiān)控平臺(tái)之后ESB的效力懇求和呼應(yīng) 如圖 5 和圖 6 所示，我們可以利用效力監(jiān)控平臺(tái)對(duì)效力進(jìn)展監(jiān)控和統(tǒng)計(jì)分析，從而使ESB平臺(tái)可以根據(jù)效力提供者的性能優(yōu)劣來(lái)動(dòng)態(tài)地綁定和調(diào)用高性能的效力，其過(guò)程如下：效力懇求者懇求“PurchaseOrder效力 效力注冊(cè)庫(kù)查找到效力提供者 效力注冊(cè)管理平臺(tái)第一次調(diào)用了Proder1提供的效力 Provider1的性能被監(jiān)控工具監(jiān)控到 隨著時(shí)間的推移，Provider1的性能越來(lái)越差 監(jiān)控軟件監(jiān)控到這一景象，就會(huì)停頓運(yùn)用Provider1提供的效力 當(dāng)下一次效力懇求者再次懇求此效力時(shí)，效力注冊(cè)管理平臺(tái)將調(diào)用Provider2，懇求Provider2提供的效力。 ESB的開(kāi)發(fā)和測(cè)試在ESB開(kāi)發(fā)和測(cè)試階段要完成的任務(wù)主要包括：基于eclipse工具的模型驅(qū)