一、基礎架構
構建Eureka服務治理有三個核心角色：服務註冊中心、服務提供者和服務消費者。
- 服務註冊中心（Eureka Server）：Eureka提供的服務端，提供服務註冊和發現的功能；
- 服務提供者：提供服務的應用，遵循Eureka通信機制的應用。它將自己註冊到Eureka Server中，以供其他應用發現；
- 服務消費者：消費者應用從服務註冊中心獲取服務列表，從而讓消費者知道可以從哪個服務提供者調用其所需的服務；
很多時候，客戶端既是服務提供者也是服務消費者
![Eurekaæå¡ä½ç³»å¾]()
二、要素
在高可用的集羣中，都會創建兩個或兩個以上的服務註冊中心，他們之間進行相互註冊，使得各自所管理的服務列表在各個註冊中心進行信息同步。
三. 服務治理機制
3.1 服務提供者
3.1.1 服務註冊
服務提供者在啓動的時候會發送REST請求的方式將自己註冊到Eureka Server服務上，同時帶上自身的一些元數據信息。Eureka Server 接受到REST請求之後，將元數據信息存儲到一個雙層Map中，其中第一層的key是服務名，第二層的key是具體的實例名，value值有挺多信息的，其中就有點擊實例需要進行操作的url （value值不太清楚，個人猜測應該url鏈接），Eureka服務端的信息面板中一個服務有多個實例的情況，這些內容就是以雙層Map形式存儲的。
在服務註冊時，需確認一下 eureka.client.register.with.eureka=true參數是否正確，該默認值爲false，若設置爲false 將不會啓動註冊操作。
3.1.2 服務同步
兩個服務提供者分別註冊到兩個不同的註冊中心上，也就是說他們的信息分別被兩個註冊中心所維護，由於服務註冊中心之間因相互註冊爲服務，所以當服務提供者發送一個請求到某個服務註冊中心時，該服務註冊中心也會將請求轉發給集羣中相連的其他註冊中心，從而實現了註冊中心的服務同步。通過服務同步，兩個服務提供者的服務信息就可以通過這兩臺服務註冊中心的任意一臺獲取。
3.1.1 服務續約
在註冊完服務之後，服務提供者會維護一個心跳用來持續告訴Eureka Server 我還活着，以防止Eureka Server 剔除任務 將該服務實例從服務列表中排除出去，我們稱該操作爲“服務續約”
服務續約有兩個重要的屬性：
eureka.instance.lease-renewal-interval-in-seconds=30
表示服務續約的調用間隔時間默認爲30秒
eureka.instance.lease-expiration-duration-in-seconds=90
表示服務失效的時間爲默認90秒
3.2 服務消費者
3.2.1 獲取服務
當我們啓動服務消費者的時候，它會發送一個REST請求到註冊中心，來獲取上面註冊的服務清單，爲了性能考慮，Eureka Server 會維護一份只讀的服務清單返回給客戶端，同時該緩存清單會每隔30秒更新一次
所以獲取服務是服務消費者的基礎，必須確保
eureka.client.fetch-register=true 默認爲ture
若想修改獲取服務清單的更新時間修改
eureka.client.register-fetch-interval-seconds=30 的參數進行修改，默認30秒
3.2.2 服務調用
服務消費者獲取服務清單後，通過服務名獲取具體的實例名和該實例的元數據信息，因爲有這些服務的信息，所以客戶端可以根據自己的需求決定具體調用哪個實例，在ribbon中默認採用輪詢的方式進行調用，從而實現客戶端的負載均衡。
對於訪問實例的選擇 Eureka 中有Region和Zone的概念，一個Region中包含多個Zone，每個服務客戶端會註冊到一個Zone中，所以每個客戶端對應一個Region和一個Zone，在服務調用時優先訪問同一個Zone中的服務提供方，若訪問不到就調用其他的Zone。
3.2.3 服務下線
在服務運行過程中必然會面臨關閉或重啓某個實例的情況，在關閉時我們不希望客戶端繼續調用關閉的實例，所以當服務正常關閉時，會觸發一個REST請求給Eureka Server 告訴服務註冊中心 我要下線了 服務端接收到請求之後，將該服務狀態設置爲(DOWN)並把該下線事件傳播出去。
3.3 服務註冊中心
3.3.1 失效剔除
有時候，服務實例並不一定會正常下線，可能由於內存溢出，網絡故障等原因導致服務不能正常工作，而服務註冊中心並沒有收到服務下線請求，爲了從服務列表中清除那些不可用的服務實例，Eureka Server 在啓動的時候會創建一個定時任務，默認每隔60秒將清單中超時90秒的沒有續約的服務剔除出去。
3.3.2 自我保護
當我們在本地調試基於Eureka的程序時，基本上都會遇到這樣一個問題，在註冊中心信息面板中出現紅色的警告信息：
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
實際上就是觸發了Eureka Server的自我保護機制，因爲服務註冊到Eureka Server之後會維護一個心跳連接，告訴Eureka Server我還活着，Eureka Server在運行期間會統計失敗的比列在15分鐘內低於85%的，如果出現低於的情況（在單機調試的時候跟容易滿足，實際在生產環境上通常是由於網絡不穩定導致），Eureka Server會將這些服務實例保護起來，讓這些服務不過期，儘可能保護這些註冊信息，但是在保護期間客戶端很容易拿到實際已經不存在的服務實例，會出現失敗的情況，所以客戶端必須要有容錯機制，比如使用請求重試，斷路器等機制。
既然本地吊事容易觸發註冊中心自我保護機制 可以通過配置屬性
eureka.server.enable-self-preservation=false 參數來關閉保護機制，以確保服務註冊中心可以將不可用的服務實例正確剔除。
啓動自我保護後此時會出現以下幾種情況：
1、Eureka Server不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務。
2、Eureka Server仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上，保證當前節點依然可用。
3、當網絡穩定時，當前Eureka Server新的註冊信息會被同步到其它節點中。
因此Eureka Server可以很好的應對因網絡故障導致部分節點失聯的情況，而不會像Zookeeper那樣如果有一半不可用的情況會導致整個集羣不可用而變成癱瘓。