2020.11.01 Spring Cloud 原理
Spring Cloud 原理
概述
本文先從其最核心的幾個元件入手，來剖析一下其底層工作原理。也就是Eureka\Ribbon\Feign\Hystrix\Zuul這幾個元件
業務場景介紹
先來一個業務場景，假設開發一個電商網站，要實現支付訂單的功能，流程如下：
-
建立一個訂單之後，如果使用者立刻支付了這個訂單，我們需要將訂單狀態更新為"已支付"
-
扣減相應的商品庫存
-
通知倉儲中心，進行發貨
-
給使用者的這次購物增加相應的積分
針對上述流程，我們需要有訂單服務、庫存服務、倉儲服務、積分服務.整個流程的答題思路如下：
- 使用者針對一個訂單完成支付之後，就回去找訂單服務，更新訂單狀態
- 訂單服務呼叫庫存服務，完成相應功能
- 訂單服務呼叫倉儲服務，完成相應功能
- 訂單服務呼叫積分服務，完成相應功能
至此，整個支付訂單的業務流程結束
各服務間的呼叫過程圖：
對Spring Cloud 的主要元件做一下總結
Netflix Eureka
-
Eureka 服務端：也稱服務註冊中心，同其他服務註冊中心一樣，支援高可用配置。如果Eureka 以叢集模式部署，當叢集中有分片出現故障時，那麼Eureka 就轉入自我保護模式。它允許在分片故障期間繼續提供服務的發現和註冊，當故障分片恢復執行時，叢集中其他分片會把它們的狀態再次同步回來
-
Eureka客戶端：主要處理服務的註冊與發現。客戶端服務通過註解和引數配置的方式，嵌入在客戶端應用程式的程式碼中，在應用程式執行時，Eureka客戶端想註冊中心註冊自身提供的服務並週期性傳送心跳來更新它的服務租約。同時，它也能從服務端查詢當前註冊的服務資訊並把它們快取到本地並週期性地重新整理服務狀態
-
Eureka Server 的高可用實際上就是將自己作為服務向其他註冊中心註冊自己，這樣就可以形成一組互相註冊的服務註冊中心，以實現服務清單的互相同步，達到高可用效果
Eureka 詳解
服務提供者
- 服務註冊
服務提供者在啟動的時候會通過REST 請求的方式將自己註冊到Eureka Server上,同時帶上了自己的服務的一些元資料資訊。Eureka Server接收到這個REST請求之後,將元資料資訊儲存在一個雙層結構Map 中,其中第一層的key是服務名,第二層的key是具體服務的例項名
- 服務同步
兩個服務提供者分別註冊到了兩個不同的服務註冊中心上,也就是說，它們的資訊分別被兩個服務註冊中心所維護。此時,由於服務註冊中心之間因互相註冊為服務,當服務提供者傳送註冊請求到一個服務註冊中心時,它會將該請求轉發給叢集中相連的其他註冊中心,從而實現註冊中心之間的服務同步。通過服務同步,兩個服務提供者的服務資訊就可以通過這兩臺服務註冊中心中的任意一臺獲取到
- 服務續約
在註冊完服務之後,服務提供者會維護一個心跳用來維持告訴Eureka Server：我還活著,以防止Eureka Server 的提出任務將該服務例項從服務列表中排除出去,我們稱該操作為服務續約
程式碼體現
# 定義服務續約任務的呼叫間隔時間 預設30秒
eureka.instance.lease-renewak-interval-in-seconds=30
# 定義服務失效的時間，預設90秒
eureka.instance.lease-expiration-duration-in-seconds=90
服務消費者
- 獲取服務
當我們啟動服務消費者的時候,它會發送一個REST請求給服務註冊中心,來獲取上面註冊的服務清單。為了效能考慮,Eureka Server 會維護一份只讀的服務來返回給客戶端,同時該快取清單會每隔30秒更新一次
程式碼實現
# 快取清單的更新時間，預設30秒
eureka.client.registry-fetch-interval-seconds=30
- 服務呼叫
服務消費者在獲取服務清單後，通過服務名可以獲得具體提供服務的例項名和該例項名的元資料資訊。在Ribbon中會預設採用輪詢的方式進行呼叫，從而實現客戶端的負載均衡
對於訪問例項的選擇，Eureka中有Region和Zone的概念，一個Region中可以包含多個Zone，每個服務客戶端需要被註冊到一個Zone中，所以每個客戶端對應一個Region和一個Zone。在進行服務呼叫的時候，優先訪問同處一個一個Zone中的服務提供方，若訪問不到，就訪問其他的Zone
- 服務下線
當服務例項進行正常的關閉操作時,他會觸發一個服務下線的REST請求給Eureka Server,告訴服務註冊中心：“我要下線了”。服務端在接收到請求之後,將該服務狀態置為下線(DOWN),並把該下線事件傳播出去