1.定義介紹

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

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

SOA將能夠幫助軟件工程師們站在一個(gè)新的高度理解企業(yè)級(jí)架構(gòu)中的各種組件的開(kāi)發(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ì)、開(kāi)發(fā)、部署和管理離散邏輯單元(服務(wù))模型的方法。SOA 并不是一個(gè)新鮮事物，而只是面向?qū)ο竽Ｐ偷囊环N替代。雖然基于 SOA 的系統(tǒng)并不排除使用 OOD 來(lái)構(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ǔ)上，通過(guò)使用基于 XML 的語(yǔ)言來(lái)描述接口，服務(wù)已經(jīng)轉(zhuǎn)到更動(dòng)態(tài)且更靈活的接口系統(tǒng)中，CORBA 中的 IDL 無(wú)法與之相比。如下圖9-13 描述了一個(gè)完整的 SOA 模型。

在 SOA 模型中，所有的功能都定義成了獨(dú)立的服務(wù)。服務(wù)之間通過(guò)交互和協(xié)調(diào)完成業(yè)務(wù)的整體邏輯。所有的服務(wù)通過(guò)服務(wù)總線或流程管理器來(lái)連接。這種松散耦合的架構(gòu)使得各服務(wù)在交互過(guò)程中無(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ù)模型的表示層從邏輯層分離出來(lái)，中間增加了服務(wù)對(duì)外的接口層。通過(guò)服務(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)行、是由哪種語(yǔ)言編寫(xiě)的，以及消息的傳輸路徑，而是只需要提出服務(wù)請(qǐng)求，然后就會(huì)得到答案。

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

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

(1)明確定義的接口。服務(wù)請(qǐng)求者依賴(lài)于服務(wù)規(guī)約來(lái)調(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)程過(guò)程調(diào)用，通常消息量比較大，但是服務(wù)之間的交互頻度較低。

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

(5)互操作性、兼容和策略聲明。為了確保服務(wù)規(guī)約的全面和明確，策略成為一個(gè)越來(lái)越重要的方面。這可以是技術(shù)相關(guān)的內(nèi)容，例如，一個(gè)服務(wù)對(duì)安全性方面的要求;也可以是與業(yè)務(wù)有關(guān)的語(yǔ)義方面的內(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)用程序開(kāi)發(fā)和實(shí)現(xiàn)工作。SCA 提供了構(gòu)建粗粒度構(gòu)件的機(jī)制，這些粗粒度構(gòu)件由細(xì)粒度構(gòu)件組裝而成。SCA 將傳統(tǒng)中間件編程從業(yè)務(wù)邏輯分離出來(lái)，從而使程序員免受其復(fù)雜性的困擾。它允許開(kāi)發(fā)人員集中精力編寫(xiě)業(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ù)描述語(yǔ)言接口，而傳統(tǒng)構(gòu)件常以具體 API 形式出現(xiàn);服務(wù)構(gòu)件的實(shí)現(xiàn)與語(yǔ)言是無(wú)關(guān)的，而傳統(tǒng)構(gòu)件常綁定某種特定的語(yǔ)言;服務(wù)構(gòu)件可以通過(guò)構(gòu)件容器提供 QoS 的服務(wù)，而傳統(tǒng)構(gòu)件完全由程序代碼直接控制。

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

SOA 伴隨著無(wú)處不在的標(biāo)準(zhǔn)，為企業(yè)的現(xiàn)有資產(chǎn)或投資帶來(lái)了更好的復(fù)用性。SOA 能夠在最新的和現(xiàn)有的系統(tǒng)之上創(chuàng)建應(yīng)用，借助現(xiàn)有的應(yīng)用產(chǎn)生新的服務(wù)，為企業(yè)提供更好的靈活性來(lái)構(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ā)展起來(lái)的。

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í)也定義了一種編程接口。通過(guò) UDDI 提供的標(biāo)準(zhǔn)接口，企業(yè)可以發(fā)布自己的服務(wù)供其他企業(yè)查詢(xún)和調(diào)用，也可以查詢(xún)特定服務(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ù)描述語(yǔ)言)是對(duì)服務(wù)進(jìn)行描述的語(yǔ)言，它有一套基于 XML 的語(yǔ)法定義。WSDL 描述的重點(diǎn)是服務(wù)，它包含服務(wù)實(shí)現(xiàn)定義和服務(wù)接口定義，如圖 9-15 所示。

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

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

3.SOAP

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

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

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

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

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

SOAP 消息基本上是從發(fā)送端到接收端的單向傳輸，但它們常常結(jié)合起來(lái)執(zhí)行類(lèi)似于請(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 定義了少量的屬性用來(lái)表明這項(xiàng)要素是否可選以及由誰(shuí)來(lái)處理。SOAP 頭在 SOAP 消息中可能出現(xiàn)，也可能不出現(xiàn)。如果出現(xiàn)的話，必須是 SOAP 封裝元素的第一個(gè)直接子元素。

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

4.REST

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

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

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

SOA 只是一種概念和思想，需要借助于具體的技術(shù)和方法來(lái)實(shí)現(xiàn)它。從本質(zhì)上來(lái)看， SOA 是用本地計(jì)算模型來(lái)實(shí)現(xiàn)一個(gè)分布式的計(jì)算應(yīng)用，也有人稱(chēng)這種方法為“本地化設(shè)計(jì)，分布式工作”模型。CORBA、DCOM 和 EJB 等都屬于這種解決方式，也就是說(shuō)，SOA 最終可以基于這些標(biāo)準(zhǔn)來(lái)實(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é)中介紹，此處不再贅述。

從邏輯上和高層抽象來(lái)看，目前，實(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)求者角色可以由瀏覽器來(lái)?yè)?dān)當(dāng)，由人或程序(例如，另外一個(gè)服務(wù))來(lái)控制。

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

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

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

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

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

(6)服務(wù)注冊(cè)層的主要功能是使服務(wù)提供者能夠通過(guò) 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)件的配置、依從性和約束文件。從理論上來(lái)說(shuō)，任何幫助服務(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ā)布、由誰(shuí)發(fā)布以及誰(shuí)批準(zhǔn)和根據(jù)什么條件批準(zhǔn)等，以便使服務(wù)能夠有序的注冊(cè)。

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

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

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

ESB 的概念是從 SOA 發(fā)展而來(lái)的，它是一種為進(jìn)行連接服務(wù)提供的標(biāo)準(zhǔn)化的通信基礎(chǔ)結(jié)構(gòu)，基于開(kāi)放的標(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)，這將帶來(lái)昂貴的系統(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ī)制。具體來(lái)說(shuō)，ESB 具有以下功能：

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

(2)通過(guò)使用 ESB，可以在幾乎不更改代碼的情況下，以一種無(wú)縫的非侵入方式使現(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)換等功能。允許在多種形式下通過(guò)像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)存的、專(zhuā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 通過(guò)使用 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)和防火墻的集成方案)能夠由以前開(kāi)發(fā)測(cè)試過(guò)的服務(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 通過(guò)構(gòu)件和服務(wù)復(fù)用，按照 SOA 的思想簡(jiǎn)化應(yīng)用組合，基于標(biāo)準(zhǔn)的通信、轉(zhuǎn)換和連接來(lái)實(shí)現(xiàn)這些優(yōu)點(diǎn)。

8 微服務(wù)

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

從專(zhuān)業(yè)的角度來(lái)看，微服務(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)境、類(lèi)生產(chǎn)環(huán)境等。另外，應(yīng)當(dāng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語(yǔ)言、工具對(duì)其進(jìn)行構(gòu)建。

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

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

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

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

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

同時(shí)，在應(yīng)用新技術(shù)時(shí)，微服務(wù)架構(gòu)也提供了更好的試驗(yàn)場(chǎng)。因?yàn)閷?duì)于單塊的系統(tǒng)而 言，采用一個(gè)新的語(yǔ)言、數(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ì)引起多大問(wèn)題。在單塊系統(tǒng)中，一個(gè)部分出現(xiàn)問(wèn)題，可能導(dǎo)致整體系統(tǒng)的問(wèn)題。而微服務(wù)架構(gòu)中，每個(gè)服務(wù)可以?xún)?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ù)越大，這樣容易引起一系列的問(wèn)題。且當(dāng)團(tuán)隊(duì)是分布式的時(shí)候，問(wèn)題更嚴(yán)重。微服務(wù)架構(gòu)就能很好地解決這個(gè)問(wèn)題，微服務(wù)架構(gòu)可以將架構(gòu)與組織結(jié)構(gòu)相匹配，避免出現(xiàn)過(guò)大的代碼庫(kù)，從而獲得理想的團(tuán)隊(duì)大小及生產(chǎn)力。服務(wù)的所有權(quán)也可以在團(tuán)隊(duì)之 間遷移，從而避免異地團(tuán)隊(duì)的出現(xiàn)。

(6)可組合性

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

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

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

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

軟件開(kāi)發(fā)業(yè)內(nèi)有一句名言“軟件開(kāi)發(fā)沒(méi)有銀彈”，雖然前面介紹了微服務(wù)很多方面的優(yōu)勢(shì)，但微服務(wù)并不能解決所有問(wèn)題。下面我們來(lái)分析在使用微服務(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ù)間的通信都是通過(guò)網(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ù)單元。這就意味著，原來(lái)適用于單塊架構(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ì)通常是按技能劃分，如開(kāi)發(fā)部、測(cè)試部、運(yùn)維部，并通過(guò)項(xiàng)目的方式協(xié)作，完成系統(tǒng)交付。而在微服務(wù)架構(gòu)的實(shí)施過(guò)程中，除了如上所述的交付、運(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)出一種組織模型。這種新型的組織模型意味著開(kāi)發(fā)人員和運(yùn)維的角色發(fā)生了變化，開(kāi)發(fā)者將承擔(dān)起服務(wù)整個(gè)生命周期的責(zé)任，包括部署和監(jiān)控，而運(yùn)維也越來(lái)越多地表現(xiàn)出一種顧問(wèn)式的角色，盡早考慮服務(wù)如何部署。因此，如何在微服務(wù)的實(shí)施中，按需調(diào)整組織架構(gòu)，構(gòu)建全功能的團(tuán)隊(duì)，是一個(gè)不小的挑戰(zhàn)。

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

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

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

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

審核編輯：湯梓紅