如何釋出和引用服務
服務提供者如何釋出一個服務，服務消費者如何引用這個服務。具體來說，就是這個服務的介面名是什麼？呼叫這個服務需要傳遞哪些引數？介面的返回值是什麼型別？以及一些其他介面描述資訊
最常見的服務釋出和引用的方式有三種：
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協議建立網路連線最常用的途徑有兩種
- HTTP通訊
- Socket通訊
服務端如何處理請求
- 同步阻塞方式 (適用於連線數比較小的業務場景)
- 同步非阻塞方式 (用於連線數比較多並且請求消耗比較輕的業務場景，比如聊天伺服器)
- 非同步非阻塞方式 (用於連線數比較多而且請求消耗比較重的業務場景)
資料傳輸採用什麼協議
最常用的有HTTP協議，它是一種開放的協議，各大網站的伺服器和瀏覽器之間的資料傳輸大都採用了這種協議。還有一些定製的私有協議，比如阿里巴巴開源的Dubbo協議等。
資料該如何序列化和反序列化
常用的序列化方式分為兩類：
- 文字類如XML/JSON等
- 二進位制類如PB/Thrift等
如何監控微服務呼叫
監控物件
- 使用者端監控。提供給使用者的功能監控
- 介面監控。依賴的具體RPC介面的監控
- 資源監控。依賴的redis,mysql等
- 基礎監控。伺服器本身的健康狀況的監控
監控指標
- 請求量，請求量一般有二個維度，一個是實時請求量即QPS,還一個是統計請求量即PV。
- 響應時間，可以用一段時間內所有呼叫的平均耗時來反映請求的響應時間
- 錯誤率，通常用一段時間內呼叫失敗的次數佔呼叫總次數的比率來衡量
監控維度
- 全域性維度
- 分機房維度
- 單機維度
- 時間維度
- 核心維度
監控系統的步驟
1.資料採集
通常有兩種資料收集方式：
- 服務主動上報，這種處理方式透過在業務程式碼或者服務框架里加入資料收集程式碼邏輯，在每一次服務呼叫完成後，主動上報服務的呼叫資訊。
- 代理收集，這種處理方式透過服務呼叫後把呼叫的詳細資訊記錄到本地日誌檔案中，然後再透過代理去解析本地日誌檔案，然後再上報服務的呼叫資訊。
2. 資料傳輸
資料傳輸最常用的方式有兩種：
- UDP傳輸，這種處理方式是資料處理單元提供伺服器的請求地址，資料採集後透過UDP協議與伺服器建立連線，然後把資料傳送過去。
- Kafka傳輸，這種處理方式是資料採集後傳送到指定的Topic，然後資料處理單元再訂閱對應的Topic，就可以從Kafka訊息佇列中讀取到對應的資料。
3. 資料處理
資料處理是對收集來的原始資料進行聚合並儲存。資料聚合通常有兩個維度：
- 介面維度聚合，這個維度是把實時收到的資料按照介面名維度實時聚合在一起，這樣就可以得到每個介面的實時請求量、平均耗時等資訊。
- 機器維度聚合，這個維度是把實時收到的資料按照呼叫的節點維度聚合在一起，這樣就可以從單機維度去檢視每個介面的實時請求量、平均耗時等資訊。
4. 資料展示
資料展示是把處理後的資料以Dashboard的方式展示給使用者。資料展示有多種方式，比如曲線圖、餅狀圖、格子圖展示等。
如何追蹤微服務呼叫
在微服務架構下，由於進行了服務拆分，一次請求涉及到多個服務呼叫，如果請求失敗，就很難定位是在哪個環節出錯，所以我們需要服務呼叫鏈的追蹤。
服務追蹤的作用
- 最佳化系統瓶頸
- 最佳化鏈路呼叫
- 生成網路拓撲
- 透明傳輸資料
服務追蹤系統原理
它的核心理念就是呼叫鏈：透過一個全域性唯一的ID將分佈在各個服務節點上的同一次請求串聯起來，從而還原原有的呼叫關係，可以追蹤系統問題、分析呼叫資料並統計各種系統指標。
服務追蹤系統可以分為三層
- 資料採集層，負責各個節點資料埋點並上報資料處理層。
- 資料處理層，負責資料的儲存與計算。
- 資料展示層，負責資料的圖形化展示。
微服務治理的手段有哪些
一次服務呼叫，服務提供者、註冊中心、網路這三者都可能會有問題，此時服務消費者應該如何處理才能確保呼叫成功呢？這就是服務治理要解決的問題。
常用的服務治理手段
節點管理
服務呼叫失敗一般是由兩類原因引起的，一類是服務提供者自身出現問題，如伺服器當機、程式意外退出等；一類是網路問題，如服務提供者、註冊中心、服務消費者這三者任意兩者之間的網路出現問題。
無論是服務提供者自身出現問題還是網路發生問題，都有兩種節點管理手段。
- 註冊中心主動摘除機制
這種機制要求服務提供者定時的主動向註冊中心彙報心跳，註冊中心根據服務提供者節點最近一次彙報心跳的時間與上一次彙報心跳時間做比較，如果超出一定時間，就認為服務提供者出現問題，繼而把節點從服務列表中摘除，並把最近的可用服務節點列表推送給服務消費者。
- 服務消費者摘除機制
雖然註冊中心主動摘除機制可以解決服務提供者節點異常的問題，但如果是因為註冊中心與服務提供者之間的網路出現異常，最壞的情況是註冊中心會把服務節點全部摘除，導致服務消費者沒有可用的服務節點呼叫，但其實這時候服務提供者本身是正常的。所以，將存活探測機制用在服務消費者這一端更合理，如果服務消費者呼叫服務提供者節點失敗，就將這個節點從記憶體中儲存的可用服務提供者節點列表中移除。
負載均衡
常用的負載均衡演算法主要包括以下幾種。
- 隨機演算法
- 輪訓演算法
- 最少活躍呼叫演算法
- 一致性Hash演算法
服務路由
對於服務消費者而言，在記憶體中的可用服務節點列表中選擇哪個節點不僅由負載均衡演算法決定，還由路由規則確定。所謂的路由規則，就是透過一定的規則如條件表示式或者正規表示式來限定服務節點的選擇範圍。
為什麼要制定路由規則呢？主要有兩個原因。
- 業務存在灰度釋出的需求
- 多機房就近訪問的需求
服務容錯
服務呼叫並不總是一定成功的,對於服務呼叫失敗的情況，需要有手段自動恢復，來保證呼叫成功。
服務容錯常用的手段主要有以下幾種。
- FailOver：失敗自動切換。就是服務消費者發現呼叫失敗或者超時後，自動從可用的服務節點列表總選擇下一個節點重新發起呼叫，也可以設定重試的次數。
- FailBack：失敗通知。就是服務消費者呼叫失敗或者超時後，不再重試，而是根據失敗的詳細資訊，來決定後續的執行策略。
- FailCache：失敗快取。就是服務消費者呼叫失敗或者超時後，不立即發起重試，而是隔一段時間後再次嘗試發起呼叫。
- FailFast：快速失敗。就是服務消費者呼叫一次失敗後，不再重試。
一般情況下對於冪等的呼叫，可以選擇FailOver或者FailCache，非冪等的呼叫可以選擇FailBack或者FailFast。
參考資料
極客專欄:從0開始學微服務
本文亦在微信公眾號【小道資訊】釋出，歡迎掃碼關注！
本作品採用《CC 協議》，轉載必須註明作者和本文連結