之前介紹了什麼時候進行服務化，以及服務化拆分的兩種方式即橫向拆分和縱向拆分，還提到了引入微服務架構需要解決的問題。 這篇文章將進行介紹微服務架構的各個組成部分。 下圖是微服務架構的模塊圖，在具體介紹之前先來看下一次正常的服務調用的流程。 首先服務提供者（就是提供服務的一方）按照一定格式的服務描述，向 ...
之前介紹了什麼時候進行服務化，以及服務化拆分的兩種方式即橫向拆分和縱向拆分，還提到了引入微服務架構需要解決的問題。
這篇文章將進行介紹微服務架構的各個組成部分。
下圖是微服務架構的模塊圖，在具體介紹之前先來看下一次正常的服務調用的流程。
首先服務提供者（就是提供服務的一方）按照一定格式的服務描述，向註冊中心註冊服務，聲明自己能夠提供哪些服務以及服務的地址是什麼，完成服務發佈。
接下來服務消費者（就是調用服務的一方）請求註冊中心，查詢所需要調用服務的地址，然後以約定的通信協議向服務提供者發起請求，得到請求結果後再按照約定的協議解析結果。
而且在服務的調用過程中，服務的請求耗時、調用量以及成功率等指標都會被記錄下來用作監控，調用經過的鏈路信息會被記錄下來，用於故障定位和問題追蹤。在這期間，如果調用失敗，可以通過重試等服務治理手段來保證成功率。
總結一下，微服務架構下，服務調用主要依賴下麵幾個基本組件：
- 服務描述：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 配置方式的服務描述主要分三個步驟：
- 服務提供者定義介面，並實現介面
- 服務提供者進程啟動時，通過載入 server.xml 配置文件將介面暴露出去。
- 服務消費者進程啟動時，通過載入 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 故障引起的大批量業務受影響。
- 依賴服務不可用：服務治理可以通過熔斷，在依賴服務異常的情況下，一段時期內停止發起調用而直接返回。既保證了服務消費者能夠不被拖垮，也給服務提供者減少壓力，使其能夠儘快恢復。
還有其他服務治理的手段比如自動擴縮容、負載均衡、服務路由以及服務容錯等。
總結
主要對微服務架構中的組件進行了介紹，微服務架構主要由服務描述、註冊中心、服務框架、服務監控、服務追蹤以及服務治理等組成。
參考
