深入理解Eureka之源碼解析

Eureka的一些概念

Register：服務注冊 當Eureka客戶端向Eureka Server注冊時，它提供自身的元數據，比如IP地址、端口，運行狀況指示符URL，主頁等。

Renew：服務續約 Eureka客戶會每隔30秒發送一次心跳來續約。 通過續約來告知Eureka Server該Eureka客戶仍然存在，沒有出現問題。 正常情況下，如果Eureka Server在90秒沒有收到Eureka客戶的續約，它會將實例從其注冊表中刪除。 建議不要更改續約間隔。

Fetch Registries：獲取注冊列表信息 Eureka客戶端從服務器獲取注冊表信息，并將其緩存在本地。客戶端會使用該信息查找其他服務，從而進行遠程調用。該注冊列表信息定期（每30秒鐘）更新一次。每次返回注冊列表信息可能與Eureka客戶端的緩存信息不同， Eureka客戶端自動處理。如果由于某種原因導致注冊列表信息不能及時匹配，Eureka客戶端則會重新獲取整個注冊表信息。 Eureka服務器緩存注冊列表信息，整個注冊表以及每個應用程序的信息進行了壓縮，壓縮內容和沒有壓縮的內容完全相同。Eureka客戶端和Eureka 服務器可以使用JSON / XML格式進行通訊。在默認的情況下Eureka客戶端使用壓縮JSON格式來獲取注冊列表的信息。

Cancel：服務下線

Eureka客戶端在程序關閉時向Eureka服務器發送取消請求。 發送請求后，該客戶端實例信息將從服務器的實例注冊表中刪除。該下線請求不會自動完成，它需要調用以下內容： DiscoveryManager.getInstance().shutdownComponent()；

Eviction 服務剔除 在默認的情況下，當Eureka客戶端連續90秒沒有向Eureka服務器發送服務續約，即心跳，Eureka服務器會將該服務實例從服務注冊列表刪除，即服務剔除。

Eureka的高可用架構

如圖為Eureka的高級架構圖，該圖片來自于Eureka開源代碼的文檔，地址為https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance 。

從圖可以看出在這個體系中，有2個角色，即Eureka Server和Eureka Client。而Eureka Client又分為Applicaton Service和Application Client，即服務提供者何服務消費者。 每個區域有一個Eureka集群，并且每個區域至少有一個eureka服務器可以處理區域故障，以防服務器癱瘓。

Eureka Client向Eureka Serve注冊，并將自己的一些客戶端信息發送Eureka Serve。然后，Eureka Client通過向Eureka Serve發送心跳（每30秒）來續約服務的。 如果客戶端持續不能續約，那么，它將在大約90秒內從服務器注冊表中刪除。 注冊信息和續訂被復制到集群中的Eureka Serve所有節點。 來自任何區域的Eureka Client都可以查找注冊表信息（每30秒發生一次）。根據這些注冊表信息，Application Client可以遠程調用Applicaton Service來消費服務。

Register服務注冊

服務注冊，即Eureka Client向Eureka Server提交自己的服務信息，包括IP地址、端口、service ID等信息。如果Eureka Client沒有寫service ID，則默認為 ${spring.application.name}。

服務注冊其實很簡單，在Eureka Client啟動的時候，將自身的服務的信息發送到Eureka Server。現在來簡單的閱讀下源碼。在Maven的依賴包下，找到eureka-client-1.6.2.jar包。在com.netflix.discovery包下有個DiscoveryClient類，該類包含了Eureka Client向Eureka Server的相關方法。其中DiscoveryClient實現了EurekaClient接口，并且它是一個單例模式，而EurekaClient繼承了LookupService接口。它們之間的關系如圖所示。

在DiscoveryClient類有一個服務注冊的方法register()，該方法是通過Http請求向Eureka Client注冊。其代碼如下：

在DiscoveryClient類繼續追蹤register()方法，它被InstanceInfoReplicator 類的run()方法調用，其中InstanceInfoReplicator實現了Runnable接口，run()方法代碼如下：

而InstanceInfoReplicator類是在DiscoveryClient初始化過程中使用的，其中有一個initScheduledTasks()方法。該方法主要開啟了獲取服務注冊列表的信息，如果需要向Eureka Server注冊，則開啟注冊，同時開啟了定時向Eureka Server服務續約的定時任務，具體代碼如下：

然后在來看Eureka server端的代碼，在Maven的eureka-core:1.6.2的jar包下。打開com.netflix.eureka包，很輕松的就發現了又一個EurekaBootStrap的類，BootStrapContext具有最先初始化的權限，所以先看這個類。

其中PeerAwareInstanceRegistryImpl和PeerEurekaNodes兩個類看其命名，應該和服務注冊以及Eureka Server高可用有關。先追蹤PeerAwareInstanceRegistryImpl類，在該類有個register()方法，該方法提供了注冊，并且將注冊后信息同步到其他的Eureka Server服務。代碼如下：

其中 super.register(info, leaseDuration, isReplication)方法，點擊進去到子類AbstractInstanceRegistry可以發現更多細節，其中注冊列表的信息被保存在一個Map中。replicateToPeers()方法，即同步到其他Eureka Server的其他Peers節點，追蹤代碼，發現它會遍歷循環向所有的Peers節點注冊，最終執行類PeerEurekaNodes的register()方法，該方法通過執行一個任務向其他節點同步該注冊信息，代碼如下：

經過一系列的源碼追蹤，可以發現PeerAwareInstanceRegistryImpl的register()方法實現了服務的注冊，并且向其他Eureka Server的Peer節點同步了該注冊信息，那么register()方法被誰調用了呢？之前在Eureka Client的分析可以知道，Eureka Client是通過 http來向Eureka Server注冊的，那么Eureka Server肯定會提供一個注冊的接口給Eureka Client調用，那么PeerAwareInstanceRegistryImpl的register()方法肯定最終會被暴露的Http接口所調用。在Idea開發工具，按住alt+鼠標左鍵，可以很快定位到ApplicationResource類的addInstance ()方法，即服務注冊的接口，其代碼如下：

Renew服務續約

服務續約和服務注冊非常類似，通過之前的分析可以知道，服務注冊在Eureka Client程序啟動之后開啟，并同時開啟服務續約的定時任務。在eureka-client-1.6.2.jar的DiscoveryClient的類下有renew()方法，其代碼如下：

另外服務端的續約接口在eureka-core:1.6.2.jar的 com.netflix.eureka包下的InstanceResource類下，接口方法為renewLease()，它是REST接口。為了減少類篇幅，省略了大部分代碼的展示。其中有個registry.renew()方法，即服務續約，代碼如下:

讀者可以跟蹤registry.renew的代碼一直深入研究。在這里就不再多講述。另外服務續約有2個參數是可以配置，即Eureka Client發送續約心跳的時間參數和Eureka Server在多長時間內沒有收到心跳將實例剔除的時間參數，在默認的情況下這兩個參數分別為30秒和90秒，官方給的建議是不要修改，如果有特殊要求還是可以調整的，只需要分別在Eureka Client和Eureka Server修改以下參數：

eureka.instance.leaseRenewalIntervalInSeconds

eureka.instance.leaseExpirationDurationInSeconds

最后，服務注冊列表的獲取、服務下線和服務剔除就不在這里進行源碼跟蹤解讀，因為和服務注冊和續約類似，有興趣的朋友可以自己看下源碼，深入理解。總的來說，通過讀源碼，可以發現，整體架構與前面小節的eureka 的高可用架構圖完全一致。

Eureka Client注冊一個實例為什么這么慢

Eureka Client一啟動（不是啟動完成），不是立即向Eureka Server注冊，它有一個延遲向服務端注冊的時間，通過跟蹤源碼，可以發現默認的延遲時間為40秒，源碼在eureka-client-1.6.2.jar的DefaultEurekaClientConfig類下，代碼如下：

Eureka Server的響應緩存 Eureka Server維護每30秒更新的響應緩存,可通過更改配置eureka.server.responseCacheUpdateIntervalMs來修改。 所以即使實例剛剛注冊，它也不會出現在調用/ eureka / apps REST端點的結果中。

Eureka Server刷新緩存 Eureka客戶端保留注冊表信息的緩存。 該緩存每30秒更新一次（如前所述）。 因 此，客戶端決定刷新其本地緩存并發現其他新注冊的實例可能需要30秒。

LoadBalancer Refresh Ribbon的負載平衡器從本地的Eureka Client獲取服務注冊列表信息。Ribbon本身還維護本地緩存，以避免為每個請求調用本地客戶端。 此緩存每30秒刷新一次（可由ribbon.ServerListRefreshInterval配置）。 所以，可能需要30多秒才能使用新注冊的實例。

綜上幾個因素，一個新注冊的實例，特別是啟動較快的實例（默認延遲40秒注冊），不能馬上被Eureka Server發現。另外，剛注冊的Eureka Client也不能立即被其他服務調用，因為調用方因為各種緩存沒有及時的獲取到新的注冊列表。

Eureka 的自我保護模式

當一個新的Eureka Server出現時，它嘗試從相鄰節點獲取所有實例注冊表信息。如果從Peer節點獲取信息時出現問題，Eureka Serve會嘗試其他的Peer節點。如果服務器能夠成功獲取所有實例，則根據該信息設置應該接收的更新閾值。如果有任何時間，Eureka Serve接收到的續約低于為該值配置的百分比（默認為15分鐘內低于85％），則服務器開啟自我保護模式，即不再剔除注冊列表的信息。

這樣做的好處就是，如果是Eureka Server自身的網絡問題，導致Eureka Client的續約不上，Eureka Client的注冊列表信息不再被刪除，也就是Eureka Client還可以被其他服務消費。

參考資料

http://cloud.spring.io/spring-cloud-static/Dalston.RELEASE/#netflix-eureka-client-starter

https://github.com/Netflix/eureka/wiki

https://github.com/Netflix/eureka/wiki/Understanding-Eureka-Peer-to-Peer-Communication

http://xujin.org/sc/sc-eureka-register/

http://blog.abhijitsarkar.org/technical/netflix-eureka/

http://nobodyiam.com/2016/06/25/dive-into-eureka/

https://mp.weixin.qq.com/s?__biz=MzAxNjk4ODE4OQ==&mid=2247483760&idx=1&sn=821f28fb6715c2bbdcfbb26631b3a118&chksm=9bed2002ac9aa914302171619df1f6a9edcdb8b6ba0167c7075f7b51e2a143a834ea65ea832c&scene=21#wechat_redirect

網絡安全 HTTP 緩存 注冊

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。