SpringCloud解析之Eureka

本文基於Spring Cloud Edgware.SR6版本，從功能和架構上解析Eureka，讓你們對Eureka有一個較爲清晰的認識（本文默認你們對分佈式微服務有一個初步的概念和理解，本文不涉及或少許涉及源碼）。

官方概念這裏就不貼了，我的理解，Eureka是Spring Cloud分佈式微服務架構的服務治理方案之一，提供服務註冊，服務發現，服務維護和治理，註冊中心集羣等功能。

Eureka中維護一份服務列表，當客戶端（服務提供者或服務消費者）註冊服務實例到Eureka，Eureka會將其實例信息維護到列表中，這叫建立租約；租約的有效時間默認是30秒，客戶端須要每隔一段時間發送一次心跳告知Eureka本身的服務正常有效，這叫續約。

Eureka是服務註冊中心，但當註冊中心集羣時，Eureka也作爲客戶端，向其它註冊中心註冊本身，同時獲取其它註冊中心的維護的服務列表，當有新的客戶端註冊進來時，Eureka會通知其它的註冊中心，異步更新服務列表，達到高可用的目的。Eureka默認會開啓以下配置，若是做爲單個註冊中心或本地測試，能夠關閉。

eureka:
  client:
#   不向Eureka註冊本身
    registerWithEureka: false
#     不獲取服務列表
    fetchRegistry: false

客戶端正常下線時，會通知Eureka，Eureka就從服務列表中將其剔除。若是客戶端非正常下線（好比宕機，系統崩潰）沒法通知到Eureka，Eureka會定時檢查本身的服務列表，發現有服務的租約超過有效時間，也會認爲服務失效而剔除。

Eureka默認配置會開啓一個保護機制，當一段時間內有超過15%的服務失效時，Eureka不會剔除這些服務，而是繼續維護在服務列表，直到客戶端從新發送心跳。Eureka有一個心跳次數閥值係數=0.85（能夠經過配置修改），客戶端默認心跳間隔=30秒，1分鐘內總心跳數=客戶端實例數*2，1分鐘心裏跳閥值=1分鐘內總心跳數*0.85，當1分鐘內有效客戶端實例的心跳總數<心跳閥值，Eureka就會由於保護機制而繼續維護在服務列表，所以客戶端須要有重試和熔斷機制。

Eureka和ZooKeeper

Eureka和ZooKeeper，雖然都是服務集羣治理的實現方案，可是區別也是比較明顯的。CAP理論中，C(consistency)數據一致性，A(availability)可用性，P(partition-tolerance)分區容錯性，Eureka強調AP，經過緩存和異步同步達到最終一致性，ZooKeeper更兼顧CP，當節點失效就會剔除。

我的更傾向Eureka，無論是服務註冊和發現，仍是註冊中心集羣，只須要引入依賴包，添加配置和註解，就能夠達到效果，同時不得不佩服Spring Boot和Spring Cloud的強大。可是，若是是ZooKeeper轉使用Eureka，可能會由於其內部的緩存和保護機制感到彆扭，此處貼上本人的配置，能夠減小緩存時效，提升緩存刷新頻率，強制關閉客戶端的話，大概30秒Eureka就會剔除服務（Eureka默認狀況下大概要4分鐘纔會剔除服務），供你們參考

Eureka註冊中心配置（YML）

eureka:
  server:
#     檢查失效服務剔除時間間隔
    evictionIntervalTimerInMs: 2000
#   關閉保護機制
    enableSelfPreservation: false

Eureka客戶端（properties）

#服務實例租約有效時間
eureka.instance.lease-expiration-duration-in-seconds=15
#服務實例續約間隔時間（心跳間隔）
eureka.instance.lease-renewal-interval-in-seconds=5
#客戶端更新服務列表間隔時間
eureka.client.registryFetchIntervalSeconds=5