一：Eureka實現服務註冊和發現
Eureka和zookeeper的區別：
1.ZooKeeper保證的是CP,Eureka保證的是AP
2.ZooKeeper有Leader和Follower角色,Eureka各個節點平等
3.ZooKeeper採用過半數存活原則,Eureka採用自我保護機制解決分區問題。因此在zookeeper進行選舉和故障轉移的過程中服務是不可用的，但是保證了數據的強一致性，而在自我保護機制中服務可用，但不一定是最新數據，當恢復之後會達到最終一致性。
Spring Cloud Eureka 是 Spring Cloud Netflix 微服務套件的一部分，基於 Netflix Eureka 做了二次封裝，主要負責完成微服務架構中的服務治理功能，服務治理可以說是微服務架構中最爲核心和基礎的模塊，它主要用來實現各個微服務實例的自動化註冊與發現。
服務註冊：在服務治理框架中，通常都會構建一個註冊中心，每個服務單元向註冊中心登記自己提供的服務，將主機與端口號、版本號、通信協議等一些附加信息告知註冊中心，註冊中心按照服務名分類組織服務清單，服務註冊中心還需要以心跳的方式去監控清單中的服務是否可用，若不可用需要從服務清單中剔除，達到排除故障服務的效果。
服務發現：由於在服務治理框架下運行，服務間的調用不再通過指定具體的實例地址來實現，而是通過向服務名發起請求調用實現。
Eureka Server：服務的註冊中心，負責維護註冊的服務列表, 同其他服務註冊中心一樣，支持高可用配置。客戶端註冊的主要數據包括服務名、機器 ip、端口號、域名等等。
Service Provider：服務提供方，作爲一個 Eureka Client，一方面向Eureka Server 註冊自身提供的服務，並週期性的發送心跳來更新它的服務租約，進行續約。另一方面也可以從eureka server查詢當前註冊的服務信息並把它們緩存到本地並週期新的刷新服務狀態。
Service Consumer本質上也是一個Eureka Client（它也會向Eureka Server註冊，只是這個註冊信息無關緊要罷了）。它啓動後，會從Eureka Server上獲取所有實例的註冊信息，包括IP地址、端口等，並緩存到本地。這些信息默認每 30 秒更新一次。前文提到過，如果與Eureka Server通信中斷，Service Consumer仍然可以通過本地緩存與Service Provider通信。
二：Eureka Server 的高可用集羣
Eureka Server可以運行多個實例來構建集羣，解決單點問題，但不同於ZooKeeper的選舉 leader 的過程，Eureka Server採用的是 Peer to Peer對等通信。這是一種去中心化的架構，無master/slave區分，每一個Peer都是對等的。在這種架構中，節點通過彼此互相註冊來提高可用性，每個節點需要添加一個或多個有效的serviceUrl指向其他節點。每個節點都可被視爲其他節點的副本。
如果某臺Eureka Server宕機，Eureka Client的請求會自動切換到新的Eureka Server 節點，當宕機的服務器重新恢復後，Eureka會再次將其納入到服務器集羣管理之中。當節點開始接受客戶端請求時，所有的操作都會進行replicateToPeer（節點間複製）操作，將請求複製到其他Eureka Server當前所知的所有節點中。
一個新的Eureka Server節點啓動後，會首先嚐試從鄰近節點獲取所有實例註冊表信息，完成初始化。默認配置下，如果Eureka Server在一定時間內沒有接收到某個服務實例的心跳，EurekaServer將會註銷該實例（默認爲90秒，通過eureka.instance.lease-expiration-duration-in-seconds配置）。當Eureka Server節點在短時間內丟失過多的心跳時（ Eureka Server 每分鐘收到心跳續約的數量低於一個閾值，並且持續 15 分鐘，就會觸發自我保護比如發生了網絡分區故障），那麼這個節點就會進入自我保護模式。
在自我保護模式中，Eureka Server會保護服務註冊表中的信息，不再註銷任何服務實例。當它收到的心跳數重新恢復到閾值以上時，該 Eureka Server節點就會自動退出自我保護模式。它的設計哲學前面提到過，那就是寧可保留錯誤的服務註冊信息，也不盲目註銷任何可能健康的服務實例。這樣做會使客戶端很容易拿到實際已經不存在的服務實例，會出現調用失敗的情況。因此客戶端要有容錯機制，比如請求重試、斷路器。
服務端的更改可能需要 2 分鐘才能傳播到所有客戶端的原因：
Eureka Server 對註冊列表進行緩存，默認時間爲 30s。
Eureka Client 對獲取到的註冊信息進行緩存，默認時間爲 30s。
Ribbon 會從上面提到的Eureka Client 獲取服務列表，將負載均衡後的結果緩存 30s。
如果不是在 Spring Cloud 環境下使用這些組件 (Eureka, Ribbon)，服務啓動後並不會馬上向 Eureka 註冊，而是需要等到第一次發送心跳請求時纔會註冊。心跳請求的發送間隔默認是 30s。Spring Cloud 對此做了修改，服務啓動後會馬上註冊。