1 Spring Cloud Eureka服務治理(下)


注:此隨筆為讀書筆記。《Spring Cloud微服務實戰》,想學習Spring Cloud的同伴們可以去看看此書,里面對源碼有詳細的解讀。

  上篇主要介紹了什么是微服務以及微服務治理的簡單實現,如微服務注冊中心的實現、微服務注冊的實現、微服務的發現和消費的實現、微服務注冊高可用的實現。本篇主要介紹一下微服務治理機制。服務治理基礎架構有是三個核心要素:服務注冊中心、服務提供者、服務消費者,服務提供者一般執行服務注冊、服務同步、服務續約任務,服務消費者會執行獲取服務、服務調用、服務下線任務,服務注冊中心會執行失效剔除、自我保護任務。下面一一理解。

場景:

  有兩個服務注冊中心,互相注冊組成高可用集群;

  服務提供者啟動兩個實例,一個注冊在注冊中心1中,一個注冊在注冊中心2中;(疑問:這里我試了,服務只指向一個注冊中心,只啟動一個實例,兩個注冊中心都會有剛啟動的服務,這應該也算服務同步吧)

  有兩個服務消費者,一個指向注冊中心1中,一個指向注冊中心2中。

1.服務提供者

1.服務注冊

  服務提供者在啟動的時候會發送REST請求將自己注冊到注冊中心,同時帶上了自身服務的一些元數據信息。注冊中心接收到請求后,將元數據信息存儲在一個雙層結構Map中,其中第一層的Key是服務名,第二層的Key是具體服務的實例名。如Ribbon負載均衡的例子中,一個服務有多個實例的情況。

2.服務同步

  由於服務注冊中心之間互相注冊為服務,當服務提供者發送注冊請求到其中一個注冊中心時,它會將請求轉發給集群中相連的其他注冊中心,此時集群中所有的注冊中心都會注冊該服務實例,從而實現注冊中心之間的服務同步。通過服務同步,消費者就可以通過這兩個注冊中心的任意一個獲取到兩個服務提供者的服務信息。

解釋:哪些服務是被服務A同步的呢?

  即各個注冊中心中和服務A的服務名、端口號都相同的服務。

注冊中心1:

注冊中心2:

3.服務續約

  在服務注冊完之后,服務提供者會維護一個心跳來告訴注冊中心自己還活着,以防止注冊中心的“剔除任務”將該服務實例從服務列表剔除,我們把該操作稱為續約。

eureka.instance.lease-renewal-interval-in-seconds=30  #服務續約任務的調用間隔時間,默認為30秒
eureka.instance.lease-expiration-duration-in-seconds=90 #定義服務失效的時間,默認90秒

 2.服務消費者

1.獲取服務

  到這里,服務注冊中心都注冊了一個服務,並且該服務都擁有兩個服務實例。當我們啟動服務消費者的時候,會發送REST請求給注冊中心,來獲取注冊中心的服務清單。為了性能考慮,注冊中心會維護一份只讀的服務清單返回給客戶端,該緩存清單默認30秒更新一次。

eureka.client.fetch-register=true  #確定會獲取注冊中心的服務清單
eureka.client.fetch-register-interval-seconds=30 #緩存清單的更新時間,默認30秒

2.服務調用

  服務消費者獲取到服務清單后,通過服務名可以獲得服務提供的服務實例名和該實例的元數據信息,由於服務實例有詳細的元數據信息,因而客戶端可以根據自己的需要調用哪個服務實例,在Spring Cloud Ribbon中采用輪詢的方式進行調用,從而實現客戶端的負載均衡。

3.服務下線

  當服務掛掉后,會觸發下線的REST請求給注冊中心,注冊中心收到請求后會將該服務的狀態設置成“DOWN”,並把下線事件傳播出去。

3.服務注冊中心

1.失效剔除

   有些時候我們的服務不會正常下線,有可能是內存溢出、網絡故障等原因導致服務不可用,而注冊中心並外收到服務下線請求。為了從服務列表中將無法提供的服務正確剔除,注冊中心在啟動的時候會創建一個定時任務,每隔一段時間(默認60秒)將當前服務清單中超時(默認90秒)沒有續約的服務剔除。

2.自我保護

  服務注冊到注冊中心后,會維護一個心跳連接,告訴注冊中心自己還活着。注冊中心在運行期間,會統計該服務心跳失敗的比例,15分鍾低於85%(在開發環境,debug調試的時候很容易出現;生成環境網絡不穩定會導致) 的情況下,注冊中心會將服務信息保存起來,讓這些服務實例不會過期,更不會剔除服務實例。但是這段時間服務實例若出現問題,那么消費者很容易拿到不可用的服務實例,從而出現調用失敗的情況。所以客戶端需要有容錯機制,比如使用請求重試、斷路由等機制。

  我們公司內部產品遇到過這種情況,用戶登錄系統時有時候超時最終返回錯誤頁面,有時候就可以正常登錄。當時確定的影響因素是網絡非常不穩定,那么在網絡穩定性問題解決之前,服務需要正常訪問,當時采用的方案是請求重試機制,一般在第二次請求時便會請求成功,而且速度和網絡良好的情況差不多。qa那邊也會認為這個問題解決了。當然,網絡正常后,服務也會正常訪問。現在看來,原來是注冊中心的自我保護機制導致的。解決方案就是請求重試和斷路由等機制了。

  由於在本地開發的時候,debug調試,會經常引起注冊中心自我保護機制,所以,在本地開發的時候可以關閉注冊中心的自我保護機制,以確保注冊中心將不可用的服務立即剔除。

eureka.server.enable-self-preservation=false #關閉自我保護機制

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM