Eureka是SpringCloud官方推薦的服務治理組件,本篇文章來看一下eureka服務治理的相關知識,關於eureka治理框架的搭建,可以參考SpringCloud學習之【服務注冊與發現】
首先來看一下服務治理的簡單架構圖
服務注冊中心
-
失效剔除
當我們人為主動進行服務下線,注冊中心會受到注冊實例的服務下線的請求,進而維護的有效服務列表的時效性。但我們還不可避免地會遇到其他不可預期的事情,比如網絡故障、內存溢出等等情況,會導致我們的服務實例與注冊中心失去聯系,但卻沒有發送服務下線請求,故需要一個機制來應付這種場景——注冊中心在啟動時候會創建一個定時任務,默認每隔一段時間(默認60秒)將當前服務清單中超時(默認為90秒)沒有續約的服務實例剔除出去
- 設置失效剔除時間,單位ms
eureka.server.eviction-interval-timer-in-ms=60000
- 設置失效剔除時間,單位ms
-
自我保護
服務的有效信息靠服務注冊中心通過心跳機制來維護,那要是服務注冊中心自己出問題了呢?服務注冊中心認為,少數服務失效是服務實例的故障,而大多數的服務失效則認為是自己的故障。Eureka通過一個自我保護機制來實現:服務注冊到Eureka Server之后,會維護一個心跳連接,那么Eureka Server在運行期間會統計心跳失敗的比例在15分鍾內是否低於85%,如果出現低於的情況,Eureka Server會將當前的實例注冊信息保護起來,不會讓它們立刻過期。
- 關閉自我保護機制
eureka.server.enable-self-preservation=false
注意:
保護機制在生產環境中,通常是為了防止因網絡原因而導致原本沒有問題的服務被清除。而如果真的是大面積服務失效,那么久需要服務容錯機制了,往后會提到的熔斷器。因此一旦開啟了保護機制,則服務注冊中心維護的服務實例就不是那么准確了。
關於自我保護機制更深入了解,可參考Spring Eureka自我保護機制
- 關閉自我保護機制
服務提供者
-
服務注冊
“服務提供者”在啟動的時候會通過REST請求的方式將自己注冊到服務注冊中心上,並將自身的一些信息一塊帶上。服務中心對之進行接收保存並更新服務清單,並對其他注冊的服務實例進行廣播
源碼解讀可參考EUREKA服務注冊源碼品讀
-
服務同步
如架構圖所示,這里的兩個微服務提供者分別注冊到兩個不同的服務注冊中心上,也就是說,它們的信息分別被兩個服務注冊中心所維護。此時由於服務注冊中心之間因互相注冊為服務,當服務提供者發送注冊請求到一個服務注冊中心時,它會將該請求轉發給集群中相連的注冊中心,從而實現注冊中心之間的服務同步。通過服務同步,兩個服務提供者的服務信息就可以通過這兩台服務注冊中心中的任意一台獲取
-
服務續約
在注冊完服務之后,服務提供者通過心跳機制來告知服務注冊中心“我還活着”,以防止服務中心的“失效剔除”定時任務將服務進行剔除,我們稱該操作為服務續約
- 定義服務續約間隔,默認30
eureka.instance.lease-renewal-interval-in-seconds=30 - 定義服務失效時間,默認90
eureka.instance.lease-expiration-duration-in-seconds=90
- 定義服務續約間隔,默認30
服務消費者
-
獲取服務
當我們啟動服務消費者的時候,它會發送一個REST請求給服務注冊中心,來獲取上面注冊的服務清單。為了性能考慮,Eureka Server會維護一份只讀的服務清單來返回給客戶端,同時該緩存清單會每隔30秒更新一次。
- 想服務注冊中心注冊
eureka.client.register-with-eureka=true - 修改緩存服務清單時間間隔,默認30s
eureka.client.registry-fetch-interval-seconds=30
- 想服務注冊中心注冊
-
服務調用
服務消費者通過上面提到的獲取服務清單后,就可以拿到的想要調用的服務提供者的詳細信息,然后根據自身需求進行服務調用
-
服務下線
在系統運行過程中必然會面臨關閉或重啟服務的某個實例的情況,在服務關閉期間,我們自然不希望客戶端會繼續調用關閉了的實例。所以客戶端程序中,當服務實例進行正常的關閉操作時,它會觸發一個服務下線的REST請求給Eureka Server,告訴服務注冊中心:“我要下線了”。服務端在接收到請求之后,將該服務狀態設置為(DOWN),並把該下線事件傳播出去。