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

/ESB案例解析和項(xiàng)目實(shí)施經(jīng)驗(yàn)分享,第3部分:ESB項(xiàng)目需求分析和方案設(shè)計(jì)淺談本文是一個(gè)由3部分內(nèi)容組成的系列文章,在前2部分當(dāng)中,介紹了兩個(gè)企業(yè)ESB解決方案的設(shè)計(jì)案例,這兩個(gè)案例分別來自于交通運(yùn)輸行業(yè)和制造行業(yè),我們針對不同行業(yè)的業(yè)務(wù)和應(yīng)用特點(diǎn)設(shè)計(jì)了不同的ESB解決方案。第3部分內(nèi)容我們介紹了ESB項(xiàng)目實(shí)施的一些方法論和經(jīng)驗(yàn)。前言如同其它IT項(xiàng)目一樣,企業(yè)服務(wù)總線類項(xiàng)目的實(shí)施也要經(jīng)歷需求分析、方案設(shè)計(jì)、編碼和測試、上線部署等階段。在介紹了兩個(gè)特定行業(yè)對應(yīng)的ESB解決方案之后,在本系列文章的最后一部分,我們將針對ESB項(xiàng)目的設(shè)計(jì)和實(shí)施過程中各個(gè)階段要完成的主要工作內(nèi)容和一些最佳實(shí)踐跟大家作一些討論,進(jìn)而希望大家在企業(yè)ESB項(xiàng)目實(shí)施過程中借鑒科學(xué)的方法論的指導(dǎo)來保證其成功。ESB的需求分析需求分析階段是梳理項(xiàng)目中相關(guān)功能需求和非功能需求的重要步驟,它是整個(gè)項(xiàng)目成敗的關(guān)鍵。在這個(gè)階段我們將從企業(yè)業(yè)務(wù)需求出發(fā),梳理端到端的跨系統(tǒng)業(yè)務(wù)流程；基于業(yè)務(wù)流程,依據(jù)科學(xué)的方法論進(jìn)行服務(wù)鑒別；由服務(wù)列表出發(fā),梳理服務(wù)的消費(fèi)和提供關(guān)系；然后根據(jù)SOA的最佳實(shí)踐,定義服務(wù)的接口,包括服務(wù)的Schema描述,字段的類型,編碼的規(guī)則；依據(jù)服務(wù)的消費(fèi)－提供關(guān)系,梳理ESB中的服務(wù)映射和轉(zhuǎn)換規(guī)則和策略。概括而言,我們需要從功能性和非功能性兩個(gè)方面來進(jìn)行ESB的需求分析。針對ESB的功能性需求,我們要側(cè)重了解以下方面的問題：1.梳理出要被集成的系統(tǒng)的名稱,個(gè)數(shù)。2.針對每個(gè)系統(tǒng)而言,要了解：該系統(tǒng)的對外接口是向外調(diào)用<OutBound>,被別人調(diào)用<Inbound>,還是二者都有；接口的實(shí)時(shí)性要求,是實(shí)時(shí)的還是批量的,還是二者皆有？接口的調(diào)用方式,是同步的還是異步的,還是二者皆有？應(yīng)用系統(tǒng)所運(yùn)行的操作系統(tǒng)平臺(tái)。應(yīng)用系統(tǒng)本身的編程語言？C/C++,Java…..這些系統(tǒng)現(xiàn)有接口的情況,是否已經(jīng)可以提供對外接口,接口的方式是什么,包括接口的通訊協(xié)議是什么,HTTP/MQ/Socket/其它？接口的數(shù)據(jù)格式是什么,XML/自定義格式/其他行業(yè)標(biāo)準(zhǔn)格式？接口的編程語言是什么,Java/C/C++？如果本身不能提供接口,那么要做接口開發(fā)時(shí)有什么要求或限制條件？這些應(yīng)用后臺(tái)數(shù)據(jù)庫的情況,數(shù)據(jù)庫能否直接訪問？每個(gè)應(yīng)用跟其他應(yīng)用交換數(shù)據(jù)時(shí),源數(shù)據(jù)格式和目的數(shù)據(jù)格式,比如從文本格式轉(zhuǎn)換為XML格式？交易特征：哪些處理要采用兩階段提交；是否需要多個(gè)消息組成一個(gè)交易；是否要保證消息之間的處理順序；適配器的情況：對于一些特殊系統(tǒng),是否已經(jīng)具備現(xiàn)成的適配器；適配器是單向的還是雙向的；消息通信的模式：是SendandForget、Request/Reply還是Pub/Sub?針對ESB的非功能性需求,我們要確認(rèn)：1.ESB平臺(tái)的擴(kuò)展性和高可用性需求,包括HA和集群等；2.ESB平臺(tái)的性能需求,主要包括系統(tǒng)間數(shù)據(jù)交換的頻率,要交換的數(shù)據(jù)的大小<消息大小將直接對效率造成影響>；峰值時(shí)候?qū)SB數(shù)據(jù)吞吐量、響應(yīng)時(shí)間的要求等；3.哪些交易要保證數(shù)據(jù)傳輸?shù)母呖煽啃裕?.ESB平臺(tái)的可管理性需求,如服務(wù)的生命周期管理,ESB平臺(tái)的維護(hù)和管理；如果企業(yè)已經(jīng)設(shè)立了SOA管控方面的規(guī)范,那么要遵從規(guī)范的制約,比如要考慮是否有規(guī)定的命名規(guī)則,企業(yè)是否有企業(yè)級(jí)的數(shù)據(jù)規(guī)范和底層通訊協(xié)議的規(guī)范等；5.安全性方面的要求：是否采用SSL傳輸加密,是否對消息進(jìn)行加密/解密處理等；6.錯(cuò)誤處理和日志以及平臺(tái)本身的運(yùn)行監(jiān)控等方面的要求等。ESB的方案設(shè)計(jì)方案設(shè)計(jì)的主要內(nèi)容包括：ESB涉及IT應(yīng)用環(huán)境分析,定義ESB與相關(guān)應(yīng)用的接口模式；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)的服務(wù)流設(shè)計(jì),涉及路由、轉(zhuǎn)換和映射等；ESB的同步、異步或者發(fā)布/訂閱模式設(shè)計(jì)；ESB平臺(tái)的接入渠道和數(shù)據(jù)接口設(shè)計(jì),包括XML/JMS、SOAP/HTTP、EDI/MQ等；ESB相關(guān)的適配器設(shè)計(jì),包括技術(shù)適配器或者自開發(fā)的適配器；ESB平臺(tái)的容錯(cuò)和重試機(jī)制設(shè)計(jì),包括日志等的統(tǒng)一管理等；圖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ù)處理流程以及服務(wù)的注冊和管理等方面的內(nèi)容。其中通訊協(xié)議接入和轉(zhuǎn)換是指對各種被集成的應(yīng)用系統(tǒng)的通訊協(xié)議的支持和轉(zhuǎn)換能力,例如HTTP、JMS、Socket、FTP等；數(shù)據(jù)接入和轉(zhuǎn)換是指對各種被集成的應(yīng)用系統(tǒng)提供的數(shù)據(jù)格式的支持和轉(zhuǎn)換能力,例如XML、SOAP、自定義格式以及符合某些行業(yè)標(biāo)準(zhǔn)的專有格式〔SWIFT、EDI、HL7等；數(shù)據(jù)處理流程是指路由、格式轉(zhuǎn)換、數(shù)據(jù)庫讀寫等對數(shù)據(jù)的各種處理；統(tǒng)一服務(wù)注冊存儲(chǔ)管理是指對服務(wù)的注冊、發(fā)布、查詢,以及對運(yùn)營時(shí)服務(wù)的管控,并且提供服務(wù)運(yùn)營狀態(tài)的統(tǒng)計(jì)分析數(shù)據(jù)。ESB的組件模型圖2.ESB組件模型圖2給出了一個(gè)ESB組件模型的示例,其中包含的各主要組件及其功能如下：1.MessageBrokerRuntime組件提供消息路由、格式轉(zhuǎn)換、消息日志等操作的運(yùn)行時(shí)環(huán)境。該運(yùn)行環(huán)境由IBMMessageBroker提供；2.MessagingBrokerInstance組件是處理基于MQ消息業(yè)務(wù)請求的容器。它是作為一個(gè)Broker實(shí)例運(yùn)行在MessageBrokerRuntime上的。該實(shí)例提供了MQ消息的業(yè)務(wù)請求處理器、服務(wù)日志、服務(wù)定位等功能的運(yùn)行容器；3.WebServiceBrokerInstance組件是處理基于WebService的業(yè)務(wù)請求的容器,它是作為一個(gè)Broker實(shí)例運(yùn)行在MessageBrokerRuntime上的。該實(shí)例提供了WebService的業(yè)務(wù)請求處理、服務(wù)日志、以及服務(wù)定位等功能。4.EventBrokerInstance組件是平臺(tái)內(nèi)部處理Pub/Sub事件的容器。它是作為一個(gè)Broker實(shí)例運(yùn)行在MessageBrokerRuntime上的。該容器提供了EventHandler組件的運(yùn)行環(huán)境,將基于MQ/JMS的事件分發(fā)到不同平臺(tái)組件的目標(biāo)隊(duì)列上。5.MessageHandler組件是處理基于MQ消息的業(yè)務(wù)請求,包括消息解析、格式轉(zhuǎn)換,服務(wù)鑒權(quán)與認(rèn)證、服務(wù)路由、服務(wù)日志等功能。MessageHandler組件處理MQ消息的典型流程如下：首先對MQ消息進(jìn)行解析,對解析后的業(yè)務(wù)請求進(jìn)行分析,之后通過Authentication與Authorization組件判斷該請求者的業(yè)務(wù)請求是否可以進(jìn)行后續(xù)處理；通過ServiceLocating組件對該業(yè)務(wù)請求進(jìn)行服務(wù)定位與路由；將基于MQ的業(yè)務(wù)請求消息轉(zhuǎn)換成WebService的業(yè)務(wù)請求消息；通過ServiceLogging組件對整個(gè)業(yè)務(wù)請求進(jìn)行日志記錄；返回業(yè)務(wù)請求處理結(jié)果給業(yè)務(wù)發(fā)起者,如果失敗,返回錯(cuò)誤消息。6.WebServiceHandler組件是處理基于WebService的業(yè)務(wù)請求,與MessageHandler組件功能類似,也包括消息解析、格式轉(zhuǎn)換,服務(wù)鑒權(quán)與認(rèn)證、服務(wù)路由、服務(wù)日志等功能。WebServiceHandler組件處理WebService請求的典型流程如下：首先對WebService請求消息進(jìn)行解析,對解析后的業(yè)務(wù)請求進(jìn)行分析,之后通過Authentication與Authorization組件判斷該請求者的業(yè)務(wù)請求是否可以進(jìn)行后續(xù)處理；通過ServiceLocating組件對該業(yè)務(wù)請求進(jìn)行服務(wù)定位與路由；通過ServiceLogging組件對整個(gè)業(yè)務(wù)請求進(jìn)行日志記錄；返回業(yè)務(wù)請求處理結(jié)果給業(yè)務(wù)發(fā)起者,如果失敗,返回錯(cuò)誤消息。7.EventHandler組件實(shí)現(xiàn)對Pub/Sub的處理。8.ServiceLocating組件負(fù)責(zé)根據(jù)業(yè)務(wù)請求定位具體的服務(wù)提供者。ServiceLocating通過對服務(wù)目錄的查詢選擇適合的服務(wù)進(jìn)行后續(xù)的調(diào)用,該查詢工作可以通過實(shí)時(shí)的服務(wù)目錄查詢獲得結(jié)果。9.ServiceLogging組件負(fù)責(zé)記錄整個(gè)業(yè)務(wù)請求處理過程中的情況,該組件的實(shí)現(xiàn)可以通過文件或者數(shù)據(jù)庫的方式。10.Authentication組件負(fù)責(zé)對業(yè)務(wù)請求者進(jìn)行鑒權(quán),判斷該業(yè)務(wù)請求者是否可以訪問平臺(tái)服務(wù),該鑒權(quán)的工作在企業(yè)服務(wù)總線的外部進(jìn)行,Authentication組件只是調(diào)用外部功能完成。11.Authorization組件判斷業(yè)務(wù)請求者是否具備訪問某特定服務(wù)的權(quán)限,該驗(yàn)證權(quán)限的工作在企業(yè)服務(wù)總線的外部進(jìn)行,Authorization組件只是調(diào)用外部功能完成。以處理基于MQ消息輸入為例,ESB的組件交互圖如圖3所示：圖3.ESB組件交互圖ESB方案設(shè)計(jì)時(shí)的最佳實(shí)踐根據(jù)我們以往項(xiàng)目設(shè)計(jì)和開發(fā)時(shí)的一些經(jīng)驗(yàn),我們建議進(jìn)行ESB的方案設(shè)計(jì)時(shí)要遵循下述最佳實(shí)踐：確定標(biāo)準(zhǔn)的使用：使用與否、使用到什么程度；確定在ESB上實(shí)現(xiàn)的業(yè)務(wù)邏輯：ESB是一個(gè)服務(wù)路由和轉(zhuǎn)換中心,而不是一個(gè)應(yīng)用服務(wù)器,因此它并不能取代應(yīng)有服務(wù)器。復(fù)雜的消息解析和轉(zhuǎn)換相比簡單的路由操作所需消耗的成本要高的多,因此在ESB上應(yīng)該主要考慮路由、格式轉(zhuǎn)換、服務(wù)調(diào)用等問題,而對于數(shù)據(jù)本身的處理應(yīng)該交給相應(yīng)的應(yīng)用來完成；確定消息格式：從標(biāo)準(zhǔn)化的角度而言,XML當(dāng)然是首選,但是從解析/處理性能、行業(yè)標(biāo)準(zhǔn)以及對現(xiàn)有應(yīng)用的最大兼容性的角度而言,可能會(huì)采用某些特定格式,例如EDI、SWITF、平文本或者自定義格式等；區(qū)別消息頭和消息體：把數(shù)據(jù)的Meta-data,例如：安全相關(guān)的信息、日志的等級(jí)、請求端的標(biāo)識(shí)等放在消息頭中,而不要放在消息體中。這樣可以很容易地改變其內(nèi)容及其對其的處理邏輯。在ESB中只處理消息頭,避免對消息體的解析；設(shè)計(jì)時(shí)參考ESB相關(guān)的成熟Patterns；使用服務(wù)注冊庫：如需要服務(wù)Endpoint的查找：推薦從服務(wù)注冊中心進(jìn)行查找,這樣的好處在于：服務(wù)提供者可以容易地發(fā)布新的服務(wù),服務(wù)提供者和ESB之間的耦合度可以更低,通過關(guān)于服務(wù)本身的Metadata來進(jìn)行服務(wù)的查找和路由；注重性能和高可用性的考慮；在必須的情況下考慮交易完整性；適配器的采用：應(yīng)用系統(tǒng)通過適配器實(shí)現(xiàn)與ESB的雙向交互,適配器主要分為技術(shù)適配器、應(yīng)用適配器兩種,適配器的物理部署可以與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è)與合作伙伴等的外部連接；再如：企業(yè)內(nèi)部可能存在若干個(gè)部門級(jí)ESB和一個(gè)全企業(yè)ESB；確定服務(wù)版本控制策略；確定端到端的QoS準(zhǔn)則；注重安全性；確定IT部門ESB平臺(tái)的負(fù)責(zé)主體,長期的投入。ESB的安全性考慮對于ESB的安全性考慮,主要有兩種方式,第一種方式是通過ESB內(nèi)部的Mediation節(jié)點(diǎn)來進(jìn)行服務(wù)請求者的認(rèn)證/授權(quán)；另一種是調(diào)用一個(gè)外部服務(wù)進(jìn)行服務(wù)請求者的認(rèn)證/授權(quán),如圖4所示,圖中給出了這兩種方式的示意圖,具體實(shí)施時(shí)可以進(jìn)行選擇。圖4.ESB的兩種安全實(shí)現(xiàn)方式運(yùn)行在ESB平臺(tái)上的服務(wù)的管理和監(jiān)控當(dāng)一個(gè)企業(yè)開始它的SOA之旅時(shí),開始階段通常會(huì)選取一個(gè)具體的項(xiàng)目進(jìn)行SOA的嘗試,然后便會(huì)逐步走向全企業(yè)采納,這時(shí),大多數(shù)企業(yè)都會(huì)面臨一個(gè)問題,那就是服務(wù)越來越多,對這些服務(wù)目錄的管理出現(xiàn)了很多問題,例如：所有與服務(wù)相關(guān)的信息是如何被管理的,包括存儲(chǔ)、管理、維護(hù)、存取等？服務(wù)請求者如何決定使用哪個(gè)服務(wù)？服務(wù)請求者如何定位服務(wù)的Endpoint？當(dāng)服務(wù)信息發(fā)生改變時(shí)如何得到通知？因此我們建議用戶在盡可能早的情況下考慮服務(wù)注冊中心的建設(shè),所謂服務(wù)注冊中心是一個(gè)企業(yè)范圍內(nèi)的服務(wù)信息的存儲(chǔ)庫,該存儲(chǔ)庫存儲(chǔ)了企業(yè)中注冊的服務(wù)和服務(wù)相關(guān)的信息,它的主要功能包括：采用集中的方式來管理服務(wù)相關(guān)的信息<Interface,ServiceLocation,ServiceSpecification…>,為服務(wù)元數(shù)據(jù)同時(shí)提供"注冊中心"功能,允許用戶存儲(chǔ)、管理和查詢包含服務(wù)描述的服務(wù)元數(shù)據(jù)構(gòu)件〔WSDL、XSD、WS-Policy、SCDL或XML文檔；提供服務(wù)的治理功能,實(shí)現(xiàn)整個(gè)服務(wù)生命周期的管理；提供服務(wù)間依賴、包容關(guān)系的管理；提供分類<Categorization>和版本控制<Versioning>等功能；提供服務(wù)發(fā)現(xiàn)和通知等能力等。除了服務(wù)注冊中心的考慮之外,我們還要考慮對服務(wù)的管理。服務(wù)不僅具有特定的功能,還應(yīng)該滿足一些諸如性能、可用性、安全性等QoS指標(biāo)。服務(wù)響應(yīng)的快慢、什么時(shí)間可用、可以被誰調(diào)用、在某個(gè)時(shí)間段里能被調(diào)用多少次、哪些事件要記錄日志,這些都是服務(wù)管理要考慮的問題。通過服務(wù)注冊中心和服務(wù)監(jiān)控平臺(tái)的有機(jī)配合,我們可以根據(jù)服務(wù)的響應(yīng)時(shí)間、服務(wù)可用與否等策略來實(shí)現(xiàn)對服務(wù)的動(dòng)態(tài)訪問。讓我們來看一個(gè)例子：圖5.使用服務(wù)監(jiān)控平臺(tái)之前ESB的服務(wù)請求和響應(yīng)圖6.使用服務(wù)監(jiān)控平臺(tái)之后ESB的服務(wù)請求和響應(yīng)如圖5和圖6所示,我們可以利用服務(wù)監(jiān)控平臺(tái)對服務(wù)進(jìn)行監(jiān)控和統(tǒng)計(jì)分析,從而使ESB平臺(tái)可以根據(jù)服務(wù)提供者的性能優(yōu)劣來動(dòng)態(tài)地綁定和調(diào)用高性能的服務(wù),其過程如下：服務(wù)請求者請求"PurchaseOrder"服務(wù)服務(wù)注冊庫查找到服務(wù)提