初探微服務架構

之前介紹了什麼時候進行服務化，以及服務化拆分的兩種方式即橫向拆分和縱向拆分，還提到了引入微服務架構需要解決的問題。

這篇文章将進行介紹微服務架構的各個組成部分。

下圖是微服務架構的子產品圖，在具體介紹之前先來看下一次正常的服務調用的流程。

首先服務提供者（就是提供服務的一方）按照一定格式的服務描述，向注冊中心注冊服務，聲明自己能夠提供哪些服務以及服務的位址是什麼，完成服務釋出。

接下來服務消費者（就是調用服務的一方）請求注冊中心，查詢所需要調用服務的位址，然後以約定的通信協定向服務提供者發起請求，得到請求結果後再按照約定的協定解析結果。

而且在服務的調用過程中，服務的請求耗時、調用量以及成功率等名額都會被記錄下來用作監控，調用經過的鍊路資訊會被記錄下來，用于故障定位和問題追蹤。在這期間，如果調用失敗，可以通過重試等服務治理手段來保證成功率。

總結一下，微服務架構下，服務調用主要依賴下面幾個基本元件：

• 服務描述：RESTful API （HTTP）、XML 配置（RPC）、IDL 檔案（gRPC/Thrift）
• 注冊中心：注冊（服務提供者->注冊中心）、訂閱（服務消費者->注冊中心）、傳回（注冊中心->服務消費者）、通知（注冊中心->服務消費者）
• 服務架構：通信架構、通信協定、序列化和反序列化
• 服務監控（發現問題）：名額收集、資料處理、資料展現
• 服務追蹤（定位問題）：RequestId傳遞
• 服務治理（解決問題）：單機故障-自動摘除、單IDC故障-自動切換、依賴服務不可用-熔斷

接下來進行介紹這些元件。

服務描述

服務調用首先解決的問題就是服務如何對外描述。服務描述主要解決對外服務的服務名是什麼，調用需要提供哪些資訊，傳回格式是什麼以及如何進行解析。

常用的服務描述方式包括 RESTful API、XML 配置以及 IDL 檔案三種。

RESTful API 方式通常用于 HTTP 協定的服務描述。RESTful API 方式的服務描述如下：

GET /sysDictoryDict/mapByUserId/{userId}
POST /enterprise/enterpriseDetail/top
PUT /enterprise/{enterpriseId}
DELETE /enterprise/{enterpriseId}           

XML 配置方式多用作 RPC 協定的服務描述，通過 *.xml 配置檔案來定義接口名、參數以及傳回值類型等。XML 配置方式的服務描述主要分三個步驟：

1. 服務提供者定義接口，并實作接口
2. 服務提供者程序啟動時，通過加載 server.xml 配置檔案将接口暴露出去。
3. 服務消費者程序啟動時，通過加載 client.xml 配置檔案引入要調用的接口。

IDL 檔案方式通常用作 Thrift 和 gRPC 這類跨語言服務調用架構中，比如 gRPC 就是通過 Protobuf 檔案來定義服務的接口名、參數以及傳回值的資料結構。

服務描述方式比較

服務描述方式	使用場景	缺點
RESTful API	跨語言平台，組織内外都适用	相比 TCP，HTTP 作為通信協定性能較差
XML 配置	Java 平台，一般用于組織内部	不支援跨語言平台
IDL 檔案		修改/删除 PB 字段不能向前相容

注冊中心

接下來要解決的問題就是服務的釋出和訂閱，也就是說你提供一個服務，如何讓外部想調用這個服務的人知道。就需要注冊中心出場了，服務提供者将自己提供的服務以及位址登記到注冊中心，服務消費者則從注冊中心查詢所需要調用的服務的位址，然後發起請求。

在整個微服務架構中，注冊中心是最基礎的核心服務之一，它記錄着服務和服務位址的映射關系，為服務提供方提供注冊、登出功能，為服務消費方提供服務發現的功能。

注冊中心一般的工作流程是：

• 服務提供者在啟動時，根據服務釋出檔案中配置的釋出資訊向注冊中心注冊自己的服務。
• 服務消費者在啟動時，根據消費者配置檔案中配置的服務資訊向注冊中心訂閱自己所需要的服務。
• 注冊中心傳回服務提供者位址清單給服務消費者。
• 當服務提供者發生變化，比如有節點新增或者銷毀，注冊中心将變更通知給服務消費者。

常見的注冊中心有 Netflix 的 Eureka、HashiCorp 的 Consul、雅虎的 Zookeeper、阿裡的 Nacos 等。

服務架構

通過注冊中心，服務消費者就可以擷取到服務提供者的位址，有了位址後就可以發起調用。但在發起調用之前你還需要解決以下幾個問題。

• 服務通信采用什麼協定？就是說服務提供者和服務消費者之間以什麼樣的協定進行網絡通信，是采用四層 TCP、UDP 協定，還是采用七層 HTTP 協定，還是采用其他協定？
• 資料傳輸采用什麼方式？就是說服務提供者和服務消費者之間的資料傳輸采用哪種方式，是同步還是異步，是在單連接配接上傳輸，還是多路複用。
• 資料壓縮采用什麼格式？通常資料傳輸都會對資料進行壓縮，來減少網絡傳輸的資料量，進而減少帶寬消耗和網絡傳輸時間，比如常見的 JSON 序列化、Java 對象序列化以及 Protobuf 序列化等。

這三部分就組成了一個完成的 RPC 調用架構，通信架構提供了基礎的通信能力，通信協定描述了通信契約，而序列化和反序列化則用于資料的編/解碼。一個通信架構可以适配多種通信協定，也可以采用多種序列化和反序列化的格式。

• 通信架構：解決用戶端和服務端如何建立連接配接、管理連接配接以及服務端如何處理請求的問題。
• 通信協定：解決用戶端和服務端采用哪些資料傳輸協定的問題。
• 序列化和反序列化：解決用戶端和服務端采用哪種資料編碼的問題。

服務監控

可以正常發起服務調用後，就需要對調用情況進行監控，以了解服務是否正常。通常來講，服務監控主要包括三個流程。

• 名額收集：把每一次服務調用的請求耗時以及成功與否收集起來，并上傳到集中的資料進行中心。
• 資料處理：根據每次調用的請求耗時以及成功與否等資訊，就可以計算每秒服務請求量、平均耗時以及成功率等名額。
• 資料展示：通常都是将資料展示在 Dashboard 面闆上，并且每隔 10s 等間隔自動重新整理，用作業務監控和報警等。

服務追蹤

記錄服務調用經過的每一層鍊路，以便進行問題追蹤和故障定位。

服務追蹤的工作原理大緻如下：

• 服務消費者發起調用前，會在本地按照一定的規則生成一個 requestid，發起調用時，将 requestid 當作請求參數的一部分，傳遞給服務提供者。
• 服務提供者接收到請求後，記錄下這次請求的 requestid，然後處理請求。如果服務提供者繼續請求其他服務，會在本地再生成一個自己的 requestid，然後把這兩個 requestid 都當作請求參數繼續往下傳遞。

以此類推，通過這種層層往下傳遞的方式，一次請求，無論最後依賴多少次服務調用、經過多少服務節點，都可以通過最開始生成的 requestid 串聯所有節點，進而達到服務追蹤的目的。

常用的服務追蹤有 Twitter 的 Zipkin、華為的 skywalking、Uber 的 jaeger、大衆點評的 CAT等。

服務治理

服務治理就是保證在各種意外情況下，服務調用仍然能夠正常進行。

在生産環境中，經常會遇到下面幾種情況：

• 單機故障：服務治理可以通過一定的政策，自動摘除故障節點，就能保證單機故障不會影響業務。
• 單 IDC 故障：服務治理可以通過自動切換故障 IDC 的流量到其他正常 IDC，可以避免因為單 IDC 故障引起的大批量業務受影響。
• 依賴服務不可用：服務治理可以通過熔斷，在依賴服務異常的情況下，一段時期内停止發起調用而直接傳回。既保證了服務消費者能夠不被拖垮，也給服務提供者減少壓力，使其能夠盡快恢複。

還有其他服務治理的手段比如自動擴縮容、負載均衡、服務路由以及服務容錯等。

總結

主要對微服務架構中的元件進行了介紹，微服務架構主要由服務描述、注冊中心、服務架構、服務監控、服務追蹤以及服務治理等組成。