談及企業(yè)服務(wù)總線

談及企業(yè)服務(wù)總線（ESB）,在有面向服務(wù)的架構(gòu)（SOA）實施經(jīng)驗的開發(fā)者眼中一定不會陌生。這些年，人們一直在談?wù)撍灾劣行┤苏J為''實施SOA一定需要ESB"，或'只要將ESB架起來了，我們就SOA了”。這些說法有可取之處，也存在片面之嫌，由于業(yè)界對于ESB沒有統(tǒng)一、標準的定義，所以一千個人眼中有一千個“ESB"也就成了情理中的事情了。然而，怎么才能將ESB用好？我們需要清楚地認識ESB在SOA中所扮演的角色，理解哪些工作是ESB的職責之內(nèi)，哪些卻不是。只有正確地認識了ESB的職能，并委以恰當?shù)娜蝿?wù)，才能將它用在刀刃上、發(fā)揮其巨大的能量。事實上，ESB在SOA中扮演著重要的角色，在技術(shù)層解決了SOA的整合問題，耦合了應(yīng)用與應(yīng)用之間的集成邏輯，使得SOA更靈活，更易于擴展，更敏捷。有了ESB，新建的服務(wù)消費者應(yīng)用程序不需要關(guān)心服務(wù)的提供者在哪里，使用何種通訊協(xié)議，與其交互的數(shù)據(jù)是怎樣的……，它只需向ESB發(fā)出請求，使用開放的、標準的通訊協(xié)議。相反，若某個可重用的價值較大的服務(wù)位于某一個遺留系統(tǒng)中，而由于種種原因，該遺留系統(tǒng)不能在短期內(nèi)重寫，此時ESB可以架起該服務(wù)與其使用者之間溝通的橋梁。當然，ESB的作用遠不止這些，業(yè)內(nèi)也有很多討論，本文不再贅述。讀者可在Google上搜索ESBPatterns獲得相關(guān)資料。然而，ESB并非''救世主"，它注定也不可能解決應(yīng)用系統(tǒng)整合中出現(xiàn)的所有問題。道理很簡單，計算機發(fā)展歷史長從沒有出現(xiàn)過一個產(chǎn)品/工具可以滿足所有的應(yīng)用需求，技術(shù)發(fā)展得很快，需求發(fā)展更快，所以技術(shù)永遠跟不上需求。此外，ESB或ESB產(chǎn)品有其特定的適用范圍，它是基礎(chǔ)設(shè)施層的概念/產(chǎn)品，解決的是整合中的常見問題，比如服務(wù)連通、路由、消息豐富、服務(wù)的注冊/查找/發(fā)布等服務(wù)的管理、服務(wù)監(jiān)控和質(zhì)量保證等。ESB不能解決的問題比其能解決的問題多很多。比如，讓它去做人工流程的編排是不合適的，讓它提供門戶類產(chǎn)品那樣的用戶交互也是極其困難的……。筆者支持過許多客戶項目。在這些項目中，有的客戶將ESB用的好，有的則勉強用上，用的功能很簡單，有的則用ESB做一些原本不屬于它該做的工作。在這里，筆者僅從個人的立場，分享自己這些年來積累的ESB實施經(jīng)驗。下面列出筆者?？吹降煌扑]的實施和筆者在實施ESB的過程中積累的一些較好的實踐方式，供讀者參考。同時歡迎批評指正。不推薦實施挾ESB以令外圍應(yīng)用現(xiàn)象：ESB的架構(gòu)師在ESB上設(shè)計一套標準的數(shù)據(jù)接口（通用的XML格式），規(guī)定使用統(tǒng)一的協(xié)議（如WebService/HTTP）。所有的ESB服務(wù)消費者和接入ESB的服務(wù)必須符合該標準。其目的是為了簡化ESB上的開發(fā)工作。這就是一種''挾天子以令諸侯"的做法，因為在實際情況中，可能領(lǐng)導(dǎo)規(guī)定了''所有的服務(wù)必須要經(jīng)過ESB，即便是透傳”。分析：國內(nèi)的ESB實施者大多數(shù)是一些SI/ISV，出于成本/人力或其他個方面的原因，總會有一些架構(gòu)師希望達成這樣一個目標：我能否設(shè)計/實現(xiàn)一個一勞永逸的ESB中間平臺，將來不論哪種服務(wù)都可以方便地接入到ESB上?這是一個很浪漫很理想的目標，但這個目標是不可能實現(xiàn)的。原因有二：其一，仲裁邏輯一般是非常具體的，具體的服務(wù)有具體的整合需求。譬如，一個服務(wù)提供者基于HTTP提供了一個Web服務(wù)WS1,而我們希望將這個服務(wù)通過ESB暴露給兩個客戶端ClientA,ClientB；ClientA使用XML/HTTP訪問服務(wù)，而ClientB卻使用SOAP/JMS訪問該服務(wù)，如圖1所示。有過ESB實施經(jīng)驗的人都能看出里面的仲裁邏輯是非常具體的，我們要考慮的不僅僅是協(xié)議之間的差別，還需要考慮消息格式的差別。其二，如果有這樣的設(shè)計/實現(xiàn)存在，ESB產(chǎn)商為何不把這個特性直接實現(xiàn)了呢？你也許會說產(chǎn)商不理解具體的業(yè)務(wù)，而具體的業(yè)務(wù)是復(fù)雜的，SI/ISV卻了解這些復(fù)雜業(yè)務(wù)。而事實上，ESB解決的更多是技術(shù)層面的工作，業(yè)務(wù)層面的工作大多數(shù)不屬于ESB的范疇，復(fù)雜的業(yè)務(wù)邏輯不是在業(yè)務(wù)系統(tǒng)中實現(xiàn)，就是在其它SOA組件中實現(xiàn)，如流程管理引擎。OAP/JMSClientB八SOAP/HTTPESBOAP/JMSClientB八SOAP/HTTPESBClientA圖1.ESB的主要功能之一是連接異構(gòu)協(xié)議和數(shù)據(jù)。?原因及危害：該實踐出現(xiàn)的根本原因是:沒有認清ESB本身的作用，過分看重了ESB之上的設(shè)計能力。其實，ESB針對的是一個個功能各異的整合邏輯，服務(wù)之間的整合邏輯也是迥異的。所以，一勞永逸的ESB之上的架構(gòu)是不存在的。其危害是：丟失了ESB本身最強大的連通性方面的功能，正式因為需要聯(lián)通的應(yīng)用之間的差異性，才逐漸發(fā)展出了ESB這樣的組件。如果要求所有的外圍應(yīng)用的協(xié)議標準和數(shù)據(jù)標準都統(tǒng)一了（事實上，這是不可能實現(xiàn)的，特別在與第三方應(yīng)用整合時），那么ESB的必要性就遜色不少。?建議：不要試圖實現(xiàn)一個一勞永逸的ESB之上的架構(gòu)，這個架構(gòu)不存在也沒有其存在的必要性。不過，筆者并非反對設(shè)計。實際上，ESB上可以設(shè)計，也可以通過一定的設(shè)計實現(xiàn)某種程度的自動化，靈活性和通用性。舉個例子，某一組功能類似的服務(wù)，對這一組服務(wù)的所有請求必須進行審計、安全加固等操作，對于這一類需求，我們可以事先在ESB上設(shè)計好相應(yīng)的技術(shù)組件/服務(wù)，然后在ESB的仲裁流中間調(diào)用該組件/服務(wù)即可。用ESB實現(xiàn)業(yè)務(wù)流程

現(xiàn)象：有些架構(gòu)師看到ESB支持服務(wù)組合(ServiceComposition)模式，進而認為可用該模式來實現(xiàn)業(yè)務(wù)流程。因此，ESB產(chǎn)品就演變成了BPM產(chǎn)品。分析：如果讀者關(guān)心過ESB的通用使用模式，就會發(fā)現(xiàn)ESB的服務(wù)組合模式(ServiceComposition)與BPM中的服務(wù)編排(ServiceCherography)非常相似，二者都是將細粒度的服務(wù)組合/組裝起來，形成大粒度的服務(wù)，或者業(yè)務(wù)流程。事實上，二者有著本質(zhì)的區(qū)別。其一:ESB是一個偏向技術(shù)層整合的組件，比如將''客戶資料查詢”服務(wù)與“日志”服務(wù)組裝起來，得到的結(jié)果還是“客戶資料查詢”服務(wù)，只是在仲裁流中間插入了一個新的附加功能，即''日志”服務(wù)。BPM中的服務(wù)編排的含義很側(cè)重于業(yè)務(wù)流轉(zhuǎn)的概念。比如'項目立項審批流程”，該流程的實現(xiàn)可能需要來自幾個相關(guān)系統(tǒng)中的服務(wù)的參與，它們可能是'立項申請”，接著是'一級職能經(jīng)歷審批”，然后是'部門經(jīng)理審批"，''財務(wù)審批”等。這些服務(wù)流轉(zhuǎn)起來形成的是一個完整的業(yè)務(wù)流程。其二：ESB上的服務(wù)組合是無狀態(tài)的，ESB運行時會為每個請求建立一個實例來執(zhí)行其仲裁邏輯，請求與請求之間沒有時序關(guān)系，是互不相干的、各自獨立的。相反，BPM上的服務(wù)編排這不一樣，未完成的業(yè)務(wù)流程實例一直會存活在BPM運行時中，存活期可能為一天、一周、甚至1個月或更長；請求與請求之間可能存在著一定的關(guān)聯(lián)性，比如對與一個項目(相同的項目ID)的立項審批流程，一級職能經(jīng)理、部門經(jīng)理和財務(wù)對流程發(fā)出的請求都是針對同一運行時實例的。原因及危害：除了其他非技術(shù)的因素外，導(dǎo)致該實踐的一個重要原因是：混淆了ESB的服務(wù)組合與BPM的服務(wù)編排兩個概念。危害：讓ESB實現(xiàn)BPM，特別是長運行的流程時，雖然在技術(shù)上可以實現(xiàn)，但是這違背了ESB產(chǎn)品的設(shè)計理念，會大大影響其ESB運行時的整體運行效率。建議：認清技術(shù)上的服務(wù)組合與服務(wù)編排之間的差異，分析每個產(chǎn)品所屬的概念范疇，選擇合適的產(chǎn)品解決合適的問題。用ESB用ESB實現(xiàn)大數(shù)據(jù)?現(xiàn)象：將ESB用于在兩個系統(tǒng)間傳輸大量數(shù)據(jù)，比如傳輸視頻文件、大文檔等。在這些場景中傳輸?shù)男畔?文件/消息有一個共同的特點：只使用了ESB提供的連通性功能，而沒有使用其他功能，如消息解析，轉(zhuǎn)換，路由等。分析：為了在ESB市場上搶占有利位置，各大廠商提供的ESB產(chǎn)品的能力越來越強。ESB產(chǎn)品的設(shè)計是支持消息從一個系統(tǒng)傳到另一個或幾個系統(tǒng)的。所以，一些架構(gòu)師利用ESB產(chǎn)品本身提供的此項功能架設(shè)了一個數(shù)據(jù)傳輸總線。可是ESB并不適合完成該項功能，雖然它可以實現(xiàn)這一功能，但這并非最佳實踐。ESB作為企業(yè)級的服務(wù)聯(lián)通、管理平臺，需要穿透ESB的服務(wù)應(yīng)該是企業(yè)內(nèi)重用可能最大、價值最大的那些服務(wù)，應(yīng)用程序?qū)@類服務(wù)的訪問應(yīng)該非常頻繁，因此同一時刻需要ESB支撐的業(yè)務(wù)可能非常繁重。所以，ESB產(chǎn)品的設(shè)計初衷是實現(xiàn)一個無狀態(tài)、高吞吐的服務(wù)總線，為企業(yè)內(nèi)重要的業(yè)務(wù)服務(wù)提供透明、標準、開放的接入能力。原因及危害：這種實踐的原因是過分放大了ESB對數(shù)據(jù)的傳輸能力，如果在ESB傳輸巨大的信息，可能會導(dǎo)致ESB整體性能的下降，損害其他重要服務(wù)的QoS。建議：如果需要傳輸?shù)臄?shù)據(jù)有解析或轉(zhuǎn)換的需求、或者需要根據(jù)數(shù)據(jù)里的信息進行某種路由或其他仲裁邏輯需求時，則建議使用ESB；但如果同時消息體又過與龐大，可以考慮將需要解析的消息與不需解析的數(shù)據(jù)部分進行拆分，通過其他專門的數(shù)據(jù)傳輸平臺去傳輸不需解析的部分，如FTP，數(shù)據(jù)庫備份機制等，而在ESB中實現(xiàn)該傳輸任務(wù)的控制流。服務(wù)要管理起來ESB的一個重要功能是將企業(yè)內(nèi)/合作伙伴處的服務(wù)以開放的、標準的服務(wù)方式暴露出來，使得服務(wù)消費者能夠便利地查找到服務(wù)，以促進服務(wù)的重用、管理。而許多ESB產(chǎn)品不包含服務(wù)的注冊、存儲、發(fā)布、訂閱等功能，這些功能包含UDDI庫中。所以，ESB一般需要一個服務(wù)注冊/存儲庫與之協(xié)作。ESB執(zhí)行各種仲裁邏輯，而注冊庫為ESB提供必要的元數(shù)據(jù)信息。服務(wù)注冊庫可以存儲服務(wù)的元數(shù)據(jù)，包括服務(wù)的描述、功能、版本、輸入/輸出消息的模式、服務(wù)端點、SLA、安全策略等內(nèi)容，這些信息可被ESB用來進行消息格式驗證、服務(wù)的動態(tài)路由、執(zhí)行安全策略和SLA保證等。ESB可以多級實施，可以實現(xiàn)整個企業(yè)級/全國級的ESB，也可以實現(xiàn)部門級/地市級的ESBo服務(wù)消費者應(yīng)該能在注冊庫中找到自己所需要的服務(wù)，獲得調(diào)用該服務(wù)所需的位置、服務(wù)的描述文件、請求/相應(yīng)消息格式等信息。若是沒有注冊庫，則隨著ESB接入的服務(wù)越來越多，仲裁邏輯不斷增加，必將造成服務(wù)管理的混亂。最后抵消了ESB帶來的價值。復(fù)雜的動態(tài)路由規(guī)則應(yīng)服務(wù)化路由是ESB中非常重要的仲裁邏輯之一。路由場景是非常普遍的。譬如，針對不同的客戶提供不同QoS的場景，執(zhí)行時需根據(jù)客戶的類型將其路由到不同執(zhí)行能力的服務(wù)提供者；再比如當響應(yīng)消息到達ESB時，總是需要將該響應(yīng)消息送回最初的服務(wù)請求者處。路由可分為靜態(tài)路由和動態(tài)路由。靜態(tài)路由指得是設(shè)計時已經(jīng)明確路由分支的情況，而動態(tài)路由的路由分支選擇是在運行時動態(tài)確定的。不論是靜態(tài)路由還是動態(tài)路由，路由分支的選擇一定伴隨著一個或一系列決策依據(jù)。決策依據(jù)可簡單如一個If-Else語句，也可以復(fù)雜到需要通過多維決策表并通過多次判斷才能得到最后的路由分支。對于復(fù)雜的路由，推薦將路由規(guī)則的邏輯外部化，并將它服務(wù)化，如圖2所示。如此，仲裁邏輯在分發(fā)消息前可先訪問該路由規(guī)則服務(wù)，從而得到明確的路由結(jié)果。至此，可能有人會問到，“復(fù)雜”與“簡單”如何界定。這個問題沒有統(tǒng)一的規(guī)定，根據(jù)筆者以往的實施經(jīng)驗，如果符合以下條件之一，就可以認為是復(fù)雜的路由規(guī)則：1.判斷維度大于等于22.連續(xù)決策節(jié)點大于等于33.路由分支可能隨時增加或減少ESB*oo規(guī)則［擎ESB改進ESB*oo規(guī)則［擎ESB改進圖2.動態(tài)路由規(guī)則服務(wù)化。將復(fù)雜的動態(tài)路由規(guī)則服務(wù)化的好處簡單明了。首先，讓復(fù)雜的規(guī)則服務(wù)化，可以降低仲裁邏輯的變化性。當規(guī)則發(fā)生改變時，不需要修改仲裁邏輯，而只需更改規(guī)則服務(wù)即可。進一步，如果該規(guī)則服務(wù)是由某種專業(yè)的規(guī)則引擎實現(xiàn)的，更改起來將更加簡單。其二，由于ESB產(chǎn)品的實現(xiàn)與設(shè)計并無業(yè)界的標準，所以基于ESB產(chǎn)品的配置開發(fā)無法在不同產(chǎn)品間互相移植。將規(guī)則服務(wù)化之后，還可減少仲裁邏輯在不同的ESB產(chǎn)品間移植時所需的工作量。最后，規(guī)則的服務(wù)化符合SOA原則，企業(yè)內(nèi)業(yè)務(wù)規(guī)則應(yīng)該以服務(wù)的形式管理起來，以促進規(guī)則的重用。轉(zhuǎn)換邏輯的實現(xiàn)盡量選用XSLT數(shù)據(jù)轉(zhuǎn)換也是仲裁邏輯中非常常見并且重要的功能。同一數(shù)據(jù)在不同的業(yè)務(wù)系統(tǒng)中表現(xiàn)方式可能不一樣，如上文例子中的ClientA訪問服務(wù)WS1的情況，仲裁邏輯需要將XML消息轉(zhuǎn)換為調(diào)用服務(wù)A的SOAP消息。一般而言，大多數(shù)ESB產(chǎn)品都提供了多種數(shù)據(jù)轉(zhuǎn)換的方式，很多產(chǎn)商宣傳中力推的都是''拖拽式”可視化映射的轉(zhuǎn)換方式。該功能聽起來的確很酷，看上去很直觀。但是正如我們前面所說的，ESB是一個偏向技術(shù)層整合的組件，業(yè)務(wù)人員一般不會關(guān)心XML是如何轉(zhuǎn)換成SOAP的。所以，對于開發(fā)者來說，這種'炫”功能并無太大吸引力。更重要的是，他們可能非常習慣于自己的編程語言，如Java、XSLT、ESQL和PHP等，這些語言操作起來要簡單很多。筆者本人就不太喜歡使用可視化隱射的方式去實現(xiàn)數(shù)據(jù)轉(zhuǎn)換的需求，尤其碰到需要循環(huán)運行、復(fù)雜計算等轉(zhuǎn)換邏輯時，在可視化映射上實現(xiàn)起來更加不容易。在此，筆者推薦的方式是使用XSLT實現(xiàn)數(shù)據(jù)轉(zhuǎn)換的功能，如圖3所示。原因如下：首先，XSLT是一個標準的XML轉(zhuǎn)換語言，使用XSLT實現(xiàn)的轉(zhuǎn)換邏輯可很輕易地在不同ESB產(chǎn)品間移植。據(jù)筆者調(diào)查，幾乎所有主流商業(yè)ESB產(chǎn)品都支持XSLT的轉(zhuǎn)換機制。其二，選擇XSLT還可增加ESB之上的架構(gòu)靈活性。因為仲裁邏輯中的轉(zhuǎn)換邏輯是最計算密集型的邏輯，它最消耗CPU，影響整體性能。在這種架構(gòu)中，我們很容易地將此轉(zhuǎn)換邏輯剝離出仲裁邏輯，由一些專門的XML轉(zhuǎn)換加速軟件/硬件(如IBMWebSphereDataPower)來完成這一工作。這樣的設(shè)計可提高架構(gòu)的靈活性，通過分布式計算的方式提高整體計算性能。ESBOOxsltXSLT加速器可演變成ESBOOxsltXSLT加速器可演變成ESB圖3.XSLT實現(xiàn)數(shù)據(jù)轉(zhuǎn)換邏輯及架構(gòu)擴展展望在SOA