面向服務的架構

迄今為止，對于面向服務的架構（Service-Oriented Architecture，SOA）還沒有一個公認的定義。許多組織從不同的角度和不同的側面對 SOA 進行了描述，較為典型的有以下三個：

（1）W3C 的定義：SOA 是一種應用程序架構，在這種架構中，所有功能都定義為獨立的服務，這些服務帶有定義明確的可調用接口，能夠以定義好的順序調用這些服務來形成業(yè)務流程。

（2）Service-architecture.com 的定義：服務是精確定義、封裝完善、獨立于其他服務所處環(huán)境和狀態(tài)的函數(shù)。SOA 本質上是服務的集合，服務之間彼此通信，這種通信可能是簡單的數(shù)據傳送，也可能是兩個或更多的服務協(xié)調進行某些活動。服務之間需要某些方法進行連接。

（3）Gartner 的定義：SOA 是一種 C/S 架構的軟件設計方法，應用由服務和服務使用者組成，SOA 與大多數(shù)通用的 C/S 架構模型不同之處，在于它著重強調構件的松散耦合，并使用獨立的標準接口。

SOA 概述

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

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

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

1. 服務的基本結構

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

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

2.SOA 設計原則

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

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

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

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

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

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

3. 服務構件與傳統(tǒng)構件

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

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

SOA 的關鍵技術

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

1. UDDI

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

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

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

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

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

2.WSDL

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

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

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

3.SOAP

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

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

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

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

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

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

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

（2）SOAP 頭。SOAP 頭的元素名是 Header，提供了向 SOAP 消息中添加關于這條 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)轉移）是一種只使用 HTTP 和 XML 進行基于 Web 通信的技術，可以降低開發(fā)的復雜性，提高系統(tǒng)的可伸縮性。它的簡單性和缺少嚴格配置文件的特性，使它與 SOAP 很好地隔離開來，REST 從根本上來說只支持幾個操作（POST、GET、PUT 和 DELETE），這些操作適用于所有的消息。REST 提出了如下一些設計概念和準則：

（1）網絡上的所有事物都被抽象為資源。

（2）每個資源對應一個唯一的資源標識。

（3）通過通用的連接件接口對資源進行操作。

（4）對資源的各種操作不會改變資源標識。

（5）所有的操作都是無狀態(tài)的。

SOA 的實現(xiàn)方法

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

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

1.Web Service

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 服務注冊表

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

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

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

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

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

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

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

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

（1）支持異構環(huán)境中的服務、消息和基于事件的交互，并且具有適當?shù)姆占墑e和可管理性。

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

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

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

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

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

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

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

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

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

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

微服務

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

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

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

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

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

（1）技術異構性

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

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

（2）彈性

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

（3）擴展

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

（4）簡化部署

在大型單塊系統(tǒng)中，即使修改一行代碼，也需要重新部署整個應用系統(tǒng)。這種部署的影響很大、風險很高，因此不敢輕易地重新部署。而微服務架構中，每個服務的部署都是 獨立的，庋涂梢愿斕囟蘊囟ú糠值拇虢脅渴稹�

（5）與結織結構相匹配

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

（6）可組合性

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

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

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

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

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

（1）分布式系統(tǒng)的復雜度

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

（2）運維成本

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

（3）部署自動化

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

（4）DevOps 與組織結構

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

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

（5）服務間依賴測試

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

（6）服務間依賴管理

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

3.微服務與 SOA

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

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