Eureka 的設計理念
服務實例註冊到服務中心
服務的註冊，本質上就是在服務啓動的時候，調用 Eureka Server 的 REST API 的 Registrer 方法，註冊應用實例的信息。對於 Java 應用，可以使用 Netflix 的 Eureka Client 封裝 API 調用；對於 Spring Cloud 應用，可以使用 spring-cloud-starter-netflix-eureka-client 基於 Spring Boot 自動配置，自動註冊服務。
服務實體從服務中心剔除
正常情況下，服務實例在關閉應用的時候，應該通過鉤子方法或其他生命週期回調方法，調用 Eureka Server 的 REST API 的 de-register 方法，來刪除自身服務實例的信息。另外，爲了解決服務掛掉，或網絡中斷等其他異常情況沒有及時刪除自身信息的問題，Eureka Server 要求 Client 定時進行續約，也就是發送心跳，來證明自己是存活的、健康的、可調用的。如果超過一定時間沒有續約，則認爲 Client 停掉了，Server 端會主動剔除。
服務實例一致性問題
由於註冊中心（Eureka Server）通常來說是一個集羣，就需要 Client 在集羣中保持一致。Eureka 通過 CAP、Peer to Peer、Zone + Region、SELF PRESERVATION 四個方面保證一致性。
CAP
C：Consistency，數據一致性。即數據在存在多個副本的情況下，可能由於網絡、機器故障、軟件系統等問題早上數據寫入部分副本成功，副本副本失敗，進而造成副本之間數據不一致，存在衝突。滿足一致性則要求對數據的更新操作成功後，多副本的數據保持一致。
A：Availablility，服務可用性。在任何時候，客戶端對集羣進行讀寫操作時，請求能夠正常響應，即，在一定的時間內完成。
P：Partition Tolerance，分區容忍性，即發生通信故障的時候，整個集羣被分隔成多個無法相互通信的分區時，集羣仍然可用。
在分佈式系統中，網絡條件一般是不可控的，網絡分區是不可避免的，因此分佈式系統必須滿足分區容忍性，所以分佈式系統的設計需要在 AP、CP 之間進行選擇。
Zookeeper 是 CP Eureka是CA
Peer to Peer
分佈式系統的數據在多個副本直接的複製方式，可分爲：主從複製、對等複製
主從複製
主從複製，就是 Master-Slave 模式，有一個主副本，其他爲從副本。所有的對數據的寫操作，都提交到主副本，然後由主副本更新到其他的從副本。具體的更新方式有：同步更新、異步更新、同步異步混合更新。
對於主從複製的模式，寫操作都要經過主副本，所有主副本的壓力會很大。但是，從副本會分擔主副本的讀請求，而一個系統最大的請求都是讀請求，所有可以一般情況下都是一主多從的架構。
對等複製
即 Peer to Peer 模式。副本之間不分主從，任何副本都能接收寫操作，然後每個副本之間相互進行數據更新。對於對等複製模式來說，由於任何副本都可以接收到寫操作，所以不存在寫操作的壓力瓶頸。但是由於每個副本都能進行寫操作，各個副本之間的數據同步及衝突處理是一個比較棘手的問題。
Eureka 採用的就是 Peer to Peer
SELF PRESERVATION
在分佈式系統中，通常需要對應用實例的存活進行健康檢查，需要處理好網絡抖動或短暫的不可用造成的誤判；另外，Eureka Server 和 Client 之間如果存在網絡分區，在極端情況下可能會導致 Eureka Server 情況部分服務的實例列表，這個將嚴重影響到 Eureka Server 的高可用。因此，Eureka 引入了自我保護機制(SELF PRESERVATION)。
Client 與 Server 之間有租約，Client 需要定時發送心跳維持租約，表示自己存活。Eureka 通過當前註冊的實例數，計算每分鐘應該從應用實例接收到的心跳數，如果最近一分鐘接收到的續約次數小於指定的閾值的話，則關閉租約失效剔除，進制定時任務剔除失效的實例，從而保護註冊信息。