1.定義介紹

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

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

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

2.SOA的概念

SOA 是一種在計算環境中設計、開發、部署和管理離散邏輯單元(服務)模型的方法。SOA 并不是一個新鮮事物，而只是面向對象模型的一種替代。雖然基于 SOA 的系統并不排除使用 OOD 來構建單個服務，但是其整體設計卻是面向服務的。由于 SOA 考慮到了系統內的對象，所以雖然SOA 是基于對象的，但是作為一個整體，它卻不是面向對象的。

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

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

3 服務的基本結構

一個獨立的服務基本結構如圖 9-14 所示。

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

4.SOA 設計原則

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

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

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

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

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

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

5. 服務構件與傳統構件

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

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

6 SOA 的關鍵技術

SOA 伴隨著無處不在的標準，為企業的現有資產或投資帶來了更好的復用性。SOA 能夠在最新的和現有的系統之上創建應用，借助現有的應用產生新的服務，為企業提供更好的靈活性來構建系統和業務流程。SOA 是一種全新的架構，為了支持其各種特性，相關的技術規范不斷推出。與 SOA 緊密相關的技術主要有 UDDI、WSDL、SOAP 和 REST 等，而這些技術都是以 XML 為基礎而發展起來的。

1. UDDI

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

在 UDDI 技術規范中，主要包含以下三個部分的內容：

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

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

(3)注冊服務。UDDI 注冊服務是 SOA 中的一種基礎設施，對應著服務注冊中心的角色。

2.WSDL

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

采用抽象接口定義對于提高系統的擴展性很有幫助。服務接口定義就是一種抽象的、可重用的定義，行業標準組織可以使用這種抽象的定義來規定一些標準的服務類型，服務實現者可以根據這些標準定義來實現具體的服務。

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

3.SOAP

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

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

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

(3)RPC 表示。SOAP RPC 表示定義了一個用來表示遠程過程調用和應答的協議。

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

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

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

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

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

4.REST

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

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

7 SOA 的實現方法

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

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

1.Web Service

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

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

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

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

Web Service 模型中的操作包括發布、查找和綁定，這些操作可以單次或反復出現。

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

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

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

在采用 Web Service 作為 SOA 的實現技術時，應用系統大致可以分為六個層次，分別是底層傳輸層、服務通信協議層、服務描述層、 服務層、業務流程層和服務注冊層。

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

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

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

(4)服務層。服務層的主要功能是將遺留系統進行包裝，并通過發布的 WSDL 接口描述被定位和調用。

(5)業務流程層。業務流程層的主要功能是支持服務發現，服務調用和點到點的服務調用，并將業務流程從服務的底層調用抽象出來。

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

2. 服務注冊表

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

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

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

(3)服務綁定。服務使用者利用查找到的服務合約來開發代碼，開發的代碼將與注冊的服務進行綁定，調用注冊的服務，以及與它們實現互動。可以利用集成的開發環境自動將新開發的服務與不同的新協議、方案和程序間通信所需的其他接口綁定在一起。

3. 企業服務總線

ESB 的概念是從 SOA 發展而來的，它是一種為進行連接服務提供的標準化的通信基礎結構，基于開放的標準，為應用提供了一個可靠的、可度量的和高度安全的環境，并可幫助企業對業務流程進行設計和模擬，對每個業務流程實施控制和跟蹤、分析并改進流程和性能。

在一個復雜的企業計算環境中，如果服務提供者和服務請求者之間采用直接的端到端的交互，那么隨著企業信息系統的增加和復雜度的提高，系統之間的關聯會逐漸變得非常復雜，形成一個網狀結構，這將帶來昂貴的系統維護費用，同時也使得 IT 基礎設施的復用變得困難重重。ESB 提供了一種基礎設施，消除了服務請求者與服務提供者之間的直接連接，使得服務請求者與服務提供者之間進一步解耦。

ESB 是由中間件技術實現并支持 SOA的一組基礎架構，是傳統中間件技術與 XML、 Web Service 等技術結合的產物，是在整個企業集成架構下的面向服務的企業應用集成機制。具體來說，ESB 具有以下功能：

(1)支持異構環境中的服務、消息和基于事件的交互，并且具有適當的服務級別和可管理性。

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

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

(4)在更高的層次，ESB 還提供諸如服務代理和協議轉換等功能。允許在多種形式下通過像HTTP、SOAP 和 JMS 總線的多種傳輸方式，主要是以網絡服務的形式，為發表、注冊、發現和使用企業服務或界面提供基礎設施。

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

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

在企業應用集成方面，與現存的、專有的集成解決方案相比，ESB 具有以下優勢：

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

(2)靈活的、服務導向的應用組合。基于 SOA，ESB 使復雜的分布式系統(包括跨多個應用、系統和防火墻的集成方案)能夠由以前開發測試過的服務組合而成，使系統具有高度可擴展性。

(3)提高復用率，降低成本。按照 SOA 方法構建應用，提高了復用率，簡化了維護工作，進而減少了系統總體成本。

(4)減少市場反應時間，提高生產率。ESB 通過構件和服務復用，按照 SOA 的思想簡化應用組合，基于標準的通信、轉換和連接來實現這些優點。

8 微服務

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

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

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

1.微服務的優勢

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

(1)技術異構性

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

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

(2)彈性

彈性主要講的是系統中一部分出現故障會引起多大問題。在單塊系統中，一個部分出現問題，可能導致整體系統的問題。而微服務架構中，每個服務可以內置可用性的解決方 案與功能降級方案，所以比單塊系統強。

(3)擴展

單塊系統中，我們要做擴展，往往是整體進行擴展。而在微服務架構中，可以針對單個服務進行擴展。

(4)簡化部署

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

(5)與結織結構相匹配

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

(6)可組合性

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

(7)對可替代性的優化

在單塊系統中如果刪除系統中的上百行代碼，也許不知道會發生什么，引起什么樣的問題，因為單塊系統中關聯性很強。但在微服務架構中，我們可以在需要時輕易地重寫服務，或者刪除不再使用的服務。

2. 微服務面臨的挑戰

軟件開發業內有一句名言“軟件開發沒有銀彈”，雖然前面介紹了微服務很多方面的優勢，但微服務并不能解決所有問題。下面我們來分析在使用微服務架構時可能面臨的一些挑戰。

(1)分布式系統的復雜度

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

(2)運維成本

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

(3)部署自動化

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

(4)DevOps 與組織結構

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

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

(5)服務間依賴測試

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

(6)服務間依賴管理

傳統的單塊系統，功能實現比較集中，大部分功能都運行在同一個應用中，同其他系統依賴較少。而微服務架構則不同，在將系統功能拆分成相互協作的獨立服務之后，隨著微服務個數的增多，如何清晰有效地展示服務之間的依賴關系，成為了一個挑戰。

9.微服務與 SOA

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

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

審核編輯：湯梓紅