1.2 微服務架構

微服務架構這個術語在最近幾年的軟件開發方法論中漸成熱門，它把一種特定的軟件應用設計方法描述為能夠獨立部署的服務套件。目前對于微服務架構還缺乏統一的標準化定義，但其在業務建模、服務集成、數據去中心化等方面上的抽象和提煉已得到普遍認可。在討論微服務架構之前，我們先介紹一下微服務的概念。

1.2.1 微服務的概念

顧名思義，微服務區別于其他服務體系的關鍵在于它的“微”特性。“微”是“小”的同義詞，所以容易讓人聯想到微服務都是小型的服務，這是微服務的第一個特性。然而，目前業界并沒有給出一個關于微服務大小的具體劃分規則和標準，本節首先會針對微服務的“微”特性展開討論。另外，微服務之間只有通過相互的協作和交互才能構成完整的服務體系，而這種協作和交互機制也是微服務區別其他服務體系的另一個主要方面。

1.微服務的大小

通常我們可以使用代碼行數、開發時間來給微服務的大小添加一些約束條件，即滿足一定代碼行數或開發時間之內的服務才能稱為微服務。這些當然都是可衡量的量化標準，但針對具體業務場景往往不能簡單通過這些指標就能得到合理的微服務劃分結果。

我們認為微服務應該足夠小，小到專注于某一個具體業務功能，也就是說首先應該保證每個微服務是具有業務獨立性的工作單元。在考慮微服務時，我們需要根據業務邊界來確定服務的邊界，這樣就可以把該業務相關的內容都集中在微服務內部，從而體現了服務的高內聚性。

同時，服務的大小還跟團隊的規模和工作方式有較大關系。如果一個系統大到不能夠由一個獨立團隊進行開發和維護，那么將其拆分成適合這個團隊開發能力的服務無疑是合理的做法。而如果這個團隊本身的規模已經大到需要進行進一步分工和協作，那么先把團隊進行拆分，再根據團隊拆分的結果進行服務拆分也是一項最佳實踐。

然而，我們還需要認識到服務過小可能帶來的問題。服務越小，其獨立性和高內聚性能夠帶來優勢，但是也會導致服務數量太多，增加管理這些服務的成本。

2.微服務的交互

微服務代表一種具體的業務功能，具有高度的內聚性并運行于獨立的進程中。因此，微服務之間的交互是網絡環境下分布式的交互模式。

微服務之間通過遠程調用或消息傳遞的方式進行相互集成，能夠提供松耦合的架構體系，每個微服務都可以在不影響其他微服務的前提下進行獨立的修改、發布和部署。對于微服務而言，我們應該明確其對業務的抽象程度以及對外暴露這種抽象程度的方式。通常，服務接口（Interface）是每一個服務都會提供的訪問入口，這些接口應該確保實現上的技術無關性。

同時，在技術實現上，我們也需要確保微服務之間采用輕量級的通信方式進行交互，因為類似采用長連接方式進行通信的過程會導致服務之間不能很好地解耦，一旦出現問題，耦合性會觸發異常，在各個微服務之間進行擴散，從而導致整個服務體系不可用。這是我們在采用微服務時所需要極力避免的場景。對于輕量級通信機制而言，通常建議采用HTTP協議讓服務之間的通信變得標準化和無狀態化。

微服務的大小和服務之間的交互方式構成了基本的微服務體系結構，分別代表了微服務高內聚、低耦合的基本特性。在本書后續章節中，我們會集中討論服務的邊界劃分原則和方法、服務管理的要求和實踐以及微服務之間集成的各種技術體系。

微服務是一種服務體系，關于如何構建這種服務體系，在設計和實現上需要特定的方法論，而微服務架構就是用來構建微服務的架構模式，為我們提供了具體的方法論以及相關的工程實踐。

1.2.2 微服務架構基礎

微服務架構是一種架構模式，區別于其他系統架構的構建方式和技術方案，微服務架構具有其固有特點，這些特點也為我們在使用微服務架構進行系統設計的過程提供了主要的切入點。

1.微服務架構特點

馬丁·福勒（Martin Fowler）指出[1]，微服務架構具有以下特點。

（1）服務組件化

組件（Component）是一種可獨立替換和升級的軟件單元。在我們日常開發過程中可能會設計和使用很多組件。這些組件可能服務于系統內部，也可能存在于系統所運行的進程之外。而服務就是一種進程外組件，服務之間利用諸如遠程過程調用（Remote Procedure Call， RPC）的通信機制完成交互。服務組件化的主要目的是服務可以獨立部署。如果你的應用程序是由很多組件組成，并且這些組件運行在同一個進程中，那么對任何一個組件的改變都將導致必須重新部署整個應用程序。但是，如果你把應用程序拆分成很多服務，顯然通常情況下，你只需要重新部署那個改變的服務。在微服務架構中，每個服務運行在其獨立的進程中，服務與服務之間采用輕量級通信機制互相溝通。

（2）按業務能力組織服務

當尋找把一個大的應用程序進行拆分的方法時，研發過程通常都會圍繞產品團隊、UED團隊、APP 前端團隊和服務器端團隊而展開。這些團隊也就是通常所說的職能團隊（Function Team）。當使用這種標準對團隊進行劃分時，任何一個需求變更，無論大小，都將導致跨團隊協作，從而增加溝通和協作成本。而微服務架構下的劃分方法有所不同，它傾向圍繞業務功能的組織來分割服務。這些服務面向具體業務結構，而不是面向某項技術能力。因此，團隊是跨職能的（Cross-Functional）的特征團隊（Feature Team），包含用戶體驗、項目管理和技術研發等開發過程所要求的所有技能。每個服務都圍繞著業務進行構建，并且能夠被獨立部署到生產/類生產環境。

（3）去中心化

服務集中治理的一種好處是在單一平臺上進行標準化，但采用微服務的團隊更喜歡不同的標準。把整體式框架中的組件拆分成不同的服務，我們在構建這些服務時就會有更多的選擇。對具體的一個服務而言，應該根據業務上下文，選擇合適的語言、工具進行構建。

另一方面，微服務架構也崇尚對數據進行分散管理。當整體式的應用使用單一邏輯數據庫進行數據持久化時，通常選擇在應用的范圍內使用一個數據庫。然后，微服務讓每個服務管理自己的數據庫，無論是相同數據庫的不同實例，或者是不同的數據庫系統。

（4）基礎設施自動化

許多使用微服務架構的產品或者系統，它們的團隊擁有豐富的持續集成（Continue Integration）和持續交付（Continuous Delivery）的經驗。團隊使用微服務架構構建軟件需要更廣泛的依賴基礎設施自動化技術。

微服務同樣需要考慮服務容錯性設計等分布式系統所需要考慮的問題，我們對以上特點進行總結和提煉，認為微服務具備業務獨立、進程隔離、團隊自主、技術無關輕量級通信和交付獨立性等“微”特性。

2.微服務架構設計的切入點

微服務架構設計的首要的切入點在于服務建模，盡可能明確領域的邊界。我們可以充分利用領域驅動設計（Domain Driven Design，DDD）方法，通過識別領域/子域中的模塊和服務、判斷這些模塊和服務是否獨立、考慮提升某些模塊和服務的層次并建立充血領域模型，從而明確各個界限上下文（Boundary Context）之間的邊界。

微服務架構設計第二個切入點就是服務之間的集成方式，即需要保證集成方式的技術無關性，不要選擇對服務具體實現有技術性限制的集成技術。采用技術無關的集成接口，充分融合技術多樣性，意味著我們在特定場景下不應該使用類似 Alibaba Dubbo（http://dubbo.io/）這種采用私有協議、重量級的通信框架，而應該盡可能使用類如RESTful的輕量級通信方式進行服務集成，確保服務易于使用，消費方可以使用多種技術實現集成。

微服務架構設計的第三個切入點在于服務的部署，獨立部署單個服務而不需要修改其他服務。同時，由于服務數量大，修改和發布的頻率也可能很高，接口變化管理上通常采用逐步遷移的方案。而在接口的發布上，常見的API網關（Gateway）等模式也會得到廣泛應用。

1.2.3 微服務架構與現有架構體系對比

微服務其實并不是憑空產生，而是有其歷史的淵源。在微服務概念被正式提出之前，我們經常會使用面向服務架構（Service Oriented Architecture，SOA）來構建分布式服務系統。SOA 只是提出了一種架構設計思想，但沒有給出標準的參考實現。而早期企業軟件開發上也摸索了一套實踐方式，即企業服務總線（Enterprise Service Bus，ESB）。本節通過與SOA和ESB這兩種架構模式的對比來更加深入地分析微服務架構。

1.微服務架構與SOA

在山姆·紐曼（Sam Newman）的《Building Microservices》[3]一書中，作者認為微服務架構是SOA的一種實踐方式，正如 XP（Extreme Programming，極限編程）或 Scrum 是敏捷軟件開發的實踐方式。在介紹兩者之間的區別和聯系之前，我們先來看一下SOA的特點。

SOA中，粗粒度的服務接口分級、松耦合的服務調用關系、標準化的服務接口、精確定義的服務契約、服務接口設計管理、支持各種消息模式等是服務的主要特征。SOA從分層上看，存在三個主要的邊界，在面向用戶的門戶（Portal）層與提供業務功能的服務層之間，還存在一個層次用于服務之間的集成（Integration）和編排（Orchestration）。顯然，各個服務通過集成和編排能夠組合成更為豐富的業務功能和體系，而集成和編排能夠實現的前提正是依賴于服務自身所具備的這些特征。圖1-7所示的是一種典型的基于SOA的服務交互方式。

在服務實現上，因為需要考慮到服務之間的集成和編排，采用SOA時需要引入一些復雜的技術體系。以在SOA中被廣泛使用的Web Service為例，復雜的交互協議使得采用SOA時需要付出巨大的代價。SOA 本身崇尚簡單和互操作性，但隨著事務、安全性等一系列擴展功能的出現，Web Service變成了一個龐大的WS-*協議棧，反而阻礙了服務之間的交互。

微服務架構與SOA無疑是有關聯的，兩者都是將業務系統拆分成各個服務并通過合適的技術完成服務的集成。微服務架構與SOA的最主要區別在于架構面向的目標。SOA通常面向的目標是企業級應用，通過 SOA 我們寄希望于將多個系統整合到一起，從而消除信息孤島。而微服務架構則更多地關注于一個獨立系統的架構，可以認為是傳統模塊化技術的一種替代方案。

微服務架構在服務之間同樣需要實現集成，但在集成方式上強調使用輕量級的通信技術，同時去除服務編排功能。一個微服務可以調用其他微服務并在服務內部實現編排操作。這樣編排操作作為微服務的內嵌功能不會暴露在集成層，從而降低服務之間的通信成本。另一方面，微服務之間的集成模式也與SOA中完全不同。由于微服務是面向業務、具備領域特性的獨立服務，我們可以在用戶操作層面直接進行服務集成。微服務之間的交互關系如圖 1-8 所示，我們可以看到微服務可以直接面向用戶，且微服務之間也可以直接進行交互，服務與服務之間沒有SOA中的集中式編排機制。

當然，并不是說，微服務架構不能使用統一的集成和編排機制。在需要對很多服務進行統一的權限管理、日志記錄、請求管理等場景時，我們也可以在這些微服務的訪問入口上添加統一的攔截。在微服務架構中，我們通常使用API網關（Gateway）實現攔截處理。關于API網關的討論我們將放在本書第4章。

由于SOA和微服務架構比較容易混淆，我們再從應用范圍、靈活性、組織性和部署等方面對兩者做一個對比總結。

（1）應用范圍

在應用范圍上，SOA是一種企業級的、面向大范圍和統一化的服務化架構，而微服務架構通常用于某一個項目或產品，并不強調大而全的服務集成需求。

（2）靈活性

SOA 通過服務編排機制實現靈活性，而微服務架構的靈活性則來自于快速的開發和部署以及服務之間的獨立性。

（3）組織性

通常，SOA 中的服務由不同組織中的職能團隊實現，而微服務則更強調跨職能團隊機制，同一項目或產品中具備各個職能的人員或團隊，共同實現微服務。

（4）部署

在SOA中，部分服務仍然以單塊系統的方式進行部署，而獨立進程部署是微服務架構的基本特征，所有的服務都能獨立部署。

2.微服務架構與ESB

消息總線（Message Bus）思想的理論基礎是消息驅動的編程方法和計算機硬件總線概念。系統組件之間通過總線來進行通信，可以支持組件的分布式存儲和并發運行。總線是系統的連接件，負責消息的分派、傳遞和過濾，并返回處理結果。總線思想在軟件設計過程中應用廣泛，并形成了一整套完整的企業服務總線（Enterprise Service Bus，ESB）技術體系。圖1-9展示了一種典型的服務總線應用場景。我們可以看到在ESB中，系統組件并不嚴格區分客戶端和服務器端，組件之間也不是通過消息通道進行直接交互，而是掛接在消息總線上，向總線登記自己所感興趣的消息類型。通過這種方式，圖1-9所示的企業級應用、遺留系統、核心業務服務以及其他第三方系統都可以通過總線串聯起來。同時，ESB 所提供的資源適配和轉換機制也能完成異構系統之間的無縫集成。

在消息總線中，消息是組件之間唯一的通信方式。根據需要，消息總線對消息具備豐富的預處理功能，包括消息路由（Routing）、消息轉換（Transformation）和消息過濾（Filtering）。這些預處理功能消除了數據傳遞在時間、空間和技術上的耦合，并提供了高度擴展性，但同時也為系統的設計和實現帶來了不可避免的復雜度。

微服務架構對于ESB的改變在于強化端點（Endpoint）及弱化通道，拋棄了ESB過度復雜的業務規則編排、消息路由等功能，并引入了啞管道（Dumb Pipe）的設計理念。這里的終端是指服務本身，而啞管道是通信機制。在微服務架構中，服務作為智能端點（Smart Endpoint），所有的業務邏輯在服務內部處理，而服務間的通信盡可能的輕量化，可以是同步的遠程過程調用（RPC），也可以是異步的消息傳遞系統，它們只作為消息通道，在傳輸過程中不會附加額外的業務規則。從這點上講，微服務架構表現得更像管道-過濾器（Pipe-Filter）模式中的過濾器一樣，接受請求、處理業務邏輯并返回響應。