1.定義介紹

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

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

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

2.SOA的概念

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

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

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

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

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

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

4.SOA 設(shè)計(jì)原則

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

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

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

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

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

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

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)的模型。它可簡(jiǎn)化使用 SOA 進(jìn)行的應(yīng)用程序開發(fā)和實(shí)現(xiàn)工作。SCA 提供了構(gòu)建粗粒度構(gòu)件的機(jī)制，這些粗粒度構(gòu)件由細(xì)粒度構(gòu)件組裝而成。SCA 將傳統(tǒng)中間件編程從業(yè)務(wù)邏輯分離出來，從而使程序員免受其復(fù)雜性的困擾。它允許開發(fā)人員集中精力編寫業(yè)務(wù)邏輯，而不必將大量的時(shí)間花費(fèi)在更為底層的技術(shù)實(shí)現(xiàn)上。

SCA 服務(wù)構(gòu)件與傳統(tǒng)構(gòu)件的主要區(qū)別在于，服務(wù)構(gòu)件往往是粗粒度的，而傳統(tǒng)構(gòu)件以細(xì)粒度居多;服務(wù)構(gòu)件的接口是標(biāo)準(zhǔn)的，主要是服務(wù)描述語言接口，而傳統(tǒng)構(gòu)件常以具體 API 形式出現(xiàn);服務(wù)構(gòu)件的實(shí)現(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 伴隨著無處不在的標(biāo)準(zhǔn)，為企業(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ù)的信息注冊(cè)規(guī)范，以便被需要該服務(wù)的用戶發(fā)現(xiàn)和使用它。UDDI 規(guī)范描述了服務(wù)的概念，同時(shí)也定義了一種編程接口。通過 UDDI 提供的標(biāo)準(zhǔn)接口，企業(yè)可以發(fā)布自己的服務(wù)供其他企業(yè)查詢和調(diào)用，也可以查詢特定服務(wù)的描述信息，并動(dòng)態(tài)綁定到該服務(wù)上。

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

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

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

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

2.WSDL

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

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

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

3.SOAP

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

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

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

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

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

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

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

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

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

4.REST

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

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

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

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

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

1.Web Service

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 服務(wù)注冊(cè)表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8 微服務(wù)

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

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

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

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

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

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

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

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

(2)彈性

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

(3)擴(kuò)展

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

(4)簡(jiǎn)化部署

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

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

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

(6)可組合性

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

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

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

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

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

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

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

(2)運(yùn)維成本

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

(3)部署自動(dòng)化

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

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

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

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

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

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

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

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

9.微服務(wù)與 SOA

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

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

審核編輯：湯梓紅