我想你一定很好奇微服務架構到底是什麼樣子的，接下來我們一起走進微服務架構，來看看它的各個組成部分。

下面這張圖是我根據自己的經驗，繪製的微服務架構的模塊圖，在具體介紹之前先來看下一次正常的服務調用的流程。

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

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

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

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

1. 服務描述
2. 註冊中心
3. 服務框架
4. 服務監控
5. 服務追蹤
6. 服務治理

接下來，我來為你一一介紹這些組件。

服務描述

服務調用首先要解決的問題就是服務如何對外描述。比如，你對外提供了一個服務，那麼這個服務的服務名叫什麼？調用這個服務需要提供哪些信息？調用這個服務返回的結果是什麼格式的？該如何解析？這些就是服務描述要解決的問題。

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

其中，RESTful API 方式通常用於 HTTP 協議的服務描述，並且常用 Wiki 或者Swagger來進行管理。下面是一個 RESTful API 方式的服務描述的例子。

XML 配置方式多用作 RPC 協議的服務描述，通過 *.xml 配置文件來定義接口名、參數以及返回值類型等。下面是一個 XML 配置方式的服務描述的例子。

IDL 文件方式通常用作 Thrift 和 gRPC 這類跨語言服務調用框架中，比如 gRPC 就是通過 Protobuf 文件來定義服務的接口名、參數以及返回值的數據結構，示例如下：

註冊中心

有了服務的接口描述，下一步要解決的問題就是服務的發佈和訂閱，就是說你提供了一個服務，如何讓外部想調用你的服務的人知道。這個時候就需要一個類似註冊中心的角色，服務提供者將自己提供的服務以及地址登記到註冊中心，服務消費者則從註冊中心查詢所需要調用的服務的地址，然後發起請求。

一般來講，註冊中心的工作流程是：

• 服務提供者在啟動時，根據服務發佈文件中配置的發佈信息向註冊中心註冊自己的服務。
• 服務消費者在啟動時，根據消費者配置文件中配置的服務信息向註冊中心訂閱自己所需要的服務。
• 註冊中心返回服務提供者地址列表給服務消費者。
• 當服務提供者發生變化，比如有節點新增或者銷燬，註冊中心將變更通知給服務消費者。

服務框架

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

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

服務監控

一旦服務消費者與服務提供者之間能夠正常發起服務調用，你就需要對調用情況進行監控，以瞭解服務是否正常。通常來講，服務監控主要包括三個流程。

• 指標收集。就是要把每一次服務調用的請求耗時以及成功與否收集起來，並上傳到集中的數據處理中心。
• 數據處理。有了每次調用的請求耗時以及成功與否等信息，就可以計算每秒服務請求量、平均耗時以及成功率等指標。
• 數據展示。數據收集起來，經過處理之後，還需要以友好的方式對外展示，才能發揮價值。通常都是將數據展示在 Dashboard 面板上，並且每隔 10s 等間隔自動刷新，用作業務監控和報警等。

服務追蹤

除了需要對服務調用情況進行監控之外，你還需要記錄服務調用經過的每一層鏈路，以便進行問題追蹤和故障定位。

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

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

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

服務治理

服務監控能夠發現問題，服務追蹤能夠定位問題所在，而解決問題就得靠服務治理了。服務治理就是通過一系列的手段來保證在各種意外情況下，服務調用仍然能夠正常進行。

在生產環境中，你應該經常會遇到下面幾種狀況。

• 單機故障。通常遇到單機故障，都是靠運維發現並重啟服務或者從線上摘除故障節點。然而集群的規模越大，越是容易遇到單機故障，在機器規模超過一百臺以上時，靠傳統的人肉運維顯然難以應對。而服務治理可以通過一定的策略，自動摘除故障節點，不需要人為干預，就能保證單機故障不會影響業務。
• 單 IDC 故障。你應該經常聽說某某 App，因為施工挖斷光纜導致大批量用戶無法使用的嚴重故障。而服務治理可以通過自動切換故障 IDC 的流量到其他正常 IDC，可以避免因為單 IDC 故障引起的大批量業務受影響。
• 依賴服務不可用。比如你的服務依賴依賴了另一個服務，當另一個服務出現問題時，會拖慢甚至拖垮你的服務。而服務治理可以通過限流，在依賴服務異常的情況下，一段時期內停止發起調用而直接返回。這樣一方面保證了服務消費者能夠不被拖垮，另一方面也給服務提供者減少壓力，使其能夠儘快恢復。

上面是三種最常見的需要引入服務治理的場景，當然還有一些其他服務治理的手段比如自動擴縮容，可以用來解決服務的容量問題。

總結

通過前面的講解，相信你已經對微服務架構有了基本的認識，對微服務架構的基本組件也有了初步瞭解。

這幾個基本組件共同組成了微服務架構，在生產環境下缺一不可，所以在引入微服務架構之前，你的團隊必須掌握這些基本組件的原理並具備相應的開發能力。實現方式上，可以引入開源方案；如果有充足的資深技術人員，也可以選擇自行研發微服務架構的每個組件。但對於大部分中小團隊來說，我認為採用開源實現方案是一個更明智的選擇，一方面你可以節省相關技術人員的投入從而更專注於業務，另一方面也可以少走彎路少踩坑。不管你是採用開源方案還是自行研發，都必須吃透每個組件的工作原理並能在此基礎上進行二次開發。

專欄後面的內容，我會帶你對這幾個微服務架構的基本組件進行詳細剖析，讓你能知其然也知其所以然。

思考題

最後你可以思考一下，微服務架構下的基本組件所解決的問題，對應到單體應用時是否存在？如果存在，解決方案是否相同？

歡迎你在留言區寫下自己的思考，與我一起討論。

閱讀更多 架構師的修煉之路 的文章

關鍵字: 服務 數據結構 JSON