一、前言

上兩節已經搭建了一個簡單的Eureka的服務註冊中心和服務提供者或者服務消費者，因為有時候服務消費者也是服務提供者，這兩者劃分沒有那麽清楚的界限。本節主要介紹一些跟Eureka相關的知識。了解它們到底有什麽特點和功能。

二、Eureka基礎知識

本節主要將Eureka分為基礎架構和服務治理兩個方向描述

2.1、基礎架構

在基礎架構中，Eureka主要分為服務註冊中心，服務提供者和服務消費者。

2.2、服務治理機制

先來看一下很基礎的服務治理機制的簡單示意圖：

根據每一個的通信行為做具體介紹：

2.2.1、服務提供者

根據上圖，服務提供的基礎功能分為：（1）服務註冊；（2）服務續約；（3）服務下線

（1）服務註冊

服務提供者在啟動的時候會通過REST請求向服務註冊中心，同時會攜帶上自己的一些元數據信息。服務註冊中心接收到註冊信息後，會將信息保存在一個雙層的MAP中，第一層的key就是服務的名稱，第二層的key是具體服務的實例。所以在服務提供者啟動時，確保對應的參數eureka.client.register-with-eureka=true,或者這個參數不配置也行，因為其默認就是true。

（2）服務續約

註冊完成以後，服務提供者會保持一個心跳給服務註冊中心，告訴服務註冊中心：”老子還活著，你不要抽風把我從服務實例給剔除了“，這個就叫做服務續約。
在服務續約中會有兩個重要的參數：
　　<1>eureka.instance.lease-renewal-interval-in-seconds

服務在運行過程中不可避免的存在重啟或者升級等問題，在服務關閉期間，不希望服務註冊中心將消費者的請求I分配到這個服務上，所以在服務正常關閉的時候，會發送一個REST的請求給註冊中心，註冊中心接受到請求以後，會把對應的服務的狀態設置為DOWN，並把下線事件傳播出去

其中最主要的就是服務註冊和續約功能。

2.2.2、服務消費者

根據上圖，服務消費者的功能主要是：（1）獲取服務；（2）服務的調用

（1）獲取服務

服務消費者啟動的時候，會向服務註冊中心發送一個REST的請求，來獲取服務註冊中心上的服務實例清單。Eureka Service 為了性能的考慮，自己維護了一個只讀屬性的緩存服務清單返回給客戶端，並且緩存服務清單默認是30秒刷新一次。
為了服務消費者能夠獲取到服務註冊中心的服務實例清單，eureka.client.fetch-registry必須設置為true，或者在配置文件中不寫，因為Eureka默認其為true。
如果希望修改 緩存服務清單的刷新時間，可以通過修改參數eureka.client.registry-fetch-interval-seconds

（2）服務的調用

服務消費者人獲取服務實例清單以後，自然是需要調用對應 服務。他是通過服務名稱來獲取服務的實例和服務相關的元數據信息，服務消費者就可以自行決定要調用哪一個服務實例。例如Ribbon就是一個典型的客戶端的負載均衡的應用。

2.2.3 、服務註冊中心

根據上圖，服務註冊中心主要特色是：（1）失效剔除；（2）自我保護機制

（1）失效剔除

有時候服務不一定是正常的下線，有很多因素導致服務不能正常工作，這個時候服務註冊中心不能接收到服務的下線通知，但是一直保持維護一個無效的服務實例，會給服務消費者造成錯覺，這個服務還在，能夠影響請求。所以為了剔除無法提供服務的實例，Eureka Service啟動的時候會啟動一個定時任務，來將一段時間沒有進行續約的服務剔除，默認是60秒會檢查一邊服務清單中超過90秒沒有續約的服務，然後將其剔除。

（2）自我保護機制

在我本本地開發測試的時候，註冊中心很容易出現一個EMERGENCY!的紅色警告，這個是因為Eureka Service有一個自我保護的機制，Eureka Service在運行期間會統計心跳失敗的比例，即是在15分鐘內，是否低於85%，如果低於這個比例，Eureka Service會將當前的實例註冊信息保護起來，讓這些實例不過期，盡量保護這些註冊信息。但是很容易造成一個問題，就是在這段保護期內，客戶端很容易再次拿到已經不能提供服務的實例，出現調用失敗的情況，所以一般要求客戶端最好有容錯機制。
可以通過參數將其自我保護機制關閉：
eureka.server.enable-self-preservation為false

SpringCloud源碼分析（一）--Eureka服務基礎知識