EurekaServer啟動,等待客戶端前來注冊. EurekaServer之間通過Replicat完成服務列表同步.每個Eureka節點,都會存儲完整的服務列表. EurekaClient會通過配置中的defaultZone信息前往EurekaServer去進行注冊. 心跳機制:微服務客戶端每隔30s(默認值)回向Server發送一次"心跳".報告狀態.如果超過90s(默認值) 沒有接收到心跳,會標注該服務失效,并從服務列表刪除. 自我保護機制:在單位時間內,如果沒有收到超過85%的Client發送過來的心跳,那么會判斷為服務器 自己網絡出現異常.從而進入保護模式.不再刪除服務列表中的微服務.直到心跳請求恢復之 后,Eureka會退出保護模式. EurekaClient會定時全量或者增量從EurekaServer拉取服務列表.并將完整的服務列表緩存到本地. 即使所有server都不能使用,客戶端仍然能夠使用緩存的服務列表完成遠程調用. EurekaClient通過服務列表獲取調用信息,完成服務調用. **Eureka設計** 分布式系統的CAP理論. C:一致性.從各個節點獲得的數據一致. A:可用性.每一次請求都會得到一個(正確)響應. P:分區容忍.節點之間出現網絡分區.系統仍然能夠繼續運行. 分布式系統在設計時,只能傾向于CAP中的兩個,不可能3個同時兼顧. DUBBO的設計傾向于哪兩個? dubbo的設計傾向于CP. dubbo更注重一致性.每次服務列表同步都是由leader發起,確保每個節點都寫入 成功,才會確認寫入.保證了每個節點的一致性. leader不可用時,會選舉新的leader.而在選舉期間.集群是不可用的.直到leader選舉結束,并完成同步.才能 繼續提供服務.所以DUBBO的設計更傾向于數據的一致性. Eureka的設計傾向于哪兩個? eureka的設計傾向于AP.首先,Eureka服務器之間的同步屬于異步的P2P方式.有可能在同一時間不同 Server節點,拉取到不同的服務列表的.但是放心,最終一致性還是可以保障的.Server節點都是平等的,沒有 主從概念.任何一個Server掛掉.客戶端會自動連接到其他存活Server提供服務.即使所有Server都掛掉.客 戶端也會從本地緩存的服務列表繼續獲得信息.由此可以得出結論.Eureka是更傾向于可用性的設計