文章比較多，但幹貨慢慢，請耐心閱讀
目錄
面向服務的架構
1 SOA 概述
1. 服務的基本結構
2.SOA 設計原則
3. 服務構件與傳統構件
2 SOA 的關鍵技術
1. UDDI
2.WSDL
3.SOAP
4.REST
3 SOA 的實作方法
1.Web Service
2. 服務系統資料庫
3. 企業服務總線
4 微服務
1.微服務的優勢
2. 微服務面臨的挑戰
3.微服務與 SOA
面向服務的架構
迄今為止，對于面向服務的架構（Service-Oriented Architecture，SOA）還沒有一個公認的定義。許多組織從不同的角度和不同的側面對 SOA 進行了描述，較為典型的有以下三個：
（1）W3C 的定義：SOA 是一種應用程式架構，在這種架構中，所有功能都定義為獨立的服務，這些服務帶有定義明确的可調用接口，能夠以定義好的順序調用這些服務來形成業務流程。
（2）Service-architecture.com 的定義：服務是精确定義、封裝完善、獨立于其他服務所處環境和狀态的函數。SOA 本質上是服務的集合，服務之間彼此通信，這種通信可能是簡單的資料傳送，也可能是兩個或更多的服務協調進行某些活動。服務之間需要某些方法進行連接配接。
（3）Gartner 的定義：SOA 是一種 C/S 架構的軟體設計方法，應用由服務和服務使用者組成，SOA 與大多數通用的 C/S 架構模型不同之處，在于它着重強調構件的松散耦合，并使用獨立的标準接口。
1 SOA 概述
SOA 是一種在計算環境中設計、開發、部署和管理離散邏輯單元（服務）模型的方法。 SOA 并不是一個新鮮事物，而隻是面向對象模型的一種替代。雖然基于 SOA 的系統并不排除使用 OOD 來建構單個服務，但是其整體設計卻是面向服務的。由于 SOA 考慮到了系統内的對象，是以雖然SOA 是基于對象的，但是作為一個整體，它卻不是面向對象的。
SOA 系統原型的一個典型例子是 CORBA，它已經出現很長時間，其定義的概念與 SOA 相似。SOA 建立在 XML 等新技術的基礎上，通過使用基于 XML 的語言來描述接口，服務已經轉到更動态且更靈活的接口系統中，CORBA 中的 IDL 無法與之相比。圖 9-13 描述了一個完整的 SOA 模型。
在 SOA 模型中，所有的功能都定義成了獨立的服務。服務之間通過互動和協調完成業務的整體邏輯。所有的服務通過服務總線或流程管理器來連接配接。這種松散耦合的架構使得各服務在互動過程中無需考慮雙方的内部實作細節，以及部署在什麼平台上。
1. 服務的基本結構
一個獨立的服務基本結構如圖 9-14 所示。
由圖 9-14 可以看出，服務模型的表示層從邏輯層分離出來，中間增加了服務對外的接口層。通過服務接口的标準化描述，使得服務可以提供給在任何異構平台和任何使用者接口使用。這允許并支援基于服務的系統成為松散耦合、面向構件和跨技術實作，服務請求者很可能根本不知道服務在哪裡運作、是由哪種語言編寫的，以及消息的傳輸路徑，而是隻需要提出服務請求，然後就會得到答案。
2.SOA 設計原則
在 SOA 架構中，繼承了來自對象和構件設計的各種原則，例如，封裝和自我包含等。那些保證服務的靈活性、松散耦合和複用能力的設計原則，對 SOA 架構來說同樣是非常重要的。關于服務，一些常見的設計原則如下：
（1）明确定義的接口。服務請求者依賴于服務規約來調用服務，是以，服務定義必須長時間穩定，一旦公布，不能随意更改；服務的定義應盡可能明确，減少請求者的不适當使用；不要讓請求者看到服務内部的私有資料。
（2）自包含和子產品化。服務封裝了那些在業務上穩定、重複出現的活動和構件，實作服務的功能實體是完全獨立自主的，獨立進行部署、版本控制、自我管理和恢複。
（3）粗粒度。服務數量不應該太多，依靠消息互動而不是遠端過程調用，通常消息量比較大，但是服務之間的互動頻度較低。
（4）松耦合。服務請求者可見的是服務的接口，其位置、實作技術、目前狀态和私有資料等，對服務請求者而言是不可見的。
（5）互操作性、相容和政策聲明。為了確定服務規約的全面和明确，政策成為一個越來越重要的方面。這可以是技術相關的内容，例如，一個服務對安全性方面的要求；也可以是與業務有關的語義方面的内容，例如，需要滿足的費用或者服務級别方面的要求，這些政策對于服務在互動時是非常重要的。
3. 服務構件與傳統構件
服務構件架構（Service Component Architecture，SCA）是基于 SOA 的思想描述服務之間組合和協作的規範，它描述用于使用 SOA 建構應用程式和系統的模型。它可簡化使用 SOA 進行的應用程式開發和實作工作。SCA 提供了建構粗粒度構件的機制，這些粗粒度構件由細粒度構件組裝而成。SCA 将傳統中間件程式設計從業務邏輯分離出來，進而使程式員免受其複雜性的困擾。它允許開發人員集中精力編寫業務邏輯，而不必将大量的時間花費在更為底層的技術實作上。
SCA 服務構件與傳統構件的主要差別在于，服務構件往往是粗粒度的，而傳統構件以細粒度居多；服務構件的接口是标準的，主要是服務描述語言接口，而傳統構件常以具體 API 形式出現；服務構件的實作與語言是無關的，而傳統構件常綁定某種特定的語言；服務構件可以通過構件容器提供 QoS 的服務，而傳統構件完全由程式代碼直接控制。
2 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）所有的操作都是無狀态的。
3 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 的思想簡化應用組合，基于标準的通信、轉換和連接配接來實作這些優點。
4 微服務
微服務顧名思義，就是很小的服務，是以它屬于面向服務架構的一種。通俗一點來說，微服務類似于古代著名的發明，活字印刷術，每個服務都是一個元件，通過編排組合的方式來使用，進而真正做到了獨立、解耦、元件化、易維護、可複用、可替換、高可用、最終達到提高傳遞品質、縮短傳遞周期的效果。
從專業的角度來看，微服務架構是一種架構模式，它提倡将單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務運作在其獨立的程序中，服務與服務間采用輕量級的通信機制互相溝通（通常是基于 HTTP 協定的 RESTful API）。每個服務都圍繞着具體業務進行建構，并且能夠被獨立的部署到生産環境、類生産環境等。另外，應當盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合适的語言、工具對其進行建構。
是以總結起來，微服務的核心特點為：小, 且專注于做⼀件事情、輕量級的通信機制、松耦合、獨立部署。
1.微服務的優勢
微服務之是以能盛行，必然是有它獨特優勢的，下面我們來分析微服務有哪些方面的優勢。
（1）技術異構性
在微服務架構中，每個服務都是一個相對獨立的個體，每個服務都可以選擇适合于自身的技術來實作。如，要開發一個社交平台，此時，我們可能使用文檔型資料庫來存儲帖 子的内容，使用圖資料來存儲朋友圈的這些關系等，這樣可以把每一塊的性能都充分發揮 出來。
同時，在應用新技術時，微服務架構也提供了更好的試驗場。因為對于單塊的系統而 言，采用一個新的語言、資料庫或者架構都會對整個系統産生巨大的影響，這樣導緻我們 想嘗試新技術時，望而卻步。但微服務不同，我們完全可以隻在一個微服務中采用新技術， 待技術使用熟練之後，再推廣到其他服務。
（2）彈性
彈性主要講的是系統中一部分出現故障會引起多大問題。在單塊系統中，一個部分出現問題，可能導緻整體系統的問題。而微服務架構中，每個服務可以内置可用性的解決方 案與功能降級方案，是以比單塊系統強。
（3）擴充
單塊系統中，我們要做擴充，往往是整體進行擴充。而在微服務架構中，可以針對單個服務進行擴充。
（4）簡化部署
在大型單塊系統中，即使修改一行代碼，也需要重新部署整個應用系統。這種部署的影響很大、風險很高，是以不敢輕易地重新部署。而微服務架構中，每個服務的部署都是 獨立的，這樣就可以更快地對特定部分的代碼進行部署。
（5）與結織結構相比對
我們都知道，團隊越大越難管理，同時團隊越大也代表系統規模越大代碼庫越大，這樣容易引起一系列的問題。且當團隊是分布式的時候，問題更嚴重。微服務架構就能很好地解決這個問題，微服務架構可以将架構與組織結構相比對，避免出現過大的代碼庫，進而獲得理想的團隊大小及生産力。服務的所有權也可以在團隊之 間遷移，進而避免異地團隊的出現。
（6）可組合性
在微服務架構中，系統會開放很多接口供外部使用。當情況發生改變時，可以使用不同的方式建構應用，而整體化應用程式隻能提供一個非常粗粒度的接口供外部使用。
（7）對可替代性的優化
在單塊系統中如果删除系統中的上百行代碼，也許不知道會發生什麼，引起什麼樣的問題，因為單塊系統中關聯性很強。但在微服務架構中，我們可以在需要時輕易地重寫服務，或者删除不再使用的服務。
2. 微服務面臨的挑戰
軟體開發業内有一句名言“軟體開發沒有銀彈”，雖然前面介紹了微服務很多方面的優勢，但微服務并不能解決所有問題。下面我們來分析在使用微服務架構時可能面臨的一些挑戰。
（1）分布式系統的複雜度
使用微服務實作分布式系統的複雜度要比單塊系統高。這表現在多個方面，如：性能方面微服務是拆分成多個服務進行部署，服務間的通信都是通過網絡，此時的性能會受影響。同時可靠性也會受影響。資料一緻性也需要嚴格控制，其成本也比單塊系統高。
（2）運維成本
相比傳統的單塊架構應用，微服務将系統分成多個獨立的部分，每個部分都是可以獨立部署的業務單元。這就意味着，原來适用于單塊架構的集中式的部署、配置、監控或者日志收集等方式，在微服務架構下，随着服務數量的增多，每個服務都需要獨立的配置、部署、監控、日志收集等，是以成本呈指數級增長。
（3）部署自動化
傳統單塊系統部署往往是以月、周為機關，部署頻度很低，在這種情況下，手動部署是可以滿足需求的。而對于微服務架構而言，每個服務都是一個獨立可部署的業務單元，每個服務的修改都需要獨立部署。這樣部署的成本是比較高的，如亞馬遜，每天都要執行數十次、甚至上百次的部署，此時仍用人工部署是行不通的，要使用自動化部署。如何有效地建構自動化部署流水線，降低部署成本、提高部署頻率，是微服務架構下需要面臨的一個挑戰。
（4）DevOps 與組織結構
傳統單塊架構中，團隊通常是按技能劃分，如開發部、測試部、運維部，并通過項目的方式協作，完成系統傳遞。而在微服務架構的實施過程中，除了如上所述的傳遞、運維上存在的挑戰，在組織或者團隊層面，如何傳遞 DevOps 文化的價值，讓團隊了解 DevOps 文化的價值，并建構全功能團隊，也是一個不小的挑戰。
微服務不僅表現出一種架構模型，同樣也表現出一種組織模型。這種新型的組織模型意味着開發人員和運維的角色發生了變化，開發者将承擔起服務整個生命周期的責任，包括部署和監控，而運維也越來越多地表現出一種顧問式的角色，盡早考慮服務如何部署。是以，如何在微服務的實施中，按需調整組織架構，建構全功能的團隊，是一個不小的挑戰。
（5）服務間依賴測試
由于微服務架構是把系統拆分為若幹個可獨立部署的服務，是以需要進行服務間的依賴測試。在服務數量較多的情況下，如何有效地保證服務之間能有效按照接口的約定正常工作，成為微服務實施過程中必須面臨的巨大挑戰。
（6）服務間依賴管理
傳統的單塊系統，功能實作比較集中，大部分功能都運作在同一個應用中，同其他系統依賴較少。而微服務架構則不同，在将系統功能拆分成互相協作的獨立服務之後，随着微服務個數的增多，如何清晰有效地展示服務之間的依賴關系，成為了一個挑戰。
3.微服務與 SOA
微服務可以講是 SOA 的一種，但仔細分析與推敲，我們又能發現他們的一些差異。這種差異表現在多個方面，具體如表 9-8 所示。
這些差異自然影響到其實作，在實作方面的主要差異如表 9-9 所示。
---------------------
作者：hu19930613
來源：CSDN
原文：https://blog.csdn.net/hu19930613/article/details/82749534
版權聲明：本文為部落客原創文章，轉載請附上博文連結！