SpringCloud Eureka服務治理機制

1、基礎架構

        構建Eureka服務治理有三個核心角色：服務註冊中心、服務提供者和服務消費者。上圖就是這三個角色之間的通訊工做架構圖。

• 服務註冊中心（Eureka Server）：Eureka提供的服務端，提供服務註冊和發現的功能；
• 服務提供者：提供服務的應用，遵循Eureka通訊機制的應用。它將本身註冊到Eureka Server中，以供其餘應用發現；
• 服務消費者：消費者應用從服務註冊中心獲取服務列表，從而讓消費者知道能夠從哪一個服務提供者調用其所需的服務；

2、各核心要素

        在高可用的集羣中，都會建立兩個或兩個以上的服務註冊中心，他們之間進行相互註冊，使得各自所管理的服務列表在各個註冊中心進行信息同步。

服務註冊中心

一、失效剔除

        有時候服務實例異常（內存溢出、網絡故障等）下線， 此時服務註冊中心並無收到「服務下線」的請求，爲了從列表中將這些沒法提供服務的實例剔除，Eureka Server在啓動時會建立一個定時任務，默認每隔一段時間（默認爲60秒），將當前清單中超時（默認90秒）沒有續約的服務剔除出去。

二、自我保護

        Eureka Server在 運行期間，會統計心跳失敗的比例在15分鐘以內是否低於85%，若是是，Eureka Server就會將當前實例註冊信息保護起來，讓這些實例不會過時。在單機的狀況之下容易觸發自我保護機制。當觸發自我保護機制時，Spring Eureka面板頁面出現下面狀況：

默認狀況下，是會開啓自我保護機制，能夠經過設置參數關閉，但通常狀況都是要開啓的。

服務提供者

一、服務註冊

        「服務提供者」在啓動時，會經過發送REST請求的方式將本身註冊到Eureka Server上，同時帶上自身服務的一些元數據信息。Eureka Server接收到REST請求後，將元數據信息存儲到一個雙層結構Map中，第一層的key是服務名，第二層key是具體的服務實例名，以下：

        架構圖中，有兩個服務提供者實例，分別註冊到兩個不一樣的服務註冊中心，即它們的信息分別被兩個不一樣的服務註冊中心所維護，由於服務註冊中心之間實現了同步（即當一個服務提供者發送註冊請求到一個服務註冊中心時，它就會將請求轉發到集羣中的與之相連的服務註冊中心），因此經過這兩臺服務註冊中心的任意一臺均可以獲取該服務提供者的信息（服務列表）。

二、服務續約

        註冊完成以後，服務提供者還會維護一個心跳，告訴Eureka Server：「我還活着」，以防止被Eureka Server剔除。默認狀況下，續約任務間隔爲30秒，服務失效的時間爲90秒，能夠經過配置文件設置時間。

服務消費者

一、獲取服務列表

        若是如今有兩個服務註冊中心，並且有兩個服務提供者實例（如架構圖），當啓動一個服務消費者的時候，首先，它會發送REST請求，獲取由服務註冊中心返回的服務列表信息，爲了性能考慮，Eureka Server會維護一份只讀服務清單返回給客戶端，同時每30秒更新一次清單列表。

二、服務調用

        服務消費者獲取到服務清單後，經過服務名能夠獲取提供服務的實例名和該實例的元數據信息。由於有這些服務實例的詳細信息，因此客戶端能夠根據本身的須要決定具體調用哪一個實例，在Ribbon中，會默認採用輪詢的方式進行調用，從而實現客戶端的負載均衡。

        Eureka中有Region和Zone兩個概念，一個Region中能夠包括多個Zone，每一個服務客戶端須要被註冊到一個Zone中，因此客戶端對應一個Region和一個Zone。在進行服務調用的時候，優先訪問同處一個Zone中的服務提供方，若訪問不到，則訪問其餘Zone。