1.註冊中心實現原理

分散式微服務架構中，服務註冊中心用於儲存服務提供者地址資訊、服務釋出相關的屬性資訊，消費者通過主動查詢和被動通知的方式獲取服務提供者的地址資訊，而不再需要通過硬編碼方式得到提供者的地址資訊。消費者只需要知道當前系統釋出了那些服務，而不需要知道服務具體存在於什麼位置，這就是透明化路由。
1）服務提供者啟動
2）服務提供者將相關服務資訊主動註冊到註冊中心
3）服務消費者獲取服務註冊資訊：
pull模式：服務消費者可以主動拉取可用的服務提供者清單
push模式：服務消費者訂閱服務（當服務提供者有變化時，註冊中心也會主動推送更新後的服務清單給消費者
4）服務消費者直接呼叫服務提供者
另外，註冊中心也需要完成服務提供者的健康監控，當發現服務提供者失效時需要及時剔除；

2.Eureka 基礎架構

3.Eureka 互動流程及原理

Eureka 包含兩個元件：Eureka Server 和 Eureka Client，Eureka Client是一個Java客戶端，用於簡化與Eureka Server的互動；Eureka Server提供服務發現的能力，各個微服務啟動時，會通過EurekaClient向Eureka Server 進行註冊自己的資訊（例如網路資訊），Eureka Server會儲存該服務的資訊；
1）圖中us-east-1c、us-east-1d，us-east-1e代表不同的區也就是不同的機房
2）圖中每一個Eureka Server都是一個叢集。
3）圖中Application Service作為服務提供者向Eureka Server中註冊服務，Eureka Server接受到註冊事件會在叢集和分割槽中進行資料同步，Application Client作為消費端（服務消費者）可以從EurekaServer中獲取到服務註冊資訊，進行服務呼叫。
4）微服務啟動後，會週期性地向Eureka Server傳送心跳（預設週期為30秒，預設Eureka Server90S會將還沒有續約的給剔除）以續約自己的資訊
5）Eureka Server在一定時間內沒有接收到某個微服務節點的心跳，Eureka Server將會登出該微服務節點（預設90秒）
6）每個Eureka Server同時也是Eureka Client，多個Eureka Server之間通過複製的方式完成服務註冊列表的同步
7）Eureka Client會快取Eureka Server中的資訊。即使所有的Eureka Server節點都宕掉，服務消費者依然可以使用快取中的資訊找到服務提供者
Eureka通過心跳檢測、健康檢查和客戶端快取等機制，提高系統的靈活性、可伸縮性和高可用性。

4.Eureka細節詳解

Eureka元資料詳解

Eureka的元資料有兩種：標準元資料和自定義元資料。
標準元資料：主機名、IP地址、埠號等資訊，這些資訊都會被髮布在服務登錄檔中，用於服務之間的呼叫。
自定義元資料：可以使用eureka.instance.metadata-map配置，符合KEY/VALUE的儲存格式。這些元資料可以在遠端客戶端中訪問。

Eureka客戶端詳解

服務提供者（也是Eureka客戶端）要向EurekaServer註冊服務，並完成服務續約等工作
服務註冊詳解（服務提供者）
1）當我們匯入了eureka-client依賴座標，配置Eureka服務註冊中心地址
2）服務在啟動時會向註冊中心發起註冊請求，攜帶服務元資料資訊
3）Eureka註冊中心會把服務的資訊儲存在Map中。
服務續約詳解（服務提供者）
服務每隔30秒會向註冊中心續約(心跳)一次（也稱為報活），如果沒有續約，租約在90秒後到期，然後服務會被失效。每隔30秒的續約操作我們稱之為心跳檢測
Eureka Client ：30S續約一次，在Eureka Server更新自己的狀態 (Client端進行配置)
Eureka Server：90S還沒有進行續約，將該微服務例項從服務登錄檔（Map）剔除 (Client端進行配置)
Eureka Client： 30S拉取服務最新的登錄檔並快取到本地 (Client端進行配置)
往往不需要我們調整這兩個配置

獲取服務列表（服務登錄檔）詳解（服務消費者）
每隔30秒服務會從註冊中心中拉取一份服務列表，這個時間可以通過配置修改。往往不需要我們調整
1）服務消費者啟動時，從 EurekaServer服務列表獲取只讀備份，快取到本地
2）每隔30秒，會重新獲取並更新資料
3）每隔30秒的時間可以通過配置eureka.client.registry-fetch-interval-seconds修改

Eureka服務端詳解

服務下線：
1）當服務正常關閉操作時，會發送服務下線的REST請求給EurekaServer。
2）服務中心接受到請求後，將該服務置為下線狀態

失效剔除：
Eureka Server會定時（間隔值是eureka.server.eviction-interval-timer-in-ms，預設60s）進行檢查，如果發現例項在在一定時間（此值由客戶端設定的eureka.instance.lease-expiration-duration-inseconds定義，預設值為90s）內沒有收到心跳，則會登出此例項。

自我保護機制：
自我保護模式正是一種針對網路異常波動的安全保護措施，使用自我保護模式能使Eureka叢集更加的健壯、穩定的執行。
自我保護機制的工作機制是：如果在15分鐘內超過85%的客戶端節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，Eureka Server自動進入自我保護機制，此時會出現以下幾種情況：
1. Eureka Server不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務。
2. Eureka Server仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上，保證當前節點依然可用。
3. 當網路穩定時，當前Eureka Server新的註冊資訊會被同步到其它節點中。
因此Eureka Server可以很好的應對因網路故障導致部分節點失聯的情況，而不會像ZK那樣如果有一半不可用的情況會導致整個叢集不可用而變成癱瘓。
為什麼會有自我保護機制？
預設情況下，如果Eureka Server在一定時間內（預設90秒）沒有接收到某個微服務例項的心跳，Eureka Server將會移除該例項。但是當網路分割槽故障發生時，微服務與Eureka Server之間無法正常通訊，而微服務本身是正常執行的，此時不應該移除這個微服務，所以引入了自我保護機制。