系統(tǒng)間通信（34）——被神化的ESB

?

轉(zhuǎn)至：http://blog.csdn.net/yinwenjie

1、概述

從本篇文章開始，我們將花一到兩篇的篇幅介紹ESB（企業(yè)服務總線）技術的基本概念，為讀者們理清多個和ESB技術有關名詞。我們還將在其中為讀者闡述什么情況下應該使用ESB技術。接下來，為了加深讀者對ESB技術的直觀理解，我們將利用Apache Camel一起搭建一個ESB技術的服務實現(xiàn)，雖然這個示例不能把目前主流的ESB服務實現(xiàn)中所有功能模塊都保羅進來，但至少可以讓讀者看到ESB技術核心服務完整的工作方式。

2、為什么需要ESB

2-1、ESB與SOA

2-1-1、SOA

SOA（Service-Oriented Architecture）中文全稱“面向服務的架構”。放在當下的技術環(huán)境（2015/2016年），SOA并不是一個新的概念。但是在SOA剛流行起來的2000年初（SOA的概念最初由Gartner Group在1996年提出），這個架構模型算就是非常流行了。本小節(jié)筆者試圖使用最平實的語言向各位讀者介紹SOA概念中的幾個核心內(nèi)容。

首先SOA是一種架構模式思想，主要圍繞多個“服務”如何進行集成以達到某種目的進行討論。那么SOA中所定義服務是什么意思呢？在業(yè)務系統(tǒng)中被發(fā)布出來供用戶使用，能夠完成一個完整業(yè)務過程的功能，就是服務。

• 服務著眼于完整的業(yè)務

  從以上對“服務”的定義可以看出，服務的定義對象是業(yè)務系統(tǒng)中的完整業(yè)務功能。例如電商系統(tǒng)中“確認訂單”這個功能就是一個服務、計費系統(tǒng)中“當月費用結算”功能就是一個服務；但是CRM系統(tǒng)中，需要完成“工單生成”功能所進行的“用戶登錄”動作就不是服務的定義，因為使用者進行“用戶登錄”是為了完成“工單生成”功能的權限驗證步驟，并不是為了“登錄”而登錄。

• 服務的粒度雖然相對粗放，但卻可控，目標是重用

  接著討論，“用戶登錄”這個功能在某些情況下也可以滿足“服務”的定義：當用戶中心系統(tǒng)為其他所有業(yè)務系統(tǒng)統(tǒng)一提供的“登錄”服務被公布出來時。服務粒度的拆分完全依據(jù)業(yè)務系統(tǒng)中業(yè)務過程進行定義和分析，所以服務的粒度都相對粗放。就像上一段文字中所舉例的“費用結算”服務那樣：可能完成“費用結算”功能，在計費系統(tǒng)內(nèi)部需要完成 用戶身份確認->上月費用查詢->套餐清單查詢->費用明細生成 這幾個過程。但是這些每一個過程都不會有任何其它業(yè)務系統(tǒng)進行單獨使用，也就是說是否單獨公布這些處理過程對于其他業(yè)務系統(tǒng)來說沒有任何意義。

  如果在后續(xù)的業(yè)務變更/業(yè)務重編時，業(yè)務設計人員發(fā)現(xiàn)某一個業(yè)務系統(tǒng)需要單獨使用計費系統(tǒng)的“上月費用查詢”功能，這時就需要計費系統(tǒng)將這個功能作為一個獨立的服務向第三方業(yè)務系統(tǒng)公布出來。這時，這個功能就滿足了“服務”的定義。

• 集成的目的是形成一個新的服務

  對企業(yè)內(nèi)部（或者企業(yè)間）的業(yè)務服務進行集成，被集成的業(yè)務服務稱之為原子服務，集成的目的是重用這些原子服務形成一個新的服務。這樣保證了技術團隊/業(yè)務團隊能以最小的代價，最高的效率使用既有服務，但同時也對實現(xiàn)SOA架構思想的軟件提出了更高的要求。

• SOA需保證屏蔽細節(jié)

  使用SOA架構思想構建多個業(yè)務系統(tǒng)的集成關系，需要保證每個業(yè)務系統(tǒng)屏蔽細節(jié)。這些細節(jié)包括技術細節(jié)和業(yè)務細節(jié)。從技術細節(jié)層面看，無論業(yè)務系統(tǒng)使用哪種開發(fā)語言、哪種對外傳輸協(xié)議、哪種消息格式都可以使用SOA進行集成，并且能夠在SOA架構的實現(xiàn)軟件上完成不同傳輸協(xié)議的轉(zhuǎn)換和不同消息格式的轉(zhuǎn)換；從業(yè)務細節(jié)層面看，SOA需要屏蔽業(yè)務系統(tǒng)的功能步驟細節(jié)。也就是說第三方系統(tǒng)只需要知道調(diào)用某一個服務就可以達到業(yè)務目的，至于提供服務的業(yè)務系統(tǒng)如何實現(xiàn)業(yè)務過程則無需關心。

• SOA讓各業(yè)務系統(tǒng)保持松散

  SOA架構模型為多個業(yè)務系統(tǒng)進行松散集成提供了一個良好的思路：通過屏蔽各業(yè)務系統(tǒng)技術細節(jié)和業(yè)務細節(jié)，兼容各業(yè)務系統(tǒng)的不同傳輸協(xié)議和不同消息格式，可以讓通過SOA進行業(yè)務集成的各個業(yè)務系統(tǒng)保持低耦合狀態(tài)。這是因為所有協(xié)議和消息格式都處于開放狀態(tài)，業(yè)務集成時各業(yè)務系統(tǒng)不需要單獨進行額外的轉(zhuǎn)換工作，甚至不需要為基于SOA的業(yè)務集成進行任何額外工作，也無須知道對方系統(tǒng)的存在。

如果您所在企業(yè)或者客戶的業(yè)務系統(tǒng)還沒有達到一個較高的復雜等級，則不建議立即使用SOA架構模型進行業(yè)務集成。因為目前SOA架構模型的各種實現(xiàn)本身就具有一定的復雜性。

2-1-2、ESB

ESB（Enterprise Service Bus）全名：企業(yè)服務總線，是SOA架構思想的一種實現(xiàn)思路。既然是一種思路，就有這一實現(xiàn)思路的具體考慮，以及需要解決問題的實際環(huán)境：

企業(yè)的信息化建設一般經(jīng)歷很長時間的發(fā)展，少則5、6年多則10幾年。所以我們看到某大型企業(yè)的信息系統(tǒng)最可能的情況是：存在著多個業(yè)務系統(tǒng)，甚至各業(yè)務系統(tǒng)負責的功能職責還存在重疊。這些系統(tǒng)采用不同時代的編程語言、編程框架、通訊協(xié)議、消息格式和存儲方案。

例如，計費系統(tǒng)可能采用C++ 進行編寫，對外調(diào)用功能采用CORBA；年久的CRM系統(tǒng)采用Delphi進行編寫，同樣使用CORBA發(fā)布調(diào)用功能，并且最近兩年該企業(yè)剛對CRM系統(tǒng)使用C#語言進行了一次升級，但是由于數(shù)據(jù)存儲層的設計原因，并沒有將老系統(tǒng)的所有數(shù)據(jù)割接到新系統(tǒng)，所以目前兩套CRM系統(tǒng)都在使用；最新開發(fā)的財務聯(lián)動系統(tǒng)，采用Java語言開發(fā)，并且不再采用應用程序窗口，改為使用瀏覽器進行頁面展示和用戶操作。這個財務聯(lián)動系統(tǒng)多數(shù)對外的服務采用HTTP協(xié)議對外公布，還有一部分服務采用Thrift RPC對外公布……

由此可見，由于各種可見的和不可見的原因，企業(yè)信息化系統(tǒng)的建設歷史和現(xiàn)實存在往往紛繁復雜。如果這些系統(tǒng)需要進行服務集成，但是又沒有一個成熟穩(wěn)定、兼容易用的中間層進行協(xié)調(diào)，那么要達到以上的調(diào)用要求基本上不可能的（即使實現(xiàn)也相當難以維護和擴展）。

那么為了滿足SOA架構思想的設計要點，達到既定的工作目標，ESB總線技術至少需要幫助這些業(yè)務系統(tǒng)完成以下工作：

• 多調(diào)用協(xié)議支撐和轉(zhuǎn)換

無論業(yè)務系統(tǒng)向外部公布的服務使用哪種調(diào)用協(xié)議，都可以通過ESB技術進行兼容性轉(zhuǎn)換。例如A業(yè)務系統(tǒng)的服務只接受Web Service SOAP形式的調(diào)用，B業(yè)務系統(tǒng)的服務卻可以使用Thrift RPC進行調(diào)用（不必為了調(diào)用A業(yè)務系統(tǒng)而專門去適應A業(yè)務系統(tǒng)的協(xié)議）。在基于ESB服務的中間層幫助實現(xiàn)兩種協(xié)議的轉(zhuǎn)換。

• 多消息格式支撐和轉(zhuǎn)換

無論調(diào)用協(xié)議攜帶哪一種消息描述格式，通過ESB中間層也可以實現(xiàn)相互轉(zhuǎn)換。ESB中間層應該支持將JSON格式的信息描述轉(zhuǎn)換成目標業(yè)務系統(tǒng)能夠識別的XML格式，或者將XML描述格式轉(zhuǎn)換成純文本格式，又或者實現(xiàn)兩種不同結構的XML格式的互相轉(zhuǎn)換，等等……

• 服務監(jiān)控管理（注冊、安全、版本、優(yōu)先級）

既然ESB要對原子服務進行集成，考慮的問題就比較多了。首先，業(yè)務系統(tǒng)提供的服務可能會以一定周期發(fā)生變化，例如周期性的升級；失控的業(yè)務系統(tǒng)甚至可能呈現(xiàn)完全無預兆無規(guī)律的服務變化，例如突發(fā)性數(shù)據(jù)割接導致服務接口變動。那么ESB的實現(xiàn)軟件中應該有一套功能，能夠保證在這樣的情況下集成服務依然能夠工作。其次，并不是業(yè)務系統(tǒng)所提供的所有服務都可以在ESB中進行集成，也并不是所有的服務都能被任何路由規(guī)則所編排。ESB應該有一套完整的功能來保證服務集成的安全性和權限。

作為被集成的業(yè)務系統(tǒng)，ESB中如何集成它提供的原子服務，前者是不需要關心的，

• 服務集成和編排

為了將多個服務通過ESB技術進行集成形成一個新的服務，ESB技術必須能夠進行服務編排。服務編排的作用就是明確原子服務執(zhí)行的先后順序、判斷原子服務執(zhí)行的條件、確保集成后的新服務能夠按照業(yè)務設計者的要求正常工作。下圖示例了新服務“工單派發(fā)”通過多個業(yè)務系統(tǒng)提供的原子服務，按照設置的執(zhí)行條件在ESB總線上進行工作的過程：

實際上ESB技術和本專題之前講過的服務治理技術在架構層面屬同一層：都是對SOA思想的實現(xiàn)思路。但是兩者的應用場景和側(cè)重點完全不一樣。

2-2、ESB是EAI的進化

ESB企業(yè)服務總線技術是在SOA架構之后出現(xiàn)的，在這之前為了集成多個系統(tǒng)而使用最多的技術思路是EAI（Enterprise Application Integration）：企業(yè)應用集成。EAI技術并沒有一個統(tǒng)一的標準，而是對不同企業(yè)集成業(yè)務系統(tǒng)手段的統(tǒng)一稱呼。

2-2-1、EAI的特征

從上圖可以看出，EAI主要的作用還是完成各中消息格式的轉(zhuǎn)換。由于EAI主要的使用場景是在上世紀八九十年代，所以如果從現(xiàn)在往回看EAI所支持的傳輸協(xié)議也是很有限的（不過肯定還是基于7層/5層網(wǎng)絡協(xié)議的）。不過，在SOA架構思想出現(xiàn)之前，EAI技術確實為企業(yè)實現(xiàn)業(yè)務系統(tǒng)集成提供了一個可行的思路。

需要注意的是，EAI技術并不是SOA架構思想的一種實現(xiàn)。它出現(xiàn)在SOA架構思想之前，最重要的是它缺少SOA的基本要素——著眼業(yè)務服務，粒度粗放但卻可控：由于EAI中并沒有流程編排的功能，所以這些原子服務并不能有機的結合在一起，形成新的服務，也無法在EAI中重新梳理業(yè)務過程，以便要求原子服務進行相應的粒度拆分。

2-2-2、哪些特征得到了進化

• 在消息轉(zhuǎn)換上的進化：

上一小節(jié)已經(jīng)提到，由于EAI技術出現(xiàn)的時間比較早，在那個時候基本上還沒有太多行業(yè)標準的傳輸協(xié)議和消息格式，使用最多的就是XML格式，還有半結構化的文本數(shù)據(jù)。所以，在公司內(nèi)部實現(xiàn)EAI技術時，一般不會考慮太多的行業(yè)標準，使用公司內(nèi)部自定制的傳輸協(xié)議和消息格式就能夠搞定。雖然這樣做也有一定的好處，就是公司內(nèi)部的業(yè)務團隊都清楚這些自定制的格式代表的業(yè)務意義，降低了一定的溝通成本。但這樣做的問題也顯而易見，如果日后需要和兄弟公司的業(yè)務系統(tǒng)進行集成，那么之前被節(jié)約的工作時間又會被浪費。

成熟的ESB產(chǎn)品中就不會這樣考慮問題，一般采用開放性的傳輸協(xié)議和消息格式。例如使用HTTP傳輸協(xié)議攜帶查詢請求、使用FTP傳輸協(xié)議攜帶上傳的文件信息；采用XMPP消息格式描述IM即時通訊內(nèi)容，采用MQTT消息格式描述物聯(lián)網(wǎng)設備采集內(nèi)容、使用AMQP消息格式描述MQ的內(nèi)容。

• 在流程編排上的進化

EAI沒有流程編排的硬性要求，也就是說他只面向數(shù)據(jù)轉(zhuǎn)換過程，并不面向業(yè)務服務。所以各位讀者可以這樣看待這個問題：SOA架構思想出現(xiàn)后，偉大的技術屌絲團隊立馬發(fā)現(xiàn)了面向服務的概念對EAI軟件的建設性作用，廢寢忘食的為各種業(yè)已運行的EAI軟件加入了各種面向服務的要素，最關鍵的就是加入了服務編排等面向服務的管理功能。實際上，以上情況就是現(xiàn)實中最真實的情況。

• 在服務管理上的進化

從EAI到ESB實際上是業(yè)務管理方法上的優(yōu)化，但就像上文中提到的那樣，并不是所有企業(yè)都適合使用基于SOA架構思想的ESB技術。目前大部分企業(yè)的對內(nèi)部業(yè)務系統(tǒng)的集成手段還是更貼切于EAI技術的定義，這是因為這些企業(yè)的業(yè)務系統(tǒng)還沒有達到較高的復雜度（出現(xiàn)最多的情況就是他們只有一套必須的財務系統(tǒng)）。

所以，EAI并不是淘汰品，ESB也不是什么“跨時代”的偉大發(fā)明。后者就是前者不斷完善的產(chǎn)物，把兩者之間的關系說成“基礎版”和“升級版”更為貼切。一些網(wǎng)絡文章一味貶低EAI提升ESB的地位，這是不正確的，有的企業(yè)或者平臺，還沒有復雜到必須使用ESB，那就可以不使用ESB技術。所以只有適合自己架構才是理想的架構。如果是某個ESB廠商的軟文，目的是什么就仁者見仁智者見智了。

2-3、ESB與循環(huán)依賴

ESB技術保證了各個業(yè)務服務的低耦合性，間接避免了各業(yè)務系統(tǒng)在集成時技術團隊有意無意制造的服務循環(huán)依賴問題。

2-3-1、什么是循環(huán)依賴

首先我們要講清楚什么是循環(huán)依賴，以及循環(huán)依賴的在程序設計層面、軟件產(chǎn)品設計層面、頂層架構設計層面上可能出現(xiàn)的場景。從概念模型上講，只要兩個或多個元素產(chǎn)生相互依賴關系，就可以看成產(chǎn)生了循環(huán)依賴：

上圖是兩個依賴關系正確的示例：A元素正常工作依賴于B元素的正常工作，或者A元素的正常工作依賴于B、C、D元素的正常工作。這里的A、B、C、D四個元素可以指代四段代碼，也可以指代一個業(yè)務系統(tǒng)中四個功能模塊，還可以指代頂層架構設計中的4個獨立工作的業(yè)務系統(tǒng)。

循環(huán)依賴在邏輯層面上是一個有向循環(huán)圖。上圖中展示了兩個錯誤的依賴關系實例：A元素正常工作依賴于B元素正常工作的同時，B元素正常工作又依賴于A元素的正常工作。那么究竟哪個元素能夠首先正常工作起來呢（先有雞還是先有蛋）？右側(cè)圖展示了三個元素的循環(huán)依賴，A元素依賴于C元素，C元素依賴于D元素，D元素又依賴于A元素。那么A、C、D三個元素究竟哪一個元素才是底層的基礎元素呢？

• 代碼層面的循環(huán)依賴：

代碼層面的循環(huán)依賴是開發(fā)人員最容易出現(xiàn)的編碼錯誤，不過有的時候也不能全怪開發(fā)人員，畢竟業(yè)務設計者從需求理解階段可能就出現(xiàn)了問題。以下示例了代碼層面的循環(huán)依賴：

/*** 此類依賴于BusinessB* @author yinwenjie*/ public class BusinessA { private BusinessB bb; public BusinessA(BusinessB bb) { this.bb = bb; } ...... } /** * 此類依賴于BusinessC * @author yinwenjie */ public class BusinessB { private BusinessC bc; public BusinessB(BusinessC bc) { this.bc = bc; } ...... } /** * 此類依賴于BusinessA * @author yinwenjie */ public class BusinessC { private BusinessA ac; public BusinessC(BusinessA ac) { this.ac = ac; } ...... // 接下來我們試圖實例化BusinessA... public static void main(String[] args) { // 怎么實例化BusinessA呢？ // new BusinessA(new BusinessB(new BusinessC(new BusinessA(！程序員已經(jīng)發(fā)瘋！)))) } }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44

實際上按照這樣的引用結構和構造函數(shù)要求，實例化BusinessA這件事情是永遠無法完成的。

• 功能層面的循環(huán)依賴：

業(yè)務系統(tǒng)的功能間也可能出現(xiàn)循環(huán)依賴。相對于代碼層面的循環(huán)依賴，功能模塊層面的循環(huán)依賴更能夠影響一款業(yè)務系統(tǒng)的設計質(zhì)量。筆者曾參與的一款軟件，客戶方曾經(jīng)提出過這樣的一個業(yè)務需求：

貨運系統(tǒng)中在創(chuàng)建新的“發(fā)車單”時，必須選擇空閑的司機和空閑的貨車（當然貨車類型是要判斷的）?？臻e的司機和空閑貨車缺少任何一樣都不能完成“發(fā)車單”的創(chuàng)建。但同時為了記錄某輛貨車上一次對應的“發(fā)車單”，客戶要求只能在創(chuàng)建新的發(fā)車單后，貨車才能解除之前的“發(fā)車單”綁定關系，變成“空閑貨車”。

那么問題來了，如果只有完成新的“發(fā)車單”創(chuàng)建后，貨車才能解除和之前“發(fā)車單”的綁定關系，那么新創(chuàng)建“發(fā)車單”時，“空閑的貨車”從哪里來呢？實際上客戶方不懂技術，是我們在需求調(diào)研階段遇到的算一個問題的問題，但關鍵看需求人員從哪個方面著手向用戶解釋引導用戶對需求邏輯進行分析。不一定用技術語言直接告訴用戶，他的需求在技術層面上不符合邏輯。

• 架構層面的循環(huán)依賴：

多個業(yè)務系統(tǒng)在進行集成時，他們也可能會出現(xiàn)循環(huán)依賴。特別是參與集成的業(yè)務系統(tǒng)越多，這種循環(huán)依賴的情況就越容易出現(xiàn)：

在系統(tǒng)數(shù)量還沒有達到一定數(shù)量時（通常來說這個閥值為4），系統(tǒng)間的循環(huán)依賴最可能是由業(yè)務人員/技術人員無意造成。這時，系統(tǒng)間的依賴關系還處于一個可控級別，即使出現(xiàn)系統(tǒng)間循環(huán)依賴的情況，技術團隊/業(yè)務團隊也可以快速進行糾正。但是，當參與集成的業(yè)務系統(tǒng)數(shù)量超過可控制的閥值數(shù)量后，這個檢查和糾正工作就不再是人工可及的范圍了。如下圖所示的5個系統(tǒng)進行集成時，很容易出現(xiàn)系統(tǒng)間循環(huán)依賴的情況：

2-3-3、避免循環(huán)依賴

• 依賴倒置原則預防循環(huán)依賴

依賴倒置原則可以幫助預防代碼層面和功能模塊層面的循環(huán)依賴。頂層架構層面的循環(huán)依賴問題，也可以遵循這個原則進行設計來避免。依賴倒置原則在很多書本、網(wǎng)絡資料上都有很詳細的介紹?；旧线@個原則是在說兩個點：高層次模塊不應該依賴于低層次模塊，模塊的實現(xiàn)都應該依賴于抽象（接口），而抽象（接口）能夠屏蔽功能設計上的細節(jié)。

• 對循環(huán)依賴的自動檢測

如果您負責的產(chǎn)品是遺留產(chǎn)品。在經(jīng)過多個設計人員更替后，產(chǎn)品內(nèi)部設計或多或少出現(xiàn)了一些循環(huán)依賴問題，這時該怎么辦？您要做的首先是檢查產(chǎn)品的哪些模塊出現(xiàn)了循環(huán)依賴，再思考修改方法。目前市面上有很多這樣的工具，可以幫助您檢查代碼層面和系統(tǒng)模塊層面的依賴關系是否良好，這里筆者推薦SonarQube。以下截圖是筆者經(jīng)歷過的一個項目中，某個子模塊通過SonarQube進行檢測的結果：

呵呵，V0.0.9版本，看來還有若干個類的復雜度偏高，說明模塊中使用的設計模式還有改進空間。好吧，這個子系統(tǒng)只是開了一個頭，目前已經(jīng)發(fā)展到V0.5.3的版本號，代碼行數(shù)也快接近5萬行了。不過作為這個子模塊的作者之一，本人自認為包耦合度一直控制得很好，直到現(xiàn)在也沒有出現(xiàn)包循環(huán)依賴的情況。

• 抽離底層能引導業(yè)務人員優(yōu)化依賴結構

在上一小節(jié)“功能層面的循環(huán)依賴”中我們舉了一個司機-貨車-發(fā)車單三個元素在業(yè)務功能層面的循環(huán)依賴問題。現(xiàn)在我們接著這個問題繼續(xù)討論?？蛻糁砸谛碌摹鞍l(fā)車單”創(chuàng)建后，才解除貨車和歷史“發(fā)車單”的綁定關系，是因為用戶擔心軟件失去對歷史“發(fā)車單”的跟蹤能力，最后無法統(tǒng)計車輛使用率或者司機績效情況。但實際上，客戶完全無需擔心出現(xiàn)這樣的情況，了解客戶的真實想法后，需求人員就能引導客戶開辟一個新的日志模塊，這個日志模塊處于整個業(yè)務系統(tǒng)設計的更底層，專門跟蹤各種歷史行為，車輛的、人員的、財務的、貨品的，都行：

我們可以用這種剝離循環(huán)依賴元素中底層能力的方式，解決循環(huán)依賴問題。這種解決思路不但適用于業(yè)務系統(tǒng)功能間的解耦，同樣適用于代碼級別或者系統(tǒng)頂層架構級別的解耦。

• 使用中間層/基礎層對依賴元素進行隔離

ESB為各個業(yè)務系統(tǒng)的集成提供了一個理想的中間層/基礎層。通過從中間層/基礎層抽離的底層能力，我們將所有業(yè)務系統(tǒng)的集成工作交由ESB完成：

注意：雖然ESB承擔了原本在系統(tǒng)內(nèi)部完成的業(yè)務集成工作。但是根據(jù)依賴倒置設計原則，ESB也只是依賴于各業(yè)務系統(tǒng)注冊在ESB總線上的調(diào)用接口，業(yè)務系統(tǒng)中功能的具體實現(xiàn)對于ESB來說是透明的。

轉(zhuǎn)載于:https://www.cnblogs.com/hypnotizer/p/6756942.html

總結

以上是生活随笔為你收集整理的ESB--转的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。