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），並把該下線事件傳播出去。