上節內容爲大家介紹了，註冊中心 Eureka 產品的使用，以及如何利用 Eureka 搭建單臺和集羣的註冊中心。這節課我們來繼續學習 Eureka，瞭解它的相關概念、工作流程機制等。
Eureka 作爲 Spring Cloud 體系中最核心、默認的註冊中心組件，研究它的運行機制，有助於我們在工作中更好地使用它。
Eureka 核心概念
回到上節的服務註冊調用示意圖，服務提供者和服務的消費者，本質上也是 Eureka Client 角色。整體上可以分爲兩個主體：Eureka Server 和 Eureka Client。
Eureka Server：註冊中心服務端
註冊中心服務端主要對外提供了三個功能：
服務註冊
服務提供者啓動時，會通過 Eureka Client 向 Eureka Server 註冊信息，Eureka Server 會存儲該服務的信息，Eureka Server 內部有二層緩存機制來維護整個註冊表
提供註冊表
服務消費者在調用服務時，如果 Eureka Client 沒有緩存註冊表的話，會從 Eureka Server 獲取最新的註冊表
同步狀態
Eureka Client 通過註冊、心跳機制和 Eureka Server 同步當前客戶端的狀態。
Eureka Client：註冊中心客戶端
Eureka Client 是一個 Java 客戶端，用於簡化與 Eureka Server 的交互。Eureka Client 會拉取、更新和緩存 Eureka Server 中的信息。因此當所有的 Eureka Server 節點都宕掉，服務消費者依然可以使用緩存中的信息找到服務提供者，但是當服務有更改的時候會出現信息不一致。
Register: 服務註冊
服務的提供者，將自身註冊到註冊中心，服務提供者也是一個 Eureka Client。當 Eureka Client 向 Eureka Server 註冊時，它提供自身的元數據，比如 IP 地址、端口，運行狀況指示符 URL，主頁等。
Renew: 服務續約
Eureka Client 會每隔 30 秒發送一次心跳來續約。 通過續約來告知 Eureka Server 該 Eureka Client 運行正常，沒有出現問題。 默認情況下，如果 Eureka Server 在 90 秒內沒有收到 Eureka Client 的續約，Server 端會將實例從其註冊表中刪除，此時間可配置，一般情況不建議更改。
服務續約的兩個重要屬性
服務續約任務的調用間隔時間，默認爲30秒
eureka.instance.lease-renewal-interval-in-seconds=30
服務失效的時間，默認爲90秒。
eureka.instance.lease-expiration-duration-in-seconds=90
Eviction 服務剔除
當 Eureka Client 和 Eureka Server 不再有心跳時，Eureka Server 會將該服務實例從服務註冊列表中刪除，即服務剔除。
Cancel: 服務下線
Eureka Client 在程序關閉時向 Eureka Server 發送取消請求。 發送請求後，該客戶端實例信息將從 Eureka Server 的實例註冊表中刪除。該下線請求不會自動完成，它需要調用以下內容：
DiscoveryManager.getInstance().shutdownComponent()；
GetRegisty: 獲取註冊列表信息
Eureka Client 從服務器獲取註冊表信息，並將其緩存在本地。客戶端會使用該信息查找其他服務，從而進行遠程調用。該註冊列表信息定期（每30秒鐘）更新一次。每次返回註冊列表信息可能與 Eureka Client 的緩存信息不同，Eureka Client 自動處理。
如果由於某種原因導致註冊列表信息不能及時匹配，Eureka Client 則會重新獲取整個註冊表信息。 Eureka Server 緩存註冊列表信息，整個註冊表以及每個應用程序的信息進行了壓縮，壓縮內容和沒有壓縮的內容完全相同。Eureka Client 和 Eureka Server 可以使用 JSON/XML 格式進行通訊。在默認情況下 Eureka Client 使用壓縮 JSON 格式來獲取註冊列表的信息。
獲取服務是服務消費者的基礎，所以必有兩個重要參數需要注意：
# 啓用服務消費者從註冊中心拉取服務列表的功能
eureka.client.fetch-registry=true
設置服務消費者從註冊中心拉取服務列表的間隔
eureka.client.registry-fetch-interval-seconds=30
Remote Call: 遠程調用
當 Eureka Client 從註冊中心獲取到服務提供者信息後，就可以通過 Http 請求調用對應的服務；服務提供者有多個時，Eureka Client 客戶端會通過 Ribbon 自動進行負載均衡。
自我保護機制
默認情況下，如果 Eureka Server 在一定的 90s 內沒有接收到某個微服務實例的心跳，會註銷該實例。但是在微服務架構下服務之間通常都是跨進程調用，網絡通信往往會面臨着各種問題，比如微服務狀態正常，網絡分區故障，導致此實例被註銷。
固定時間內大量實例被註銷，可能會嚴重威脅整個微服務架構的可用性。爲了解決這個問題，Eureka 開發了自我保護機制，那麼什麼是自我保護機制呢？
Eureka Server 在運行期間會去統計心跳失敗比例在 15 分鐘之內是否低於 85%，如果低於 85%，Eureka Server 即會進入自我保護機制。
Eureka Server 觸發自我保護機制後，頁面會出現提示：
Eureka Server 進入自我保護機制，會出現以下幾種情況：
(1 Eureka 不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務
(2 Eureka 仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
(3 當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中
Eureka 自我保護機制是爲了防止誤殺服務而提供的一個機制。當個別客戶端出現心跳失聯時，則認爲是客戶端的問題，剔除掉客戶端；當 Eureka 捕獲到大量的心跳失敗時，則認爲可能是網絡問題，進入自我保護機制；當客戶端心跳恢復時，Eureka 會自動退出自我保護機制。
如果在保護期內剛好這個服務提供者非正常下線了，此時服務消費者就會拿到一個無效的服務實例，即會調用失敗。對於這個問題需要服務消費者端要有一些容錯機制，如重試，斷路器等。
通過在 Eureka Server 配置如下參數，開啓或者關閉保護機制，生產環境建議打開：
eureka.server.enable-self-preservation=true
- 1
Eureka 集羣原理
再來看看 Eureka 集羣的工作原理。我們假設有三臺 Eureka Server 組成的集羣，第一臺 Eureka Server 在北京機房，另外兩臺 Eureka Server 在深圳和西安機房。這樣三臺 Eureka Server 就組建成了一個跨區域的高可用集羣，只要三個地方的任意一個機房不出現問題，都不會影響整個架構的穩定性。
從圖中可以看出 Eureka Server 集羣相互之間通過 Replicate 來同步數據，相互之間不區分主節點和從節點，所有的節點都是平等的。在這種架構中，節點通過彼此互相註冊來提高可用性，每個節點需要添加一個或多個有效的 serviceUrl 指向其他節點。
如果某臺 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點。當宕機的服務器重新恢復後，Eureka 會再次將其納入到服務器集羣管理之中。當節點開始接受客戶端請求時，所有的操作都會進行節點間複製，將請求複製到其它 Eureka Server 當前所知的所有節點中。
另外 Eureka Server 的同步遵循着一個非常簡單的原則：只要有一條邊將節點連接，就可以進行信息傳播與同步。所以，如果存在多個節點，只需要將節點之間兩兩連接起來形成通路，那麼其它註冊中心都可以共享信息。每個 Eureka Server 同時也是 Eureka Client，多個 Eureka Server 之間通過 P2P 的方式完成服務註冊表的同步。
Eureka Server 集羣之間的狀態是採用異步方式同步的，所以不保證節點間的狀態一定是一致的，不過基本能保證最終狀態是一致的。
Eureka 分區
Eureka 提供了 Region 和 Zone 兩個概念來進行分區，這兩個概念均來自於亞馬遜的 AWS:
region：可以理解爲地理上的不同區域，比如亞洲地區，中國區或者深圳等等。沒有具體大小的限制。根據項目具體的情況，可以自行合理劃分 region。
zone：可以簡單理解爲 region 內的具體機房，比如說 region 劃分爲深圳，然後深圳有兩個機房，就可以在此 region 之下劃分出 zone1、zone2 兩個 zone。
上圖中的 us-east-1c、us-east-1d、us-east-1e 就代表了不同的 Zone。Zone 內的 Eureka Client 優先和 Zone 內的 Eureka Server 進行心跳同步，同樣調用端優先在 Zone 內的 Eureka Server 獲取服務列表，當 Zone 內的 Eureka Server 掛掉之後，纔會從別的 Zone 中獲取信息。
Eurka 保證 AP
Eureka Server 各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而 Eureka Client 在向某個 Eureka 註冊時，如果發現連接失敗，則會自動切換至其它節點。只要有一臺 Eureka Server 還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。
Eurka 工作流程
瞭解完 Eureka 核心概念，自我保護機制，以及集羣內的工作原理後，我們來整體梳理一下 Eureka 的工作流程：
1、Eureka Server 啓動成功，等待服務端註冊。在啓動過程中如果配置了集羣，集羣之間定時通過 Replicate 同步註冊表，每個 Eureka Server 都存在獨立完整的服務註冊表信息
2、Eureka Client 啓動時根據配置的 Eureka Server 地址去註冊中心註冊服務
3、Eureka Client 會每 30s 向 Eureka Server 發送一次心跳請求，證明客戶端服務正常
4、當 Eureka Server 90s 內沒有收到 Eureka Client 的心跳，註冊中心則認爲該節點失效，會註銷該實例
5、單位時間內 Eureka Server 統計到有大量的 Eureka Client 沒有上送心跳，則認爲可能爲網絡異常，進入自我保護機制，不再剔除沒有上送心跳的客戶端
6、當 Eureka Client 心跳請求恢復正常之後，Eureka Server 自動退出自我保護模式
7、Eureka Client 定時全量或者增量從註冊中心獲取服務註冊表，並且將獲取到的信息緩存到本地
8、服務調用時，Eureka Client 會先從本地緩存找尋調取的服務。如果獲取不到，先從註冊中心刷新註冊表，再同步到本地緩存
9、Eureka Client 獲取到目標服務器信息，發起服務調用
10、Eureka Client 程序關閉時向 Eureka Server 發送取消請求，Eureka Server 將實例從註冊表中刪除
這就是Eurka基本工作流程
總結
講了 Eureka 核心概念、Eureka 自我保護機制和 Eureka 集羣原理。通過分析 Eureka 工作原理，我可以明顯地感覺到 Eureka 的設計之巧妙，通過一些列的機制，完美地解決了註冊中心的穩定性和高可用性。
Eureka 爲了保障註冊中心的高可用性，容忍了數據的非強一致性，服務節點間的數據可能不一致， Client-Server 間的數據可能不一致。比較適合跨越多機房、對註冊中心服務可用性要求較高的使用場景。