- eureka功能
- eureka註冊生效延時
- CAP定理在eureka中的應用
- eureka的數據複製方式
Eureka功能
Eureka是spring cloud生態下的服務註冊中心組件, 類似功能的常用組件還有zookeeper, consul等, 在spring cloud中, eureka提供如下功能的服務
- 服務註冊
微服務架構中的提供者也就是Eureka客戶端，在其啟動的時候，迴向Eureka服務器註冊自己的信息，同時Eureka服務器會維護一個一註冊的服務列表
- 服務發現
Eureka客戶端啟動時會從Eureka服務器中獲取註冊表信息，並將其緩存在本地，改註冊表信息定期（默認30秒）從Eureka服務器中進行同步，每次返回註冊列表信息可能不同，有Eureka客戶端自動處理。
- 服務續約
當註冊成功後，eureka客戶端會每隔30秒（可配置）的頻率想Eureka服務器發送一次心跳，發送心跳其實就是執行服務續約操作，避免自己的註冊信息被Eureka服務器刪除，續約處理和服務註冊基本一致。
- 服務下線
當服務實例關閉時，會先向Eureka服務器發送服務下線申請，Eureka服務器會將該實例從註冊表中刪除
Eureka註冊生效延時
在Eureka服務治理環境下，一個微服務上線有3處緩存處理和1處延遲處理，經過這些處理後才能夠被服務消費方獲取道並使用 1. Eureka服務器對服務註冊列表進行緩存，默認30秒。也就是即使註冊車更能夠給你也不會立即在結果中出現 2. Eureka客戶端/消費方對註冊服務信息進行緩存，默認時間30秒。也就是客戶端本地刷新並發現其他實例可能需要30秒 3. Ribbon負載均衡，獲取Eureka客戶端的服務列表，並將負載均衡後的結果緩存30秒 4. Eureka客戶端啟動時（不是啟動完成）不是立即向Eureka服務器註冊自己，而是延遲默認40秒後才會註冊 綜上：一個新的實例從啟動到可用最多可能需要2分鐘左右。
CAP定理在Eureka中的應用
Eureka用的是AP，在大規模部署的情況下（比如微服務），失敗是不可避免的，包括Eureka服務本身的失敗等，需要Eureka再出現網絡分區的時候依然可用，也就是AP。在實際生產實踐中，服務註冊即發現中心保留可用及過期的數據總比丟失掉可用的數據要好，這樣的話集群中所有的節點並不是強一致性的，即使註冊中心的不同節點保存的服務提供者信息不相同，也不會造成災難性的後果, 這就需要客戶端支持負載均衡及失敗重試，在Netflix的生態中，有ribbon提供這個功能
Eureka的數據複製方式
一般而言，分佈式系統數據在多個副本間的複製方式，可分為主從複製和對等複製 主從複製：也就是Master-Slave模式，又一個主副本，其他的為從副本，所有的對數據的寫操作都要提交到主副本，在後再有主副本更新到其他副本， 更新方式分為同步更新、異步更新、同步異步混合。 由於寫操作都在主副本上，所以他是整個系統的瓶頸，讀操作是可分擔到從副本上 對等複製：Peer to Peer模式，副本間部分主從，任何副本都可以接受讀寫操作然後相互更新各個副本之間的同步及衝突處理是比較棘手的問題, Eureka採用的就是這種方式
分享到:
