基礎架構

服務註冊中心：

Eureka提供的服務端，提供服務註冊與發現的功能，也就是eureka-server

服務提供者：

提供服務的應用，可以使springboot應用，也可以是其他技術平臺且遵循eureka通訊機制的應用。它將自己提供的服務註冊到Eureka,以供其他應用發現，即Hello-service應用

服務消費者：

從服務註冊中心獲取服務列表，從而使消費者可以知道去何處呼叫其所需要的服務，例如我們的例項使用了Ribbon來實現服務消費，後續會介紹Feign的消費方式。
很多時候，客戶端即是服務提供者也是服務消費者。

服務治理機制

服務提供者

服務註冊：

啟動時傳送REST請求方式註冊到註冊中心，註冊中心接收到請求後，將元資料資訊儲存在一個雙層結構Map中，第一層Key是服務名，第二層Key是例項名。
就如同我們實現的那樣：

服務同步：

如同之前的高可用註冊中心那樣，服務可以分別註冊到不同的註冊中心裡。因為此時註冊中心之間因互相註冊為服務，當服務提供者傳送註冊請求到一個服務註冊中心時，它會將該請求轉發給叢集中相連的其他註冊中心，從而實現註冊中心之間的服務同步。這樣，同一個服務就可以被多個註冊中心所維護。

服務續約：

註冊完後，服務提供者會維護一個心跳用來告訴註冊中心它還服務著，放置eureka-server的“剔除”將該服務例項從服務列表中排除出去，我們稱該操作為服務續約。
可調整相關屬性。例如：
eureka.instance.lease-renewal-interval-in-seconds=30
服務續約任務的呼叫間隔時間，預設30秒
eureka.instance.lease-expiration-duration-in-seconds=90
服務失效時間，預設90秒

服務消費者

獲取服務

此時，服務註冊中心已經註冊了一個服務，並且該服務有兩個例項。我們啟動消費者的時候，它會發送一個REST請求給服務註冊中心，獲取上面註冊的服務清單。為了效能考慮，Eureka Server會維護一份只讀的服務清單返回給客戶端，同時該快取清單會每隔30秒更新一次
獲取服務是消費者的基礎，所以必須確保eureka.client.fetch-registry=true沒有被修改成false,預設為true.
快取清單的更新時間可以修改：
eureka.client.registry-fetch-interval-seconds=30

服務呼叫

獲取清單後，通過服務名可以獲得具體提供服務的例項名和該例項的元資料資訊。因為有這些服務例項的詳細資訊，所以客戶端可以根據自己的需要決定具體呼叫哪個例項，在ribbon中會預設採用輪詢的方式進行呼叫，從而實現客戶端的負載均衡。

服務下線

當服務例項進行正常的關閉操作時，它會觸發一個服務下線的REST請求給EurekaServer,告訴服務註冊中心它要下線，服務端接受到請求後，將該服務狀態置為下線(DOWN)，並把該下線事件傳播出去。

服務註冊中心

失效剔除

有些時候，服務例項並不一定會正常下線，可能由於記憶體溢位，網路故障燈原因使得服務不能正常工作，而註冊中心並未收到服務下線的請求。為了從服務列表中將這些無法提供服務的例項剔除，EurekaServer在啟動時候會建立一個定時任務，預設每隔一段時間預設60秒將當前清單中超時（預設90秒）沒有續約的服務剔除出去。

自我保護

當我們在本地除錯基於Eureka的程式時，基本上都會碰到這樣一個問題，在服務註冊中心面板中出現類似下面的紅色警告資訊：

該警告就是出發了Eureka Server的自我保護機制。
服務註冊到Eureka Server後，會維護一個心跳連線，告訴Eureka Server自己還服務著。在註冊中心執行期間，會統計心跳失敗的比例再15分鐘之內是否低於85%，如果出現低於的情況（單機除錯的時候很容易滿足，實際在生產環境上通常是由於網路不穩定導致），Eureka
Server會將當前的例項註冊資訊保護起來，讓這些例項不會過期，儘可能保護這些註冊資訊。但是，在這段保護期間內例項若出現問題，那麼客戶端很容易拿到實際已經不存在的服務例項，會出現除錯失敗的情況，所以客戶端必須要有容錯機制，比如可以使用請求重試，斷路器等機制。
由於本地除錯很容易觸發註冊中心的保護機制，會使得註冊中心維護的服務例項不那麼準確。所以，我們在本地進行開發的時候，可以使用eureka.server.enable-self-preservation=false引數來關閉保護機制，以確保註冊中心可以將不可用的例項正確剔除。