SOA面向服務(wù)架構(gòu)介紹

1.定義介紹

SOA(Service-Oriented Architecture，面向服務(wù)的架構(gòu))是一個組件模型，它將應(yīng)用程序的不同功能單元(稱為服務(wù))通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進行定義的，它應(yīng)該獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進行交互。面向服務(wù)架構(gòu)，它可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進行分布式部署、組合和使用。服務(wù)層是SOA的基礎(chǔ)，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。

SOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、XML(標準通用標記語言的子集)/Web Service技術(shù)之后的自然延伸。

SOA將能夠幫助軟件工程師們站在一個新的高度理解企業(yè)級架構(gòu)中的各種組件的開發(fā)、部署形式，它將幫助企業(yè)系統(tǒng)架構(gòu)者以更迅速、更可靠、更具重用性架構(gòu)整個業(yè)務(wù)系統(tǒng)。較之以往，以SOA架構(gòu)的系統(tǒng)能夠更加從容地面對業(yè)務(wù)的急劇變化。

2.SOA的概念

SOA 是一種在計算環(huán)境中設(shè)計、開發(fā)、部署和管理離散邏輯單元(服務(wù))模型的方法。SOA 并不是一個新鮮事物，而只是面向?qū)ο竽Ｐ偷囊环N替代。雖然基于 SOA 的系統(tǒng)并不排除使用 OOD 來構(gòu)建單個服務(wù)，但是其整體設(shè)計卻是面向服務(wù)的。由于 SOA 考慮到了系統(tǒng)內(nèi)的對象，所以雖然SOA 是基于對象的，但是作為一個整體，它卻不是面向?qū)ο蟮摹?/p>

SOA 系統(tǒng)原型的一個典型例子是 CORBA，它已經(jīng)出現(xiàn)很長時間，其定義的概念與 SOA 相似。SOA 建立在 XML 等新技術(shù)的基礎(chǔ)上，通過使用基于 XML 的語言來描述接口，服務(wù)已經(jīng)轉(zhuǎn)到更動態(tài)且更靈活的接口系統(tǒng)中，CORBA 中的 IDL 無法與之相比。如下圖9-13 描述了一個完整的 SOA 模型。

在 SOA 模型中，所有的功能都定義成了獨立的服務(wù)。服務(wù)之間通過交互和協(xié)調(diào)完成業(yè)務(wù)的整體邏輯。所有的服務(wù)通過服務(wù)總線或流程管理器來連接。這種松散耦合的架構(gòu)使得各服務(wù)在交互過程中無需考慮雙方的內(nèi)部實現(xiàn)細節(jié)，以及部署在什么平臺上。

3 服務(wù)的基本結(jié)構(gòu)

一個獨立的服務(wù)基本結(jié)構(gòu)如圖 9-14 所示。

由圖 9-14 可以看出，服務(wù)模型的表示層從邏輯層分離出來，中間增加了服務(wù)對外的接口層。通過服務(wù)接口的標準化描述，使得服務(wù)可以提供給在任何異構(gòu)平臺和任何用戶接口使用。這允許并支持基于服務(wù)的系統(tǒng)成為松散耦合、面向構(gòu)件和跨技術(shù)實現(xiàn)，服務(wù)請求者很可能根本不知道服務(wù)在哪里運行、是由哪種語言編寫的，以及消息的傳輸路徑，而是只需要提出服務(wù)請求，然后就會得到答案。

4.SOA 設(shè)計原則

在 SOA 架構(gòu)中，繼承了來自對象和構(gòu)件設(shè)計的各種原則，例如，封裝和自我包含等。那些保證服務(wù)的靈活性、松散耦合和復(fù)用能力的設(shè)計原則，對 SOA 架構(gòu)來說同樣是非常重要的。關(guān)于服務(wù)，一些常見的設(shè)計原則如下：

(1)明確定義的接口。服務(wù)請求者依賴于服務(wù)規(guī)約來調(diào)用服務(wù)，因此，服務(wù)定義必須長時間穩(wěn)定，一旦公布，不能隨意更改;服務(wù)的定義應(yīng)盡可能明確，減少請求者的不適當使用;不要讓請求者看到服務(wù)內(nèi)部的私有數(shù)據(jù)。

(2)自包含和模塊化。服務(wù)封裝了那些在業(yè)務(wù)上穩(wěn)定、重復(fù)出現(xiàn)的活動和構(gòu)件，實現(xiàn)服務(wù)的功能實體是完全獨立自主的，獨立進行部署、版本控制、自我管理和恢復(fù)。

(3)粗粒度。服務(wù)數(shù)量不應(yīng)該太多，依靠消息交互而不是遠程過程調(diào)用，通常消息量比較大，但是服務(wù)之間的交互頻度較低。

(4)松耦合。服務(wù)請求者可見的是服務(wù)的接口，其位置、實現(xiàn)技術(shù)、當前狀態(tài)和私有數(shù)據(jù)等，對服務(wù)請求者而言是不可見的。

(5)互操作性、兼容和策略聲明。為了確保服務(wù)規(guī)約的全面和明確，策略成為一個越來越重要的方面。這可以是技術(shù)相關(guān)的內(nèi)容，例如，一個服務(wù)對安全性方面的要求;也可以是與業(yè)務(wù)有關(guān)的語義方面的內(nèi)容，例如，需要滿足的費用或者服務(wù)級別方面的要求，這些策略對于服務(wù)在交互時是非常重要的。

5. 服務(wù)構(gòu)件與傳統(tǒng)構(gòu)件

服務(wù)構(gòu)件架構(gòu)(Service Component Architecture，SCA)是基于 SOA 的思想描述服務(wù)之間組合和協(xié)作的規(guī)范，它描述用于使用 SOA 構(gòu)建應(yīng)用程序和系統(tǒng)的模型。它可簡化使用 SOA 進行的應(yīng)用程序開發(fā)和實現(xiàn)工作。SCA 提供了構(gòu)建粗粒度構(gòu)件的機制，這些粗粒度構(gòu)件由細粒度構(gòu)件組裝而成。SCA 將傳統(tǒng)中間件編程從業(yè)務(wù)邏輯分離出來，從而使程序員免受其復(fù)雜性的困擾。它允許開發(fā)人員集中精力編寫業(yè)務(wù)邏輯，而不必將大量的時間花費在更為底層的技術(shù)實現(xiàn)上。

SCA 服務(wù)構(gòu)件與傳統(tǒng)構(gòu)件的主要區(qū)別在于，服務(wù)構(gòu)件往往是粗粒度的，而傳統(tǒng)構(gòu)件以細粒度居多;服務(wù)構(gòu)件的接口是標準的，主要是服務(wù)描述語言接口，而傳統(tǒng)構(gòu)件常以具體 API 形式出現(xiàn);服務(wù)構(gòu)件的實現(xiàn)與語言是無關(guān)的，而傳統(tǒng)構(gòu)件常綁定某種特定的語言;服務(wù)構(gòu)件可以通過構(gòu)件容器提供 QoS 的服務(wù)，而傳統(tǒng)構(gòu)件完全由程序代碼直接控制。

6 SOA 的關(guān)鍵技術(shù)

SOA 伴隨著無處不在的標準，為企業(yè)的現(xiàn)有資產(chǎn)或投資帶來了更好的復(fù)用性。SOA 能夠在最新的和現(xiàn)有的系統(tǒng)之上創(chuàng)建應(yīng)用，借助現(xiàn)有的應(yīng)用產(chǎn)生新的服務(wù)，為企業(yè)提供更好的靈活性來構(gòu)建系統(tǒng)和業(yè)務(wù)流程。SOA 是一種全新的架構(gòu)，為了支持其各種特性，相關(guān)的技術(shù)規(guī)范不斷推出。與 SOA 緊密相關(guān)的技術(shù)主要有 UDDI、WSDL、SOAP 和 REST 等，而這些技術(shù)都是以 XML 為基礎(chǔ)而發(fā)展起來的。

1. UDDI

UDDI(Universal DescriptionDiscovery and Integration，統(tǒng)一描述、發(fā)現(xiàn)和集成)提供了一種服務(wù)發(fā)布、查找和定位的方法，是服務(wù)的信息注冊規(guī)范，以便被需要該服務(wù)的用戶發(fā)現(xiàn)和使用它。UDDI 規(guī)范描述了服務(wù)的概念，同時也定義了一種編程接口。通過 UDDI 提供的標準接口，企業(yè)可以發(fā)布自己的服務(wù)供其他企業(yè)查詢和調(diào)用，也可以查詢特定服務(wù)的描述信息，并動態(tài)綁定到該服務(wù)上。

在 UDDI 技術(shù)規(guī)范中，主要包含以下三個部分的內(nèi)容：

(1)數(shù)據(jù)模型。UDDI 數(shù)據(jù)模型是一個用于描述業(yè)務(wù)組織和服務(wù)的 XML Schema。

(2)API。UDDI API 是一組用于查找或發(fā)布 UDDI 數(shù)據(jù)的方法，UDDI API 基于 SOAP。

(3)注冊服務(wù)。UDDI 注冊服務(wù)是 SOA 中的一種基礎(chǔ)設(shè)施，對應(yīng)著服務(wù)注冊中心的角色。

2.WSDL

WSDL(Web ServiceDescription Language，Web 服務(wù)描述語言)是對服務(wù)進行描述的語言，它有一套基于 XML 的語法定義。WSDL 描述的重點是服務(wù)，它包含服務(wù)實現(xiàn)定義和服務(wù)接口定義，如圖 9-15 所示。

采用抽象接口定義對于提高系統(tǒng)的擴展性很有幫助。服務(wù)接口定義就是一種抽象的、可重用的定義，行業(yè)標準組織可以使用這種抽象的定義來規(guī)定一些標準的服務(wù)類型，服務(wù)實現(xiàn)者可以根據(jù)這些標準定義來實現(xiàn)具體的服務(wù)。

服務(wù)實現(xiàn)定義描述了給定服務(wù)提供者如何實現(xiàn)特定的服務(wù)接口。服務(wù)實現(xiàn)定義中包含服務(wù)和端口描述。一個服務(wù)往往會包含多個服務(wù)訪問入口，而每個訪問入口都會使用一個端口元素來描述，端口描述的是一個服務(wù)訪問入口的部署細節(jié)，例如，通過哪個地址來訪問，應(yīng)當使用怎樣的消息調(diào)用模式來訪問等。

3.SOAP

SOAP(Simple ObjectAccess Protocol，簡單對象訪問協(xié)議)定義了服務(wù)請求者和服務(wù)提供者之間的消息傳輸規(guī)范。SOAP 用 XML 來格式化消息，用 HTTP 來承載消息。通過 SOAP，應(yīng)用程序可以在網(wǎng)絡(luò)中進行數(shù)據(jù)交換和遠程過程調(diào)用(Remote Procedure Call， RPC)。SOAP 主要包括以下四個部分：

(1)封裝。SOAP 封裝定義了一個整體框架，用來表示消息中包含什么內(nèi)容，誰來處理這些內(nèi)容，以及這些內(nèi)容是可選的還是必需的。

(2)編碼規(guī)則。SOAP 編碼規(guī)則定義了一種序列化的機制，用于交換系統(tǒng)所定義的數(shù)據(jù)類型的實例。

(3)RPC 表示。SOAP RPC 表示定義了一個用來表示遠程過程調(diào)用和應(yīng)答的協(xié)議。

(4)綁定。SOAP 綁定定義了一個使用底層傳輸協(xié)議來完成在節(jié)點之間交換 SOAP 封裝的約定。

SOAP 消息基本上是從發(fā)送端到接收端的單向傳輸，但它們常常結(jié)合起來執(zhí)行類似于請求/應(yīng)答的模式。所有的 SOAP 消息都使用 XML 進行編碼。SOAP 消息包括以下三個部分：

(1)封裝(信封)。封裝的元素名是 Envelope，在表示消息的 XML 文檔中，封裝是頂層元素，在 SOAP 消息中必須出現(xiàn)。

(2)SOAP 頭。SOAP 頭的元素名是 Header，提供了向 SOAP 消息中添加關(guān)于這條 SOAP 消息的某些要素的機制。SOAP 定義了少量的屬性用來表明這項要素是否可選以及由誰來處理。SOAP 頭在 SOAP 消息中可能出現(xiàn)，也可能不出現(xiàn)。如果出現(xiàn)的話，必須是 SOAP 封裝元素的第一個直接子元素。

(3)SOAP 體。SOAP 體的元素名是 Body，是包含消息的最終接收者想要的信息的容器。SOAP 體在 SOAP 消息中必須出現(xiàn)且必須是 SOAP 封裝元素的直接子元素。如果有頭元素，則SOAP 體必須直接跟在 SOAP 頭元素之后;如果沒有頭元素，則 SOAP 體必須是 SOAP 封裝元素的第一個直接子元素。

4.REST

REST(RepresentationalState Transfer，表述性狀態(tài)轉(zhuǎn)移)是一種只使用 HTTP 和 XML 進行基于 Web 通信的技術(shù)，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。它的簡單性和缺少嚴格配置文件的特性，使它與 SOAP 很好地隔離開來，REST 從根本上來說只支持幾個操作(POST、GET、PUT 和 DELETE)，這些操作適用于所有的消息。REST 提出了如下一些設(shè)計概念和準則：

(1)網(wǎng)絡(luò)上的所有事物都被抽象為資源。(2)每個資源對應(yīng)一個唯一的資源標識。(3)通過通用的連接件接口對資源進行操作。(4)對資源的各種操作不會改變資源標識。(5)所有的操作都是無狀態(tài)的。

7 SOA 的實現(xiàn)方法

SOA 只是一種概念和思想，需要借助于具體的技術(shù)和方法來實現(xiàn)它。從本質(zhì)上來看， SOA 是用本地計算模型來實現(xiàn)一個分布式的計算應(yīng)用，也有人稱這種方法為“本地化設(shè)計，分布式工作”模型。CORBA、DCOM 和 EJB 等都屬于這種解決方式，也就是說，SOA 最終可以基于這些標準來實現(xiàn)。有關(guān)這些標準的知識，已經(jīng)在 13.1.1 節(jié)中詳細介紹。另外，這些標準分別使用的 ORB、RPC 和 RMI(Remote Method Invocation，遠程方法調(diào)用)等技術(shù)，將在 17.1.2 節(jié)中介紹，此處不再贅述。

從邏輯上和高層抽象來看，目前，實現(xiàn) SOA 的方法也比較多，其中主流方式有 Web Service、企業(yè)服務(wù)總線和服務(wù)注冊表。

1.Web Service

在 Web Service(Web 服務(wù))的解決方案中，一共有三種工作角色，其中服務(wù)提供者和服務(wù)請求者是必需的，服務(wù)注冊中心是一個可選的角色。它們之間的交互和操作構(gòu)成了 SOA 的一種實現(xiàn)架構(gòu)，如圖 9-16 所示。

(1)服務(wù)提供者。服務(wù)提供者是服務(wù)的所有者，該角色負責定義并實現(xiàn)服務(wù)，使用 WSDL 對服務(wù)進行詳細、準確、規(guī)范地描述，并將該描述發(fā)布到服務(wù)注冊中心，供服務(wù)請求者查找并綁定使用。

(2)服務(wù)請求者。服務(wù)請求者是服務(wù)的使用者，雖然服務(wù)面向的是程序，但程序的最終使用者仍然是用戶。從架構(gòu)的角度看，服務(wù)請求者是查找、綁定并調(diào)用服務(wù)，或與服務(wù)進行交互的應(yīng)用程序。服務(wù)請求者角色可以由瀏覽器來擔當，由人或程序(例如，另外一個服務(wù))來控制。

(3)服務(wù)注冊中心。服務(wù)注冊中心是連接服務(wù)提供者和服務(wù)請求者的紐帶，服務(wù)提供者在此發(fā)布他們的服務(wù)描述，而服務(wù)請求者在服務(wù)注冊中心查找他們需要的服務(wù)。不過，在某些情況下，服務(wù)注冊中心是整個模型中的可選角色。例如，如果使用靜態(tài)綁定的服務(wù)，服務(wù)提供者則可以把描述直接發(fā)送給服務(wù)請求者。

Web Service 模型中的操作包括發(fā)布、查找和綁定，這些操作可以單次或反復(fù)出現(xiàn)。

(1)發(fā)布。為了使用戶能夠訪問服務(wù)，服務(wù)提供者需要發(fā)布服務(wù)描述，以便服務(wù)請求者可以查找它。

(2)查找。在查找操作中，服務(wù)請求者直接檢索服務(wù)描述或在服務(wù)注冊中心查詢所要求的服務(wù)類型。對服務(wù)請求者而言，可能會在生命周期的兩個不同階段中涉及查找操作，首先是在設(shè)計階段，為了程序開發(fā)而查找服務(wù)的接口描述;其次是在運行階段，為了調(diào)用而查找服務(wù)的位置描述。

(3)綁定。在綁定操作中，服務(wù)請求者使用服務(wù)描述中的綁定細節(jié)來定位、聯(lián)系并調(diào)用服務(wù)，從而在運行時與服務(wù)進行交互。綁定可以分為動態(tài)綁定和靜態(tài)綁定。在動態(tài)綁定中，服務(wù)請求者通過服務(wù)注冊中心查找服務(wù)描述，并動態(tài)地與服務(wù)交互;在靜態(tài)綁定中，服務(wù)請求者已經(jīng)與服務(wù)提供者達成默契，通過本地文件或其他方式直接與服務(wù)進行綁定。

在采用 Web Service 作為 SOA 的實現(xiàn)技術(shù)時，應(yīng)用系統(tǒng)大致可以分為六個層次，分別是底層傳輸層、服務(wù)通信協(xié)議層、服務(wù)描述層、 服務(wù)層、業(yè)務(wù)流程層和服務(wù)注冊層。

(1)底層傳輸層。底層傳輸層主要負責消息的傳輸機制，HTTP、JMS(Java Messaging Service，Java 消息服務(wù))和 SMTP 都可以作為服務(wù)的消息傳輸協(xié)議，其中 HTTP 使用最廣。

(2)服務(wù)通信協(xié)議層。服務(wù)通信協(xié)議層的主要功能是描述并定義服務(wù)之間進行消息傳遞所需的技術(shù)標準，常用的標準是 SOAP 和 REST 協(xié)議。

(3)服務(wù)描述層。服務(wù)描述層主要以一種統(tǒng)一的方式描述服務(wù)的接口與消息交換方式，相關(guān)的標準是 WSDL。

(4)服務(wù)層。服務(wù)層的主要功能是將遺留系統(tǒng)進行包裝，并通過發(fā)布的 WSDL 接口描述被定位和調(diào)用。

(5)業(yè)務(wù)流程層。業(yè)務(wù)流程層的主要功能是支持服務(wù)發(fā)現(xiàn)，服務(wù)調(diào)用和點到點的服務(wù)調(diào)用，并將業(yè)務(wù)流程從服務(wù)的底層調(diào)用抽象出來。

(6)服務(wù)注冊層的主要功能是使服務(wù)提供者能夠通過 WSDL 發(fā)布服務(wù)定義，并支持服務(wù)請求者查找所需的服務(wù)信息。相關(guān)的標準是 UDDI。

2. 服務(wù)注冊表

服務(wù)注冊表(service registry)雖然也具有運行時的功能，但主要在 SOA設(shè)計時使用。它提供一個策略執(zhí)行點(Policy Enforcement Point，PEP)，在這個點上，服務(wù)可以在 SOA 中注冊，從而可以被發(fā)現(xiàn)和使用。服務(wù)注冊表可以包括有關(guān)服務(wù)和相關(guān)構(gòu)件的配置、依從性和約束文件。從理論上來說，任何幫助服務(wù)注冊、發(fā)現(xiàn)和查找服務(wù)合約、元數(shù)據(jù)和策略的信息庫、數(shù)據(jù)庫、目錄或其他節(jié)點都可以被認為是一個注冊表。大多數(shù)商用服務(wù)注冊產(chǎn)品支持服務(wù)注冊、服務(wù)位置和服務(wù)綁定功能。

(1)服務(wù)注冊。服務(wù)注冊是指服務(wù)提供者向服務(wù)注冊表發(fā)布服務(wù)的功能(服務(wù)合約)，包括服務(wù)身份、位置、方法、綁定、配置、方案和策略等描述性屬性。使用服務(wù)注冊表實現(xiàn) SOA 時，要限制哪些新服務(wù)可以向注冊表發(fā)布、由誰發(fā)布以及誰批準和根據(jù)什么條件批準等，以便使服務(wù)能夠有序的注冊。

(2)服務(wù)位置。服務(wù)位置是指服務(wù)使用者，幫助它們查詢已注冊的服務(wù)，尋找符合自身要求的服務(wù)。這種查找主要是通過檢索服務(wù)合約來實現(xiàn)的，在使用服務(wù)注冊表實現(xiàn) SOA 時，需要規(guī)定哪些用戶可以訪問服務(wù)注冊表，以及哪些服務(wù)屬性可以通過服務(wù)注冊表進行暴露等，以便服務(wù)能得到有效的、經(jīng)過授權(quán)的使用。

(3)服務(wù)綁定。服務(wù)使用者利用查找到的服務(wù)合約來開發(fā)代碼，開發(fā)的代碼將與注冊的服務(wù)進行綁定，調(diào)用注冊的服務(wù)，以及與它們實現(xiàn)互動?？梢岳眉傻拈_發(fā)環(huán)境自動將新開發(fā)的服務(wù)與不同的新協(xié)議、方案和程序間通信所需的其他接口綁定在一起。

3. 企業(yè)服務(wù)總線

ESB 的概念是從 SOA 發(fā)展而來的，它是一種為進行連接服務(wù)提供的標準化的通信基礎(chǔ)結(jié)構(gòu)，基于開放的標準，為應(yīng)用提供了一個可靠的、可度量的和高度安全的環(huán)境，并可幫助企業(yè)對業(yè)務(wù)流程進行設(shè)計和模擬，對每個業(yè)務(wù)流程實施控制和跟蹤、分析并改進流程和性能。

在一個復(fù)雜的企業(yè)計算環(huán)境中，如果服務(wù)提供者和服務(wù)請求者之間采用直接的端到端的交互，那么隨著企業(yè)信息系統(tǒng)的增加和復(fù)雜度的提高，系統(tǒng)之間的關(guān)聯(lián)會逐漸變得非常復(fù)雜，形成一個網(wǎng)狀結(jié)構(gòu)，這將帶來昂貴的系統(tǒng)維護費用，同時也使得 IT 基礎(chǔ)設(shè)施的復(fù)用變得困難重重。ESB 提供了一種基礎(chǔ)設(shè)施，消除了服務(wù)請求者與服務(wù)提供者之間的直接連接，使得服務(wù)請求者與服務(wù)提供者之間進一步解耦。

ESB 是由中間件技術(shù)實現(xiàn)并支持 SOA的一組基礎(chǔ)架構(gòu)，是傳統(tǒng)中間件技術(shù)與 XML、 Web Service 等技術(shù)結(jié)合的產(chǎn)物，是在整個企業(yè)集成架構(gòu)下的面向服務(wù)的企業(yè)應(yīng)用集成機制。具體來說，ESB 具有以下功能：

(1)支持異構(gòu)環(huán)境中的服務(wù)、消息和基于事件的交互，并且具有適當?shù)姆?wù)級別和可管理性。

(2)通過使用 ESB，可以在幾乎不更改代碼的情況下，以一種無縫的非侵入方式使現(xiàn)有系統(tǒng)具有全新的服務(wù)接口，并能夠在部署環(huán)境中支持任何標準。

(3)充當緩沖器的 ESB(負責在諸多服務(wù)之間轉(zhuǎn)換業(yè)務(wù)邏輯和數(shù)據(jù)格式)與服務(wù)邏輯相分離，從而使不同的系統(tǒng)可以同時使用同一個服務(wù)，不用在系統(tǒng)或數(shù)據(jù)發(fā)生變化時，改動服務(wù)代碼。

(4)在更高的層次，ESB 還提供諸如服務(wù)代理和協(xié)議轉(zhuǎn)換等功能。允許在多種形式下通過像HTTP、SOAP 和 JMS 總線的多種傳輸方式，主要是以網(wǎng)絡(luò)服務(wù)的形式，為發(fā)表、注冊、發(fā)現(xiàn)和使用企業(yè)服務(wù)或界面提供基礎(chǔ)設(shè)施。

(5)提供可配置的消息轉(zhuǎn)換翻譯機制和基于消息內(nèi)容的消息路由服務(wù)，傳輸消息到不同的目的地。

(6)提供安全和擁有者機制，以保證消息和服務(wù)使用的認證、授權(quán)和完整性。

在企業(yè)應(yīng)用集成方面，與現(xiàn)存的、專有的集成解決方案相比，ESB 具有以下優(yōu)勢：

(1)擴展的、基于標準的連接。ESB 形成一個基于標準的信息骨架，使得在系統(tǒng)內(nèi)部和整個價值鏈中可以容易地進行異步或同步數(shù)據(jù)交換。ESB 通過使用 XML、SOAP 和其他標準，提供了更強大的系統(tǒng)連接性。

(2)靈活的、服務(wù)導(dǎo)向的應(yīng)用組合?；?SOA，ESB 使復(fù)雜的分布式系統(tǒng)(包括跨多個應(yīng)用、系統(tǒng)和防火墻的集成方案)能夠由以前開發(fā)測試過的服務(wù)組合而成，使系統(tǒng)具有高度可擴展性。

(3)提高復(fù)用率，降低成本。按照 SOA 方法構(gòu)建應(yīng)用，提高了復(fù)用率，簡化了維護工作，進而減少了系統(tǒng)總體成本。

(4)減少市場反應(yīng)時間，提高生產(chǎn)率。ESB 通過構(gòu)件和服務(wù)復(fù)用，按照 SOA 的思想簡化應(yīng)用組合，基于標準的通信、轉(zhuǎn)換和連接來實現(xiàn)這些優(yōu)點。

8 微服務(wù)

微服務(wù)顧名思義，就是很小的服務(wù)，所以它屬于面向服務(wù)架構(gòu)的一種。通俗一點來說，微服務(wù)類似于古代著名的發(fā)明，活字印刷術(shù)，每個服務(wù)都是一個組件，通過編排組合的方式來使用，從而真正做到了獨立、解耦、組件化、易維護、可復(fù)用、可替換、高可用、最終達到提高交付質(zhì)量、縮短交付周期的效果。

從專業(yè)的角度來看，微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務(wù)運行在其獨立的進程中，服務(wù)與服務(wù)間采用輕量級的通信機制互相溝通(通常是基于 HTTP 協(xié)議的 RESTful API)。每個服務(wù)都圍繞著具體業(yè)務(wù)進行構(gòu)建，并且能夠被獨立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)當盡量避免統(tǒng)一的、集中式的服務(wù)管理機制，對具體的一個服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進行構(gòu)建。

所以總結(jié)起來，微服務(wù)的核心特點為：小, 且專注于做?件事情、輕量級的通信機制、松耦合、獨立部署。

1.微服務(wù)的優(yōu)勢

微服務(wù)之所以能盛行，必然是有它獨特優(yōu)勢的，下面我們來分析微服務(wù)有哪些方面的優(yōu)勢。

(1)技術(shù)異構(gòu)性

在微服務(wù)架構(gòu)中，每個服務(wù)都是一個相對獨立的個體，每個服務(wù)都可以選擇適合于自身的技術(shù)來實現(xiàn)。如，要開發(fā)一個社交平臺，此時，我們可能使用文檔型數(shù)據(jù)庫來存儲帖 子的內(nèi)容，使用圖數(shù)據(jù)來存儲朋友圈的這些關(guān)系等，這樣可以把每一塊的性能都充分發(fā)揮 出來。

同時，在應(yīng)用新技術(shù)時，微服務(wù)架構(gòu)也提供了更好的試驗場。因為對于單塊的系統(tǒng)而 言，采用一個新的語言、數(shù)據(jù)庫或者框架都會對整個系統(tǒng)產(chǎn)生巨大的影響，這樣導(dǎo)致我們 想嘗試新技術(shù)時，望而卻步。但微服務(wù)不同，我們完全可以只在一個微服務(wù)中采用新技術(shù)， 待技術(shù)使用熟練之后，再推廣到其他服務(wù)。

(2)彈性

彈性主要講的是系統(tǒng)中一部分出現(xiàn)故障會引起多大問題。在單塊系統(tǒng)中，一個部分出現(xiàn)問題，可能導(dǎo)致整體系統(tǒng)的問題。而微服務(wù)架構(gòu)中，每個服務(wù)可以內(nèi)置可用性的解決方 案與功能降級方案，所以比單塊系統(tǒng)強。

(3)擴展

單塊系統(tǒng)中，我們要做擴展，往往是整體進行擴展。而在微服務(wù)架構(gòu)中，可以針對單個服務(wù)進行擴展。

(4)簡化部署

在大型單塊系統(tǒng)中，即使修改一行代碼，也需要重新部署整個應(yīng)用系統(tǒng)。這種部署的影響很大、風險很高，因此不敢輕易地重新部署。而微服務(wù)架構(gòu)中，每個服務(wù)的部署都是 獨立的，這樣就可以更快地對特定部分的代碼進行部署。

(5)與結(jié)織結(jié)構(gòu)相匹配

我們都知道，團隊越大越難管理，同時團隊越大也代表系統(tǒng)規(guī)模越大代碼庫越大，這樣容易引起一系列的問題。且當團隊是分布式的時候，問題更嚴重。微服務(wù)架構(gòu)就能很好地解決這個問題，微服務(wù)架構(gòu)可以將架構(gòu)與組織結(jié)構(gòu)相匹配，避免出現(xiàn)過大的代碼庫，從而獲得理想的團隊大小及生產(chǎn)力。服務(wù)的所有權(quán)也可以在團隊之 間遷移，從而避免異地團隊的出現(xiàn)。

(6)可組合性

在微服務(wù)架構(gòu)中，系統(tǒng)會開放很多接口供外部使用。當情況發(fā)生改變時，可以使用不同的方式構(gòu)建應(yīng)用，而整體化應(yīng)用程序只能提供一個非常粗粒度的接口供外部使用。

(7)對可替代性的優(yōu)化

在單塊系統(tǒng)中如果刪除系統(tǒng)中的上百行代碼，也許不知道會發(fā)生什么，引起什么樣的問題，因為單塊系統(tǒng)中關(guān)聯(lián)性很強。但在微服務(wù)架構(gòu)中，我們可以在需要時輕易地重寫服務(wù)，或者刪除不再使用的服務(wù)。

2. 微服務(wù)面臨的挑戰(zhàn)

軟件開發(fā)業(yè)內(nèi)有一句名言“軟件開發(fā)沒有銀彈”，雖然前面介紹了微服務(wù)很多方面的優(yōu)勢，但微服務(wù)并不能解決所有問題。下面我們來分析在使用微服務(wù)架構(gòu)時可能面臨的一些挑戰(zhàn)。

(1)分布式系統(tǒng)的復(fù)雜度

使用微服務(wù)實現(xiàn)分布式系統(tǒng)的復(fù)雜度要比單塊系統(tǒng)高。這表現(xiàn)在多個方面，如：性能方面微服務(wù)是拆分成多個服務(wù)進行部署，服務(wù)間的通信都是通過網(wǎng)絡(luò)，此時的性能會受影響。同時可靠性也會受影響。數(shù)據(jù)一致性也需要嚴格控制，其成本也比單塊系統(tǒng)高。

(2)運維成本

相比傳統(tǒng)的單塊架構(gòu)應(yīng)用，微服務(wù)將系統(tǒng)分成多個獨立的部分，每個部分都是可以獨立部署的業(yè)務(wù)單元。這就意味著，原來適用于單塊架構(gòu)的集中式的部署、配置、監(jiān)控或者日志收集等方式，在微服務(wù)架構(gòu)下，隨著服務(wù)數(shù)量的增多，每個服務(wù)都需要獨立的配置、部署、監(jiān)控、日志收集等，因此成本呈指數(shù)級增長。

(3)部署自動化

傳統(tǒng)單塊系統(tǒng)部署往往是以月、周為單位，部署頻度很低，在這種情況下，手動部署是可以滿足需求的。而對于微服務(wù)架構(gòu)而言，每個服務(wù)都是一個獨立可部署的業(yè)務(wù)單元，每個服務(wù)的修改都需要獨立部署。這樣部署的成本是比較高的，如亞馬遜，每天都要執(zhí)行數(shù)十次、甚至上百次的部署，此時仍用人工部署是行不通的，要使用自動化部署。如何有效地構(gòu)建自動化部署流水線，降低部署成本、提高部署頻率，是微服務(wù)架構(gòu)下需要面臨的一個挑戰(zhàn)。

(4)DevOps 與組織結(jié)構(gòu)

傳統(tǒng)單塊架構(gòu)中，團隊通常是按技能劃分，如開發(fā)部、測試部、運維部，并通過項目的方式協(xié)作，完成系統(tǒng)交付。而在微服務(wù)架構(gòu)的實施過程中，除了如上所述的交付、運維上存在的挑戰(zhàn)，在組織或者團隊層面，如何傳遞 DevOps 文化的價值，讓團隊理解 DevOps 文化的價值，并構(gòu)建全功能團隊，也是一個不小的挑戰(zhàn)。

微服務(wù)不僅表現(xiàn)出一種架構(gòu)模型，同樣也表現(xiàn)出一種組織模型。這種新型的組織模型意味著開發(fā)人員和運維的角色發(fā)生了變化，開發(fā)者將承擔起服務(wù)整個生命周期的責任，包括部署和監(jiān)控，而運維也越來越多地表現(xiàn)出一種顧問式的角色，盡早考慮服務(wù)如何部署。因此，如何在微服務(wù)的實施中，按需調(diào)整組織架構(gòu)，構(gòu)建全功能的團隊，是一個不小的挑戰(zhàn)。

(5)服務(wù)間依賴測試

由于微服務(wù)架構(gòu)是把系統(tǒng)拆分為若干個可獨立部署的服務(wù)，所以需要進行服務(wù)間的依賴測試。在服務(wù)數(shù)量較多的情況下，如何有效地保證服務(wù)之間能有效按照接口的約定正常工作，成為微服務(wù)實施過程中必須面臨的巨大挑戰(zhàn)。

(6)服務(wù)間依賴管理

傳統(tǒng)的單塊系統(tǒng)，功能實現(xiàn)比較集中，大部分功能都運行在同一個應(yīng)用中，同其他系統(tǒng)依賴較少。而微服務(wù)架構(gòu)則不同，在將系統(tǒng)功能拆分成相互協(xié)作的獨立服務(wù)之后，隨著微服務(wù)個數(shù)的增多，如何清晰有效地展示服務(wù)之間的依賴關(guān)系，成為了一個挑戰(zhàn)。

9.微服務(wù)與 SOA

微服務(wù)可以講是 SOA 的一種，但仔細分析與推敲，我們又能發(fā)現(xiàn)他們的一些差異。這種差異表現(xiàn)在多個方面，具體如表 9-8 所示。

這些差異自然影響到其實現(xiàn)，在實現(xiàn)方面的主要差異如表 9-9 所示。

審核編輯：湯梓紅