鐵手劍譜

2.2企業(yè)集成的目前狀態(tài)

這一節(jié)將詳細(xì)討論，今天各個(gè)企業(yè)應(yīng)用怎樣進(jìn)行集成、或者怎樣沒有集成。還包括對今天很多組織中很流行的集成方式：偶然架構(gòu)的討論。

2.2.1 企業(yè)大都連接不善

在過去二十年以來，無數(shù)分布式計(jì)算模型一一登場：包括 DCE、CORBA、DCOM、MOM、 EAI Broker、J2EE、Web Services、.NET。 然而，跡象表明，不管采用何種技術(shù)，只有很少數(shù)企業(yè)的應(yīng)用時(shí)很好連通的。按照來自 Gartner 公司的一個(gè)研究報(bào)告[1]，這個(gè)數(shù)字少于10%。

關(guān)于應(yīng)用的連通性，其他的統(tǒng)計(jì)數(shù)結(jié)果更令人吃驚，— 只有 15% 的應(yīng)用的集成采用了正式的集成中間件。其余則使用 ETL 和批量文件傳輸技術(shù)，其主要以手工編寫的腳本和其他定制方案為基礎(chǔ)。關(guān)于 ETL 和批量文件傳輸?shù)母嘈畔ⅲ约八麄兿嚓P(guān)的問題，我們在第9章討論。

2.2.2 偶然架構(gòu)

Gartner 15% 統(tǒng)計(jì)值提供一個(gè)關(guān)于當(dāng)今的集成狀態(tài)的一個(gè)令人深思的數(shù)據(jù)。那么其他85% 的應(yīng)用是如何連接的呢? 一種在今天的企業(yè)中普遍存在的情形，我將其稱為是“偶然架構(gòu)”。所謂偶然架構(gòu)就是沒有人公開宣布創(chuàng)造的；相反，是多年積累的一種“就事論事”的解決方案。在一個(gè)偶然架構(gòu)中，公司的應(yīng)用被永遠(yuǎn)鎖定在一個(gè)不靈活的剛性基礎(chǔ)架構(gòu)之上。然后他們又被視為是信息“地牢”，因?yàn)榧苫A(chǔ)設(shè)施不能適應(yīng)新的業(yè)務(wù)需求。 (圖 2-1)

大多數(shù)集成嘗試都從某個(gè)深思熟慮的設(shè)計(jì)開始，但是經(jīng)過一段時(shí)間后，其他的部分好像都各就各位地“集成”了，但是手工編寫的代碼卻早已飄移出原來的內(nèi)容之外。經(jīng)過逐漸進(jìn)行的螺栓和補(bǔ)丁，所謂整合的系統(tǒng)已經(jīng)失去了其原來的設(shè)計(jì)完整性，尤其是如果系統(tǒng)是被很多的人來維護(hù)的，而他們對最初的設(shè)計(jì)意圖可能沒有很好地溝通。事實(shí)上，這種“就事論事”的方法將完全失去集成的一致性，因?yàn)楣こ處熆倢⑹?#8220;只是做一點(diǎn)點(diǎn)修改”作為解決問題的權(quán)益之計(jì)。最后甚至對找出那些地方做了修改都變得非常困難，更不要說要理解這些結(jié)果導(dǎo)致了那些方面的副作用影響。在一個(gè)部署系統(tǒng)中，這可能會對你的業(yè)務(wù)造成損失慘重的悲慘結(jié)果。

對集成遵守標(biāo)準(zhǔn)能夠?yàn)槟銊?chuàng)建一個(gè)針對所期望功能的基線來遵從。如果基礎(chǔ)設(shè)施是專有的， 不基于標(biāo)準(zhǔn)的，那么隨時(shí)間變化保持計(jì)劃的設(shè)計(jì)和指導(dǎo)原則就變成棘手問題。雖然也可以構(gòu)造專有的平臺并且變通規(guī)則，但是這通常又導(dǎo)致更加“多樣性”的后果，結(jié)果更加鎖定于其上。然而，你應(yīng)該記住的是簡單地遵守標(biāo)準(zhǔn)并不必然地阻止你構(gòu)建一個(gè)偶然架構(gòu)。

圖表 2?1 偶然架構(gòu)將永遠(yuǎn)使公司的應(yīng)用成為“信息發(fā)射井”

在偶然架構(gòu)背后的技術(shù)是各不相同的。圖 2-1中的實(shí)線、虛線和點(diǎn)劃線表示了連接應(yīng)用的不同技術(shù)。這些技術(shù)可能包括 FTP 文件傳輸、直接的socket連接 、專有的MOM、以及有時(shí)是 CORBA 或其他類型的遠(yuǎn)程過程調(diào)用(RPC) 機(jī)制。某些定向的點(diǎn)對點(diǎn)解決方案可能已經(jīng)使用了XML信封定義，或者基于SOAP或者其他什么機(jī)制的技術(shù)，來為集成的應(yīng)用之間承載數(shù)據(jù)。

圖中間的集成Broker表示了在部門級的層次連接應(yīng)用的一個(gè)島嶼。然而這并不意味著它能夠連接任何事物。集成Broker通常只是結(jié)交給基礎(chǔ)設(shè)施中的某一塊，因此資金豐富的項(xiàng)目可能會取得適度的成功，但是它們再也不能與其它所承諾的部分進(jìn)行很好的集成。

偶見架構(gòu)表現(xiàn)為得到一個(gè)剛性的，不能對集成提供一致的、持久的基礎(chǔ)設(shè)施。它不能如其應(yīng)該達(dá)到的效果那樣很好地解決你的組織性的問題。要改變偶然架構(gòu)一直以來就是個(gè)挑戰(zhàn)，因?yàn)辄c(diǎn)對點(diǎn)的解決方案的數(shù)量不斷在增長。這通常也意謂著應(yīng)用之間的互相依賴性是緊密耦合的。使應(yīng)用中的數(shù)據(jù)的表現(xiàn)的修改意謂著你還必須修改共享該數(shù)據(jù)的其他所有應(yīng)用。這就限制你快速地改變你的業(yè)務(wù)流程，以適應(yīng)變化了的或者新的業(yè)務(wù)機(jī)會。這些緊密耦合的、硬連接的接口不僅僅是偶然架構(gòu)的問題。因?yàn)榭刂屏鳌I(yè)務(wù)應(yīng)用之間的通信的編排被硬編碼進(jìn)應(yīng)用本身之中，這進(jìn)一步導(dǎo)致了復(fù)雜化。這些都增加了系統(tǒng)之間的緊密耦合和脆弱性，使變更業(yè)務(wù)流程更加困難，并且導(dǎo)致了廠商所定。

2.2.2.1 部門和組織問題

偶然架構(gòu)的先天技術(shù)不足隊(duì)組織中的人力協(xié)調(diào)問題具有推波助瀾的作用。不管問題是緊密耦合的接口還是硬編碼的流程編排，要想回頭或者對其進(jìn)行較大的翻新改造簡直是一件恐怖的事情。這經(jīng)常需要安排大量的會議，和屬于不同項(xiàng)目的不同的開發(fā)組的人們開會，就緊緊對要做什么以及何時(shí)做這類的問題達(dá)成一致。如果應(yīng)用，以及他們分屬的開發(fā)項(xiàng)目組，分別處于不同的地理位置和時(shí)間區(qū)，應(yīng)用改變所需的協(xié)調(diào)問題則會變得更加困難。

有時(shí)某些應(yīng)用程序被視為“遺留”系統(tǒng)，對他們你是不愿意或不能夠?qū)ζ溥M(jìn)行多少修改，因?yàn)樗鼈円呀?jīng)進(jìn)入維護(hù)模式。我們通常說，“遺留系統(tǒng)”的一個(gè)定義就是那些你昨天剛安裝的系統(tǒng)。即使你對自己開發(fā)的應(yīng)用具有完全的訪問和源代碼的控制權(quán)，當(dāng)開發(fā)人員繼續(xù)進(jìn)行其他項(xiàng)目或離開公司的時(shí)候，對其進(jìn)行修改也是非常困難的。我們將會在第 4 章中看到， ESB 大大地減少了隨時(shí)間變化，修改數(shù)據(jù)模式和格式所帶來的影響。

2.2.2.2 逃離偶然架構(gòu)

即使你已經(jīng)對跟蹤和修改應(yīng)用數(shù)據(jù)及其接口建立了良好的公司實(shí)踐，偶然架構(gòu)仍然還有其他缺點(diǎn)。使用不同的連接技術(shù)意謂著安全模型可能是混雜的，所以沒有確定的方式來建立和執(zhí)行公司級的安全策略。 對插入新的應(yīng)用沒有一致的 API可以依賴，而且沒有基礎(chǔ)來在棋上構(gòu)建公司關(guān)于集成的最佳實(shí)踐。最近與一些領(lǐng)導(dǎo)的專家進(jìn)行了交流，總結(jié)了偶然架構(gòu)的下列各項(xiàng)問題:

• 不可靠性

應(yīng)用之間的通信或許能得益于異步的消息的可靠性。如果一個(gè)大型業(yè)務(wù)流程中的某兩個(gè)應(yīng)用之間的通信連接失敗，整個(gè)業(yè)務(wù)流程可能會事務(wù)性地返回或者重啟。我們將會在第5章學(xué)到更多有關(guān)松散耦合的、異步的可靠消息的更多內(nèi)容。

• 性能和可伸縮性分析

不管你是否你已經(jīng)有了一個(gè)預(yù)先的性能規(guī)劃并且試圖分析一個(gè)現(xiàn)有的性能問題，由于偶然架構(gòu)的許許多多的子系統(tǒng)和他們各自的運(yùn)行特征，這個(gè)工作是極其困難的。通常的做法是采用混雜的、“投入資源到其中，直到它能正確運(yùn)行”式的解決方法，這將造成磁盤、處理器、內(nèi)存等上面的過度開支。

• 總體排錯(cuò)

沒有哪個(gè)單一方法能夠提供充分的診斷和報(bào)告能力。 意外架構(gòu)需要很多具有很高能力的維護(hù)人員圍著所有有缺陷得生產(chǎn)系統(tǒng)轉(zhuǎn)，這將導(dǎo)致整體擁有成本 (TCO)的急劇上升。各部分實(shí)現(xiàn)的方式差異越大，在其失效時(shí)需要用來解決它們的問題的專家經(jīng)驗(yàn)就越寬。另外，建立一個(gè)基線來描述期望的正確行為也是一個(gè)挑戰(zhàn)。

• 冗余和彈性

沒有任何方式能夠保證這個(gè)泥潭中的所有組建都能夠滿足你的關(guān)于可接受的冗余、彈性和容錯(cuò)度的定義。這意謂著要為依賴于后段系統(tǒng)的新功能定義可達(dá)到的服務(wù)級別協(xié)議 (SLAs) 是很困難的。

• 帳單漏洞

如果你的系統(tǒng)攜帶又能夠收費(fèi)的帳單數(shù)據(jù) ( 比如電信)，那么賬單數(shù)據(jù)的利息就可以被丟失在偶然架構(gòu)之中。因此，你可能會損失收入并且還一點(diǎn)都不知道。

• 監(jiān)控和管理

沒有一致的方法來監(jiān)控和管理一個(gè)偶然架構(gòu)。假定你的整合應(yīng)用系統(tǒng)必須運(yùn)行 24/7 ，而且你的職員負(fù)責(zé)關(guān)注運(yùn)行監(jiān)控工具，并且做出糾正。這些工具將不會以相同的方式工作，那么在無數(shù)不同的小方案的基礎(chǔ)上進(jìn)行培訓(xùn) ( 和再培訓(xùn)) 將是非常昂貴的事情。簡單地安裝企業(yè)級的運(yùn)行管理工具并不能自動地將自省能力提供給集成基礎(chǔ)設(shè)施，并且偶然架構(gòu)通常并不能提供所有可能需要的控制點(diǎn)。

總而言之，偶然架構(gòu)表現(xiàn)為一種剛性的、高成本的基礎(chǔ)設(shè)施，并且不能滿足你的組織變更的需要，還要承受以下缺點(diǎn)的痛苦：

•  緊密耦合的、易碎的、對變更不靈活的
•  因?yàn)槎鄠€(gè)點(diǎn)對點(diǎn)解決方案導(dǎo)致的昂貴的維護(hù)負(fù)擔(dān)
•  修改一個(gè)應(yīng)用程序可能影響其他很多應(yīng)用
•  路由邏輯是硬編碼到應(yīng)用程序之中的
•  沒有通用的安全模型；安全是混雜的
•  沒有通用的 API(通常)
•  沒有通用的通信協(xié)議
•  沒有建立和構(gòu)建最佳實(shí)踐的通用基礎(chǔ)
•  難以支持異步處理
•  不可靠
•  沒有對應(yīng)用和集成組件的健康監(jiān)控和部署管理

如你所知，偶然架構(gòu)的創(chuàng)建已經(jīng)有些年頭了，要替換和解決它并不是一蹴而就的事情。隨著繼承項(xiàng)目的需求的增加，解決方案應(yīng)該更加柔性的、簡單、以及運(yùn)行便宜，而不是其他什么東西。偶然架構(gòu)給了你的那些敏捷的競爭者得到好處，而你卻不能夠在一個(gè)合理的時(shí)間范圍內(nèi)實(shí)現(xiàn)新的業(yè)務(wù)機(jī)會。

你需要一個(gè)內(nèi)聚的架構(gòu)，面向?qū)嵺`、標(biāo)準(zhǔn)來解決著大量的問題。ESB 提供了架構(gòu)和基礎(chǔ)設(shè)施，并且使你能夠逐個(gè)項(xiàng)目的基礎(chǔ)上采用它。采用 ESB 并不是全有或全無，推倒重來式的方式。而是，你可以漸進(jìn)式地采用它，同時(shí)還能利用你的現(xiàn)有資產(chǎn)-包括偶然架構(gòu)和集成Broker，以一種“留下而分層”的方式。

2.2.3 ETL，批量傳輸，和 FTP

提取、轉(zhuǎn)換、和載入 (ETL) 技術(shù)，比如 FTP 文件傳輸和每夜批處理式的集成在今天仍然是最流行的方法。

這通常涉及到將位于各個(gè)應(yīng)用中的數(shù)據(jù)打包然后上傳這樣的操作。問題是有很大的可能在應(yīng)用間的數(shù)據(jù)失去同步。一個(gè)失敗的打包上傳的處理程序可能要花上一天的時(shí)間。在京及和業(yè)務(wù)全球化的情況下，系統(tǒng)以24/7 的方式運(yùn)行，再也沒有了“夜晚”的概念，那你得批處理又該在何時(shí)執(zhí)行呢？

其他問題也可能與每夜的批處理相關(guān)。因?yàn)榕幚淼姆磻?yīng)期問題，在分析關(guān)鍵業(yè)務(wù)數(shù)據(jù)的時(shí)候，最好的情形是24 小時(shí)輪轉(zhuǎn)時(shí)間。這一延遲可能嚴(yán)重地阻礙你對隨時(shí)變化的業(yè)務(wù)事件進(jìn)行反應(yīng)的能力。

有時(shí)，一次跨越多個(gè)面向批處理系統(tǒng)的端對端處理處理甚至?xí)ㄙM(fèi)一整個(gè)星期才能完成。處理從源頭到目標(biāo)的數(shù)據(jù)的總體潛伏反應(yīng)期完全阻止了收集具有意義的，反應(yīng)目前業(yè)務(wù)情形的數(shù)據(jù)的洞察力。比如，在供應(yīng)鏈的場景中，這將導(dǎo)致你永遠(yuǎn)不知道你的庫存的真實(shí)狀態(tài)。

第 9 章將會呈現(xiàn)一個(gè)通過FTP進(jìn)行成批傳輸?shù)募夹g(shù)和業(yè)務(wù)意義的案例研究，并且會研究ESB如何能幫助你逃脫偶然架構(gòu)的困境。

2.2.4 集成Broker

集線器-和-插頭的集成Broker，或者EAI Broker，提供了偶然架構(gòu)的替代。集成Broker是從上世紀(jì)90年代出現(xiàn)在，現(xiàn)在已經(jīng)被植入到MOM主干或應(yīng)用服務(wù)器平臺之中。

集成Broker市場的一些公司包括:

• SeeBeyond
• IBM
• webMethods
• TIBCO
• Ascential (Mercator)
• BEA (more recently)
• Vitria

集成Broker能夠使用一個(gè)集線器-和-插頭架構(gòu)幫助偶然架構(gòu)提供應(yīng)用之間的集中路由。此外，他們還允許使用業(yè)務(wù)程序管理 (BPM) 軟件將業(yè)務(wù)流程從下層的集成代碼中分離出來。到此為止，所有的都是好消息。

然而，對集成Broker方式也有缺點(diǎn)。一個(gè)集線器-和- 插頭拓?fù)洳辉试S對局部集成域之上進(jìn)行局部控制。構(gòu)建在一個(gè)集線器-和-插頭拓?fù)渲系腂PM 不能夠建立跨越部門和業(yè)務(wù)單位的業(yè)務(wù)流程極其編排。 集成Broker也可能受限于下面的MOM不能越過物理的LAN網(wǎng)段和防火墻的能力限制。

有許多公司已經(jīng)在其集成策略中采用了集線器-和-插頭的集成Broker解決方案。 這些技術(shù)具有較高的成本，并且成功也值得懷疑。1990 年代后期的昂貴集成Broker項(xiàng)目已經(jīng)取得了名義上的成功，但是將組織置于專有的集成域的井中。一項(xiàng)Forrester在2001 年十二月發(fā)布的研究報(bào)告[2] 展示了下列各項(xiàng)統(tǒng)計(jì):

•  集成項(xiàng)目平均 20+ 個(gè)月才完成
•  少于 35% 的項(xiàng)目能夠準(zhǔn)時(shí)和在預(yù)算內(nèi)完成
•  35% 的軟件維護(hù)預(yù)算被花費(fèi)在維護(hù)點(diǎn)對點(diǎn)應(yīng)用連接之上
•  在 2003 年， 全球 3500 家企業(yè)平均期望花費(fèi)六百四十萬美元到集成項(xiàng)目上

這項(xiàng)研究還是在EAI 在它的最尖峰的時(shí)候進(jìn)行的，而且?guī)缀鯖]有跡象表明這一數(shù)字在那時(shí)候起之后得到了改善。注意一年六百四十萬美元是公司會在集成項(xiàng)目上花費(fèi)的平均數(shù)的一個(gè)預(yù)測。當(dāng)于這些公司的領(lǐng)導(dǎo)們交流這些問題的時(shí)候，我進(jìn)行了一個(gè)一般性的求證。

照今天的預(yù)算標(biāo)準(zhǔn)來看，EAI Broker項(xiàng)目是很昂貴的。集成軟件費(fèi)用很貴的，通常單獨(dú)對于軟件許可費(fèi)用，每個(gè)項(xiàng)目的價(jià)格范圍就在從 $250,000 到一百萬美元不等。這還不算一起的咨詢服務(wù)組件，而這個(gè)組件的價(jià)格往往是軟件許可費(fèi)用的5到12倍。

集成Broker高昂的啟動成本又被另一事實(shí)所進(jìn)一步惡化，即從一個(gè)項(xiàng)目中學(xué)到的知識不能很好地轉(zhuǎn)移到下一個(gè)項(xiàng)目。由于傳統(tǒng)的 EAI Broker技術(shù)的專有特性，通常具有很陡峭的學(xué)習(xí)曲線，對于每個(gè)項(xiàng)目來說，有時(shí)候?qū)?個(gè)月。要試圖彌補(bǔ)這個(gè)負(fù)擔(dān)的通常方式是聘請事前對專有技術(shù)經(jīng)過培訓(xùn)的特別的顧問。當(dāng)然，高特殊性=高價(jià)格。這是高昂咨詢費(fèi)用的一個(gè)重要組成部分( 另一個(gè)大的組成是技術(shù)安裝、配置、部署、和管理的復(fù)雜性)。并且一旦項(xiàng)目完成，顧問就不見了。

集成項(xiàng)目的實(shí)現(xiàn)時(shí)間普遍是在 6-18 月之間。這意謂著。根據(jù)事前針對短期設(shè)定的標(biāo)準(zhǔn)、以及項(xiàng)目資金，實(shí)施時(shí)間吃掉了項(xiàng)目原本想要利用的策略性窗囗。

集成Broker的專有性質(zhì)，以及高昂的咨詢費(fèi)用通常導(dǎo)致供應(yīng)商鎖定和重啟后續(xù)項(xiàng)目的巨大成本。這意謂即便對于成功的項(xiàng)目，增長和伸展也是令人恐懼的。而且在你對你的供應(yīng)商或者實(shí)現(xiàn)心生不滿的時(shí)候，你也得面對到底是就目前的情況繼續(xù)走下去，還是選擇完全重新開始，雇用更多的咨詢顧問或者投入另一個(gè)新的學(xué)習(xí)曲線之間左右為難。因?yàn)樗羞@些，一些IT組織通常留下了一些難以再集成到其他項(xiàng)目的“集成孤島”。總而言之，集成Broker已經(jīng)證明是偶然架構(gòu)里面的老套技術(shù)，而并非它的解決方案。

當(dāng)我們更詳細(xì)地討論集成Broker的時(shí)候，我們將看到導(dǎo)致這里所列的問題的技術(shù)屏障。另外，許許多多的非技術(shù)因素也導(dǎo)致了對采用ESB的需求的增長。

[1] [2]來自 Gartner 公司的統(tǒng)計(jì),"集成Broker，應(yīng)用服務(wù)器和 APSs,"10/2002.

[2] [3]來自 Forrester 研究的統(tǒng)計(jì)學(xué),"減少集成費(fèi)用,"12/2001.