Spring Cloud Eureka基本概述

　　記一次Eureka的進一步學習。

一、Eureka簡介

　　百科描述：Eureka是Netflix開發的服務發現框架，本身是一個基於REST的服務，主要用於定位運行在AWS域中的中間層服務，以達到負載均衡和中間層服務故障轉移的目的。SpringCloud 將它集成在其子項目spring-cloud-netflix中，以實現SpringCloud的服務發現功能。

　　Eureka 包括 Eureka Server 和 Eureka Client，Eureka Server 即注冊中心，Eureka Client 啟動后會向 Eureka Server 注冊自己，這樣其他的 Eureka Client 訪問 Eureka Server 即可拿到注冊了的 Eureka Client 的信息。

 

二、基本結構

　　上圖是官網給的基於集群部署的 Eureka 架構圖，先看一下圖上各個部件的表示含義以及它們之間的交互：

• Eureka Server：Eureka 服務端，多個 Eureka Server 可構成集群，集群中各節點完全對等。
• Eureka Client：Eureka 客戶端，業務服務依賴它實現服務注冊和服務發現功能。
• Application Service：服務提供者，依賴 Eureka Client 實現服務注冊功能。
• Application Client：服務消費者，依賴 Eureka Client 實現服務發現功能。
• Register：Eureka Client 啟動時會發起 Register 請求向 Eureka Server 注冊自己。
• Renew：Eureka Client 會周期性的向 Eureka Server 發送心跳來續約，默認30s。
• Cancel：Eureka Client 關閉時會發送 Cancel 下線請求。
• Get：Eureka Client 會周期性的發送 Get 請求，從 Eureka Server 獲取注冊表信息，默認30s。
• Make Remote Call：服務消費者通過 Make Remote Call 訪問服務提供者。
• Replicate：Eureka Server 之間通過 Replicate 實現數據同步。當 Eureka Client 有請求（Heartbeat, Register, Cancel, StatusUpdate, DeleteStatusOverride）到某一個 Eureka Server 節點，該節點完成自身對應的操作后，會通過 Replicate 將本次請求同步到其他節點。

 

三、自我保護機制

　　上面說了，Eureka Client 默認每30s會向 Eureka Server 發送一次心跳來實現續約，默認情況下，Eureka Server 超過90s沒有收到該 Eureka Client 的心跳，則會注銷該 Eureka Client。自我保護機制正是一種針對網絡異常波動的安全保護措施，Eureka Server 在運行期間會去統計續約數量，如果在 15 分鍾之內續約數量低於 85%，Eureka Server 則會進入自我保護模式，停止實例過期將當前的實例注冊信息保護起來，同時提示一個警告，Eureka 的 web 頁面這個紅色告警語句應該很眼熟：

 

　　進入自我保護模式時，此時會出現以下幾種情況：

• Eureka Server 不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務。
• Eureka Server 仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上，保證當前節點依然可用。
• 當網絡穩定時，當前Eureka Server新的注冊信息會被同步到其它節點中。

　　自我保護機制通過配置 eureka.server.enable-self-preservation 來開啟/關閉，默認開啟。

 

四、Eureka Server注冊表和多級緩存機制

1. 注冊表的存儲結構

   

    

   　　先來看一下注冊表的存儲結構，上圖 ConcurrentHashMap<String, Map<String, Lease>> register 就是注冊表。ConcurrentHashMap 的 key 存儲的是服務名稱，value 的這個 Map 存儲的是該服務對應的多個實例信息，Map 的 key 存儲的是服務實例的id，value 的 Lease 就是實例信息，InstanceInfo 就代表了服務實例的具體信息，比如機器的ip地址、hostname 以及端口號，Lease 可以理解為 InstanceInfo 的包裝類，維護了服務實例的一些動態數據，比如最近的心跳時間。另外，從源碼中可以看到，register 是完全基於內存的，服務的注冊、下線、故障，全部會在內存里維護和更新這個注冊表。

    

2. 多級緩存機制

    

   

    

 　　上圖其實已經很清晰了，簡單理一下注冊和獲取注冊表的流程：

• 注冊：
  • Eureka Client 發起 Register 請求。
  • Eureka Server 將 Eureka Client 信息添加到注冊表，同時使 ReadWriteCacheMap 緩存失效。
  • 一段時間后（默認30s），Eureka Server 的后台線程發現 ReadWriteCacheMap 被清空了，就會清空 ReadOnlyCacheMap 緩存。
• 獲取注冊表：
  • Eureka Client 發起Get請求。
  • 首先，從 ReadOnlyCacheMap 緩存查詢，有就返回。
  • 如果沒有，從 ReadWriteCacheMap 緩存查詢，有就返回。
  • 如果還沒有，就查詢內存中的注冊表，同時將結果填充到 ReadWriteCacheMap 緩存和 ReadOnlyCacheMap 緩存。

　　這就是 Eureka Server 端的緩存機制，通過 ReadWriteCacheMap 緩存和 ReadOnlyCacheMap 緩存減少了注冊表的讀寫沖突，起到了類似於讀寫分離的效果，進一步保證了 Eureka 的性能。

　　同時 Eureka Client 端也緩存了一份注冊表信息，周期性的從 Eureka Server 拉取最新的數據。

 

五、總結

 　　本文只記錄了Eureka的一些基本概念，后面再針對每個具體功能的源碼實現做個詳細記錄。

 

參考：https://mp.weixin.qq.com/s/qjMphuPiihBmU2QtFMIfzw