Eureka服務註冊與發現

Eureka是SpringCloud官方推薦的服務治理組件，本篇文章來看一下eureka服務治理的相關知識，關於eureka治理框架的搭建，能夠參考SpringCloud學習之【服務註冊與發現】

首先來看一下服務治理的簡單架構圖

服務註冊中心

---

• 失效剔除

  當咱們人爲主動進行服務下線，註冊中心會受到註冊實例的服務下線的請求，進而維護的有效服務列表的時效性。但咱們還不可避免地會遇到其餘不可預期的事情，好比網絡故障、內存溢出等等狀況，會致使咱們的服務實例與註冊中心失去聯繫，但卻沒有發送服務下線請求，故須要一個機制來應付這種場景——註冊中心在啓動時候會建立一個定時任務，默認每隔一段時間（默認60秒）將當前服務清單中超時（默認爲90秒）沒有續約的服務實例剔除出去

  • 設置失效剔除時間,單位ms
    eureka.server.eviction-interval-timer-in-ms=60000

• 自我保護

  服務的有效信息靠服務註冊中心經過心跳機制來維護，那要是服務註冊中心本身出問題了呢？服務註冊中心認爲，少數服務失效是服務實例的故障，而大多數的服務失效則認爲是本身的故障。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

服務消費者

---

• 獲取服務

  當咱們啓動服務消費者的時候，它會發送一個REST請求給服務註冊中心，來獲取上面註冊的服務清單。爲了性能考慮，Eureka Server會維護一份只讀的服務清單來返回給客戶端，同時該緩存清單會每隔30秒更新一次。

  • 想服務註冊中心註冊
    eureka.client.register-with-eureka=true
  • 修改緩存服務清單時間間隔,默認30s
    eureka.client.registry-fetch-interval-seconds=30

• 服務調用

  服務消費者經過上面提到的獲取服務清單後，就能夠拿到的想要調用的服務提供者的詳細信息，而後根據自身需求進行服務調用

• 服務下線

  在系統運行過程當中必然會面臨關閉或重啓服務的某個實例的狀況，在服務關閉期間，咱們天然不但願客戶端會繼續調用關閉了的實例。因此客戶端程序中，當服務實例進行正常的關閉操做時，它會觸發一個服務下線的REST請求給Eureka Server，告訴服務註冊中心：「我要下線了」。服務端在接收到請求以後，將該服務狀態設置爲（DOWN），並把該下線事件傳播出去。