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

1、前言

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

2、Eureka基礎知識

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

2.一、基礎架構

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

2.二、服務治理機制

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

根據每個的通訊行爲作具體介紹：

2.2.一、服務提供者

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

（1）服務註冊

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

（2）服務續約

註冊完成之後，服務提供者會保持一個心跳給服務註冊中心，告訴服務註冊中心：」老子還活着，你不要抽風把我從服務實例給剔除了「，這個就叫作服務續約。
在服務續約中會有兩個重要的參數：
　　<1>eureka.instance.lease-renewal-interval-in-seconds
這個是表示服務提供者向服務註冊中心續約的時間間隔，默認是30秒
　　<2>eureka.instance.lease-expiration-duration-in-seconds
這個是服務過時的時間，默認是90秒
（3）服務下線

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

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

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