Eureka中的核心概念

　　本文是Spring Cloud系列的第四篇，前面三篇文章(使用Spring Cloud搭建服務註冊中心、使用Spring Cloud搭建高可用服務註冊中心、Spring Cloud中服務的發現與消費)咱們帶你們搭建了服務註冊中心，向服務註冊中心註冊了服務，同時也發現和消費了服務。前面的文章咱們是以實際代碼操做爲主，這篇文章我想對前面三篇文章中涉及到的一些知識點再進行詳細的梳理，對於一些前面未涉及到的配置再作進一步的說明。
　　
　　首先，經過前面三篇文章的學習，小夥伴們已經發現了Eureka服務治理體系中涉及到三個核心概念：服務註冊中心、服務提供者以及服務消費者，本文將從這三個方面來對Eureka服務治理體系進行一個詳細的說明。
　　
　　服務提供者服務治理體系支持跨平臺，雖然咱們前文使用了Spring Boot來做爲服務提供者，可是對於其餘技術平臺只要支持通訊機制，同樣也是能夠做爲服務提供者，換句話說，服務提供者既能夠是Java寫的，也能夠是python寫的，也能夠是js寫的。這些服務提供者將本身註冊到上，供其它應用發現而後調用，這就是咱們的服務提供者，服務提供者主要有以下一些功能：服務註冊服務提供者在啓動的時候會經過發送REST請求將本身註冊到Eureka Server上，同時還攜帶了自身服務的一些元數據信息。Eureka Server在接收到這個REST請求以後，將元數據信息存儲在一個雙層結構的Map集合中，第一層的key是服務名，第二層的key是具體服務的實例名，咱們在上篇文章最後展現出來的截圖中，你們也能夠看出一些端倪，以下：同時，咱們在服務註冊時，須要確認一下eureka.client.register-with-eureka=true配置是否正確，該值默認就爲true，表示啓動註冊操做，若是設置爲false則不會啓動註冊操做。
　　
　　服務同步再說服務同步以前，我先描述一個場景：首先我有兩個服務註冊中心，地址分別是http://www.yunduanpingtai.cn  而後我還有兩個服務提供者，地址分別是http://localhost:8080和http://localhost:8081，而後我將8080這個服務提供者註冊到1111這個註冊中心上去，將8081這個服務提供者註冊到1112這個註冊中心上去，此時我在服務消費者中若是隻向1111這個註冊中心去查找服務提供者，那麼是否是隻能獲取到8080這個服務而獲取不到8081這個服務？你們看下面一張圖：答案是服務消費者能夠獲取到兩個服務提供者提供的服務。雖然兩個服務提供者的信息分別被兩個服務註冊中心所維護，可是因爲服務註冊中心之間也互相註冊爲服務，當服務提供者發送請求到一個服務註冊中心時，它會將該請求轉發給集羣中相連的其餘註冊中心，從而實現註冊中心之間的服務同步，經過服務同步，兩個服務提供者的服務信息咱們就能夠經過任意一臺註冊中心來獲取到。OK，下面咱們來經過一個簡單的案例來驗證一下咱們上面的理論：工程咱們前面已經分別建立了application-peer1.properties和application-peer2.properties配置文件，以下：而後咱們經過下面兩行命令來啓動兩個服務註冊中心實例，以下：而後咱們給provider工程也建立兩個配置文件，分別爲application-p1.properties和application-p2.properties，內容以下：而後經過以下命令啓動兩個服務提供者的實例，以下：OK,咱們將8080這個服務註冊到1111這個服務註冊中心上去了，將8081這個服務註冊到1112這個服務註冊中心上去了。當兩個服務提供者都啓動成功以後，咱們來看看兩個服務註冊中心的控制面板，以下：  、最後咱們再來看看ribbon-consumer的配置文件，以下：你們看到，咱們運行消費端時只向1111那個服務註冊中心去獲取服務列表，可是在實際運行過程當中8080和8081兩個服務提供者都有響應咱們的請求，以下圖：上面的日誌是8081打印的，下面的日誌是8080打印的，沒毛病。
　　
　　服務續約在註冊完服務以後，服務提供者會維護一個心跳來不停的告訴Eureka Server：「我還在運行」，以防止Eureka Server將該服務實例從服務列表中剔除，這個動做稱之爲服務續約，和服務續約相關的屬性有兩個，以下：第一個配置用來定義服務失效時間，默認爲90秒，第二個用來定義服務續約的間隔時間，默認爲30秒。
　　
　　服務消費者消費者主要是從服務註冊中心獲取服務列表，拿到服務提供者的列表以後，服務消費者就知道去哪裏調用它所須要的服務了，咱們從下面幾點來進一步瞭解下服務消費者。
　　
　　獲取服務當咱們啓動服務消費者的時候，它會發送一個REST請求給服務註冊中心來獲取服務註冊中心上面的服務提供者列表，而Eureka Server上則會維護一份只讀的服務清單來返回給客戶端，這個服務清單並非實時數據，而是一份緩存數據，默認30秒更新一次，若是想要修改清單更新的時間間隔，能夠經過eureka.client.registry-fetch-interval-seconds=30來修改，單位爲秒(注意這個修改是在eureka-server上來修改)。另外一方面，咱們的服務消費端要確保具備獲取服務提供者的能力，此時要確保eureka.client.fetch-registry=true這個配置爲true。
　　
　　服務調用服務消費者從服務註冊中心拿到服務提供者列表以後，經過服務名就能夠獲取具體提供服務的實例名和該實例的元數據信息，客戶端將根據這些信息來決定調用哪一個實例，咱們以前採用了Ribbon，www.rbuluoyl.cn/ Ribbon中默認採用輪詢的方式去調用服務提供者，進而實現了客戶端的負載均衡。
　　
　　服務下線服務提供者在運行的過程當中可能會發生關閉或者重啓，當服務進行正常關閉時，它會觸發一個服務下線的REST請求給Eureka Server，告訴服務註冊中心我要下線了，服務註冊中心收到請求以後，將該服務狀態置爲DOWN，表示服務已下線，並將該事件傳播出去，這樣就能夠避免服務消費者調用了一個已經下線的服務提供者了。
　　
　　服務註冊中心服務註冊中心就是Eureka提供的服務端，它提供了服務註冊與發現功能。
　　
　　失效剔除上面咱們說到了服務下線問題，正常的服務下線發生流程有一個前提那就是服務正常關閉,可是在實際運行中服務有可能沒有正常關閉，好比系統故障、網絡故障等緣由致使服務提供者非正常下線，那麼這個時候對於已經下線的服務Eureka採用了定時清除：Eureka Server在啓動的時候會建立一個定時任務，每隔60秒就去將當前服務提供者列表中超過90秒還沒續約的服務剔除出去，經過這種方式來避免服務消費者調用了一個無效的服務。
　　
　　自我保護咱們在前三篇文章中給你們看的截圖上，都有這樣一個警告，以下圖：這個警告實際上就是觸發了Eureka Server的自我保護機制。Eureka Server在運行期間會去統計心跳失敗比例在15分鐘以內是否低於85%，若是低於85%，Eureka Server會將這些實例保護起來，讓這些實例不會過時，可是在保護期內若是服務恰好這個服務提供者非正常下線了，此時服務消費者就會拿到一個無效的服務實例，此時會調用失敗，對於這個問題須要服務消費者端要有一些容錯機制，如重試，斷路器等。咱們在單機測試的時候很容易知足心跳失敗比例在15分鐘以內低於85%，這個時候就會觸發Eureka的保護機制，一旦開啓了保護機制，則服務註冊中心維護的服務實例就不是那麼準確了，此時咱們能夠使用eureka.server.enable-self-preservation=false來關閉保護機制，這樣能夠確保註冊中心中不可用的實例被及時的剔除。
　　
　　OK，以上就是咱們對Eureka www.zzktv.cn中服務註冊中心、服務提供者、服務消費者三個核心概念的一些理解，有問題歡迎留言討論。
　　
　　更多JavaEE資料請關注公衆號