初探微服務架構

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

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

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

首先服務提供者（就是提供服務的一方）按照必定格式的服務描述，向註冊中心註冊服務，聲明本身可以提供哪些服務以及服務的地址是什麼，完成服務發佈。

接下來服務消費者（就是調用服務的一方）請求註冊中心，查詢所須要調用服務的地址，而後以約定的通訊協議向服務提供者發起請求，獲得請求結果後再按照約定的協議解析結果。

並且在服務的調用過程當中，服務的請求耗時、調用量以及成功率等指標都會被記錄下來用做監控，調用通過的鏈路信息會被記錄下來，用於故障定位和問題追蹤。在這期間，若是調用失敗，能夠經過重試等服務治理手段來保證成功率。

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

• 服務描述：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 故障引發的大批量業務受影響。
• 依賴服務不可用：服務治理能夠經過熔斷，在依賴服務異常的狀況下，一段時期內中止發起調用而直接返回。既保證了服務消費者可以不被拖垮，也給服務提供者減小壓力，使其可以儘快恢復。

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

總結

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

參考

https://dwz.cn/FscvpObJ

https://dwz.cn/3PTGdySt