服務治理機制
我們來進一步了解一下Eureka 基礎架構中各個元素的一些通信行為， 以此來了解基于Eureka 實作的服務治理體系是如何運作起來的。以下圖為例， 其中有這樣幾個重要元素：
• "服務注冊中心-1" 和“ 服務注冊中心-2", 它們互相注冊組成了高可用叢集。
• "服務提供者” 啟動了兩個執行個體， 一個注冊到“ 服務注冊中心-1" 上， 另外一個注冊到“ 服務注冊中心-2" 上。
• 還有兩個“ 服務消費者“， 它們也都分别隻指向了一個注冊中心。
一、服務提供者
1.服務注冊
“服務提供者” 在啟動的時候會通過發送REST請求的方式将自己注冊到Eureka Server上， 同時帶上了自身服務的一些中繼資料資訊。Eureka Server接收到這個REST請求之後，将中繼資料資訊存儲在一個雙層結構Map中， 其中第一層的key是服務名， 第二層的key是具體服務的執行個體名。（我們可以回想一下之前在實作Ribbon負載均衡的例子中， Eureka資訊面闆中一個服務有多個執行個體的清況， 這些内容就是以這樣的雙層Map形式存儲的。）
在服務注冊時， 需要确認一下eureka.cli ent.register-with-eureka=true參數是否正确， 該值預設為true。若設定為false将不會啟動注冊操作。
2.服務同步
如架構圖中所示， 這裡的兩個服務提供者分别注冊到了兩個不同的服務注冊中心上，也就是說， 它們的資訊分别被兩個服務注冊中心所維護。此時， 由于服務注冊中心之間因互相注冊為服務， 當服務提供者發送注冊請求到一個服務注冊中心時， 它會将該請求轉發給叢集中相連的其他注冊中心， 進而實作注冊中心之間的服務同步。通過服務同步，兩個服務提供者的服務資訊就可以通過這兩台服務注冊中心中的任意一台擷取到。
3.服務續約
在注冊完服務之後，服務提供者會維護一個心跳用來持續告訴EurekaServer: "我還活着”， 以防止Eureka Server 的“ 剔除任務” 将該服務執行個體從服務清單中排除出去， 我們稱該操作為服務續約(Renew)。
關于服務續約有兩個重要屬性，我們可以關注并根據需要來進行調整：
eureka.instance.lease-renewal-interval-in-seconds=30
eureka.instance.lease-expiration-duration-in-seconds=90
eureka.instance.lease-renewal-interval-in-seconds 參數用于定義服務續約任務的調用間隔時間，預設為30秒。
eureka.instance.lease-expiration-duration-in-seconds參數用于定義服務失效的時間，預設為90秒。
二、服務消費者
1.擷取服務
到這裡， 在服務注冊中心已經注冊了一個服務， 并且該服務有兩個執行個體。當我們啟動服務消費者的時候， 它會發送一個REST請求給服務注冊中心，來擷取上面注冊的服務清單。為了性能考慮， Eureka Server會維護一份隻讀的服務清單來傳回給用戶端，同時該緩存清單會每隔30秒更新一次。
擷取服務是服務消費者的基礎，是以必須確定eureka.client.fetch-registry=true參數沒有被修改成false, 該值預設為true。若希望修改緩存清單的更新時間，可以通過eureka.client.registry-fetch-interval-seconds=30參數進行修改，該參數預設值為30, 機關為秒。
2.服務調用
服務消費者在擷取服務清單後，通過服務名可以獲得具體提供服務的執行個體名和該執行個體的中繼資料資訊。因為有這些服務執行個體的詳細資訊， 是以用戶端可以根據自己的需要決定具體調用哪個執行個體，在ribbon中會預設采用輪詢的方式進行調用，進而實作用戶端的負載均衡。
對于通路執行個體的選擇，Eureka中有Region和Zone的概念， 一個Region中可以包含多個Zone, 每個服務用戶端需要被注冊到一個Zone中， 是以每個用戶端對應一個Region和一個Zone。在進行服務調用的時候， 優先通路同處一個Zone 中的服務提供方， 若通路不到，就通路其他的Zone。
3.服務下線
在系統運作過程中必然會面臨關閉或重新開機服務的某個執行個體的情況， 在服務關閉期間，我們自然不希望用戶端會繼續調用關閉了的執行個體。是以在用戶端程式中， 當服務執行個體進行正常的關閉操作時， 它會觸發一個服務下線的REST請求給Eureka Server, 告訴服務注冊中心：“我要下線了”。服務端在接收到請求之後， 将該服務狀态置為下線(DOWN), 并把該下線事件傳播出去。
三、服務注冊中心
1.失效剔除
有些時候， 我們的服務執行個體并不一定會正常下線， 可能由于記憶體溢出、網絡故障等原因使得服務不能正常工作， 而服務注冊中心并未收到“服務下線” 的請求。為了從服務清單中将這些無法提供服務的執行個體剔除， Eureka Server在啟動的時候會建立一個定時任務，預設每隔一段時間（預設為60秒） 将目前清單中逾時（預設為90秒）沒有續約的服務剔除出去。
2.自我保護
當我們在本地調試基于Eureka的程式時， 基本上都會碰到這樣一個問題， 在服務注冊中心的資訊面闆中出現類似下面的紅色警告資訊：
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT.RENEWALS ARE LESSER TH邸THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPI邸D JUST TO BE SAFE.
實際上， 該警告就是觸發了EurekaServer的自我保護機制。之前我們介紹過， 服務注冊到EurekaServer之後，會維護一個心跳連接配接，告訴EurekaServer自己還活着。EurekaServer在運作期間，會統計心跳失敗的比例在15分鐘之内是否低于85%, 如果出現低于的情況（在單機調試的時候很容易滿足， 實際在生産環境上通常是由于網絡不穩定導緻）， Eureka Server會将目前的執行個體注冊資訊保護起來， 讓這些執行個體不會過期， 盡可能保護這些注冊資訊。但是， 在這段保護期間内執行個體若出現問題， 那麼用戶端很容易拿到實際已經不存在的服務執行個體， 會出現調用失敗的清況， 是以用戶端必須要有容錯機制， 比如可以使用請求重試、斷路器等機制。
由于本地調試很容易觸發注冊中心的保護機制， 這會使得注冊中心維護的服務執行個體不那麼準确。是以， 我們在本地進行開發的時候， 可以使用eureka.server.enableself-preservation=false 參數來關閉保護機制， 以確定注冊中心可以将不可用的執行個體正确剔除。
Eureka常用配置
1.Eureka服務監控
添加依賴
注意：服務端已經存在該依賴，可以不用添加。
注意：
1、 服務監控依賴于 spring-boot-starter-actuator 這個 jar
2、 注意 management.context-path 的定義
3、 注意 server.servlet-path 的定義
4、 可以直接定義 eureka.instance.status-page-url=http://www.roncoo.com，這個優先級高
2.Eureka用戶端的常用配置
3.Eureka服務端的常用配置
Eureka服務認證
1.指定注冊中心
在配置檔案中指定注冊中心，主要通過eureka.client.serviceUrl 參數實作。該參數的定義如下所示，它的配置值存儲在HashMap 類型中，并且設定有一組預設值， 預設值的key 為defaultZone、value 為http://localhost:8761/eureka/。
是以我們做了如下配置， 來将應用注冊到對應的Eureka 服務端中。
當建構了高可用的服務注冊中心叢集時， 我們可以為參數的value 值配置多個注冊中心的位址（通過逗号分隔）。比如下面的例子：
另外， 為了服務注冊中心的安全考慮， 很多時候我們都會為服務注冊中心加入安全校驗。這個時候，在配置serviceUrl 時， 需要在value 值的URL 中加入相應的安全校驗資訊， 比如http://<username>:<password>@localhost:1111/eureka。其中，<username>為安全校驗資訊的使用者名， <password>為該使用者的密碼。
2.服務認證
1、服務端添加依賴
2、服務端添加配置
3、修改服務端和用戶端的配置
建議：能在内網的，盡量在内網，這樣既可以保障安全，也能降低複雜度。
Eureka高可用叢集配置
說明：啟動3個注冊中心，我們将cloudtest1、cloudtest2、cloudtest3 各自都将serviceUrl 指向另外兩個節點，即是 cloudtest1、cloudtest2、cloudtest3 是兩兩互相注冊的。
步驟：
1、設定 hosts：C:\Windows\System32\drivers\etc\hosts;
2、修改配置
每個服務都需要相應的修改，服務-01
同理：服務-02，服務-03 都做相對應的修改
3、配置修改
聲明："服務治理機制"這部分是截取《springcloud微服務實戰（翟永超）》，我本人覺得他講解的很到位，也很容易了解；至于常用配置、服務認證、高可用注冊是經過實踐總結的。