微服務的那些事

如何發佈和引用服務

服務提供者如何發佈一個服務，服務消費者如何引用這個服務。具體來講，就是這個服務的接口名是什麼？調用這個服務須要傳遞哪些參數？接口的返回值是什麼類型？以及一些其餘接口描述信息
最多見的服務發佈和引用的方式有三種：
RESTful API (通常對外)
XML配置 （對內）
IDL文件（跨語言，Thrift, gRPC）

如何註冊和發現服務

在微服務架構下，主要有三種角色：服務提供者（RPC Server）、服務消費者（RPC Client）和服務註冊中心（Registry）。

RPC Server提供服務，在啓動時，根據服務發佈文件server.xml中的配置的信息，向Registry註冊自身服務，並向Registry按期發送心跳彙報存活狀態。

RPC Client調用服務，在啓動時，根據服務引用文件client.xml中配置的信息，向Registry訂閱服務，把Registry返回的服務節點列表緩存在本地內存中，並與RPC Sever創建鏈接。

當RPC Server節點發生變動時，Registry會同步變動，RPC Client感知後會刷新本地內存中緩存的服務節點列表。

RPC Client從本地緩存的服務節點列表中，基於負載均衡算法選擇一臺RPC Sever發起調用。

註冊中心實現方式

註冊中心的實現主要涉及幾個問題：註冊中心須要提供哪些接口，該如何部署；如何存儲服務信息；如何監控服務提供者節點的存活；若是服務提供者節點有變化如何通知服務消費者，以及如何控制註冊中心的訪問權限。

註冊中心必須提供如下最基本的API

• 服務註冊接口：服務提供者經過調用服務註冊接口來完成服務註冊。
• 服務反註冊接口：服務提供者經過調用服務反註冊接口來完成服務註銷。
• 心跳彙報接口：服務提供者經過調用心跳彙報接口完成節點存活狀態上報。
• 服務訂閱接口：服務消費者經過調用服務訂閱接口完成服務訂閱，獲取可用的服務提供者節點列表。
• 服務變動查詢接口：服務消費者經過調用服務變動查詢接口，獲取最新的可用服務節點列表。

除此以外，爲了便於管理，註冊中心還必須提供一些後臺管理的API，例如：

• 服務查詢接口：查詢註冊中心當前註冊了哪些服務信息。
• 服務修改接口：修改註冊中心中某一服務的信息。

如何實現RPC遠程服務調用

在進行服務化拆分以後，服務提供者和服務消費者運行在兩臺不一樣物理機上的不一樣進程內，它們之間的調用相比於本地方法調用，可稱之爲遠程方法調用，簡稱RPC。

想要完成遠程調用，你須要解決四個問題：

• 客戶端和服務端如何創建網絡鏈接？
• 服務端如何處理請求？
• 數據傳輸採用什麼協議？
• 數據該如何序列化和反序列化？

客戶端和服務端如何創建網絡鏈接

客戶端和服務端之間基於TCP協議創建網絡鏈接最經常使用的途徑有兩種

1. HTTP通訊
2. Socket通訊

服務端如何處理請求

1. 同步阻塞方式 (適用於鏈接數比較小的業務場景)
2. 同步非阻塞方式 (用於鏈接數比較多而且請求消耗比較輕的業務場景，好比聊天服務器)
3. 異步非阻塞方式 (用於鏈接數比較多並且請求消耗比較重的業務場景)

數據傳輸採用什麼協議

最經常使用的有HTTP協議，它是一種開放的協議，各大網站的服務器和瀏覽器之間的數據傳輸大都採用了這種協議。還有一些定製的私有協議，好比阿里巴巴開源的Dubbo協議等。

數據該如何序列化和反序列化

經常使用的序列化方式分爲兩類：

• 文本類如XML/JSON等
• 二進制類如PB/Thrift等

如何監控微服務調用

監控對象

• 用戶端監控。提供給用戶的功能監控
• 接口監控。依賴的具體RPC接口的監控
• 資源監控。依賴的redis,mysql等
• 基礎監控。服務器自己的健康情況的監控

監控指標

• 請求量，請求量通常有二個維度，一個是實時請求量即QPS,還一個是統計請求量即PV。
• 響應時間，能夠用一段時間內全部調用的平均耗時來反映請求的響應時間
• 錯誤率，一般用一段時間內調用失敗的次數佔調用總次數的比率來衡量

監控維度

• 全局維度
• 分機房維度
• 單機維度
• 時間維度
• 核心維度

監控系統的步驟

1.數據採集

一般有兩種數據收集方式：

• 服務主動上報，這種處理方式經過在業務代碼或者服務框架里加入數據收集代碼邏輯，在每一次服務調用完成後，主動上報服務的調用信息。
• 代理收集，這種處理方式經過服務調用後把調用的詳細信息記錄到本地日誌文件中，而後再經過代理去解析本地日誌文件，而後再上報服務的調用信息。

2. 數據傳輸

數據傳輸最經常使用的方式有兩種：

• UDP傳輸，這種處理方式是數據處理單元提供服務器的請求地址，數據採集後經過UDP協議與服務器創建鏈接，而後把數據發送過去。
• Kafka傳輸，這種處理方式是數據採集後發送到指定的Topic，而後數據處理單元再訂閱對應的Topic，就能夠從Kafka消息隊列中讀取到對應的數據。

3. 數據處理

數據處理是對收集來的原始數據進行聚合並存儲。數據聚合一般有兩個維度：

• 接口維度聚合，這個維度是把實時收到的數據按照接口名維度實時聚合在一塊兒，這樣就能夠獲得每一個接口的實時請求量、平均耗時等信息。
• 機器維度聚合，這個維度是把實時收到的數據按照調用的節點維度聚合在一塊兒，這樣就能夠從單機維度去查看每一個接口的實時請求量、平均耗時等信息。

4. 數據展現

數據展現是把處理後的數據以Dashboard的方式展現給用戶。數據展現有多種方式，好比曲線圖、餅狀圖、格子圖展現等。

如何追蹤微服務調用

在微服務架構下，因爲進行了服務拆分，一次請求涉及到多個服務調用，若是請求失敗，就很難定位是在哪一個環節出錯，因此咱們須要服務調用鏈的追蹤。

服務追蹤的做用

• 優化系統瓶頸
• 優化鏈路調用
• 生成網絡拓撲
• 透明傳輸數據

服務追蹤系統原理

它的核心理念就是調用鏈：經過一個全局惟一的ID將分佈在各個服務節點上的同一次請求串聯起來，從而還原原有的調用關係，能夠追蹤系統問題、分析調用數據並統計各類系統指標。

服務追蹤系統能夠分爲三層

• 數據採集層，負責各個節點數據埋點並上報數據處理層。
• 數據處理層，負責數據的存儲與計算。
• 數據展現層，負責數據的圖形化展現。

微服務治理的手段有哪些

一次服務調用，服務提供者、註冊中心、網絡這三者均可能會有問題，此時服務消費者應該如何處理才能確保調用成功呢？這就是服務治理要解決的問題。

經常使用的服務治理手段

節點管理

服務調用失敗通常是由兩類緣由引發的，一類是服務提供者自身出現問題，如服務器宕機、進程意外退出等；一類是網絡問題，如服務提供者、註冊中心、服務消費者這三者任意二者之間的網絡出現問題。

不管是服務提供者自身出現問題仍是網絡發生問題，都有兩種節點管理手段。

1. 註冊中心主動摘除機制

這種機制要求服務提供者定時的主動向註冊中心彙報心跳，註冊中心根據服務提供者節點最近一次彙報心跳的時間與上一次彙報心跳時間作比較，若是超出必定時間，就認爲服務提供者出現問題，繼而把節點從服務列表中摘除，並把最近的可用服務節點列表推送給服務消費者。

1. 服務消費者摘除機制

雖然註冊中心主動摘除機制能夠解決服務提供者節點異常的問題，但若是是由於註冊中心與服務提供者之間的網絡出現異常，最壞的狀況是註冊中心會把服務節點所有摘除，致使服務消費者沒有可用的服務節點調用，但其實這時候服務提供者自己是正常的。因此，將存活探測機制用在服務消費者這一端更合理，若是服務消費者調用服務提供者節點失敗，就將這個節點從內存中保存的可用服務提供者節點列表中移除。

負載均衡

經常使用的負載均衡算法主要包括如下幾種。

• 隨機算法
• 輪訓算法
• 最少活躍調用算法
• 一致性Hash算法

服務路由

對於服務消費者而言，在內存中的可用服務節點列表中選擇哪一個節點不只由負載均衡算法決定，還由路由規則肯定。所謂的路由規則，就是經過必定的規則如條件表達式或者正則表達式來限定服務節點的選擇範圍。

爲何要制定路由規則呢？主要有兩個緣由。

• 業務存在灰度發佈的需求
• 多機房就近訪問的需求

服務容錯

服務調用並不老是必定成功的,對於服務調用失敗的狀況，須要有手段自動恢復，來保證調用成功。
服務容錯經常使用的手段主要有如下幾種。

• FailOver：失敗自動切換。就是服務消費者發現調用失敗或者超時後，自動從可用的服務節點列表總選擇下一個節點從新發起調用，也能夠設置重試的次數。
• FailBack：失敗通知。就是服務消費者調用失敗或者超時後，再也不重試，而是根據失敗的詳細信息，來決定後續的執行策略。
• FailCache：失敗緩存。就是服務消費者調用失敗或者超時後，不當即發起重試，而是隔一段時間後再次嘗試發起調用。
• FailFast：快速失敗。就是服務消費者調用一次失敗後，再也不重試。

通常狀況下對於冪等的調用，能夠選擇FailOver或者FailCache，非冪等的調用能夠選擇FailBack或者FailFast。

參考資料
極客專欄:從0開始學微服務

本文亦在微信公衆號【小道資訊】發佈，歡迎掃碼關注！