Spring Cloud第三篇 | 搭建高可用Eureka註冊中心

​

​本文是Spring Cloud專欄的第三篇文章，瞭解前兩篇文章內容有助於更好的理解後面文章：

1. Spring Cloud第一篇 | Spring Cloud前言及其經常使用組件介紹概覽

2. Spring Cloud第二篇 | 使用並認識Eureka註冊中心

​

1、Eureka註冊中心高可用集羣概述

    在微服務架構的這種分佈式系統中,咱們要充分考慮各個微服務組件的高可用性問題,不能有單點故障,因爲註冊中心Eureka自己也是一個服務,若是它只有一個節點,那麼它有可能發生故障,這樣咱們就不能註冊與查詢服務了,因此咱們須要—個高可用的服務註冊中心,這就須要經過註冊中心集羣來解決。Eureka服務註冊中心它自己也是一個服務,它也能夠看作是一個提供者,又能夠看作是一個消費者,咱們以前經過配置eureka.client.register-with-eureka= false讓註冊中心不註冊本身,可是咱們能夠向其餘註冊中心註冊本身。

    Eureka server的高可用實際上就是將本身做爲服務向其餘服務註冊中心註冊本身,這樣就會造成一組互相註冊的服務註冊中心,進而實現服務清單的互相同步,往註冊中心A上註冊的服務,能夠被複制同步到註冊中心B上,因此從任何一臺註冊中心上都能查詢到已經註冊的服務,從而達到高可用的效果。

​

2、Eureka註冊中心高可用集羣搭建

    Eureka註冊中心高可用集羣就是各個註冊中心相互註冊

    一、咱們複製Eureka服務端(springcloud-eureka-server)的application.yml爲application-eureka8701.yml，application-eureka8702.yml,咱們讓8701和8702的Eureka服務相互註冊。

修改application-eureka8701.yml相應的配置以下：

spring: application: name: springcloud-eureka-server server: port: 8701 #設置該服務中心的hostname，指定ip,該實例名稱不能重複 eureka: instance: hostname: eureka8701 client: register-with-eureka: true fetch-registry: true service-url: defaultZone: http://eureka8702:8702/eureka  修改application-eureka8701.yml相應的配置以下 spring: application: name: springcloud-eureka-server server: port: 8702 #設置該服務中心的hostname，指定ip,該實例名稱不能重複 eureka: instance: hostname: eureka8702 client: register-with-eureka: true fetch-registry: true service-url: defaultZone: http://eureka8701:8701/eureka

    二、複製SpringcloudEurekaServerApplication啓動類命名爲SpringcloudEureka8701ServerApplication，SpringcloudEureka8702ServerApplication，鼠標放在啓動類上右鍵選擇如圖

​

    然在啓動類SpringcloudEureka8701ServerApplication添加-Dspring.profiles.active=eureka8701

​

同理8702啓動類操做也是同樣，此處省略。

    三、爲了讓eureka8701和eureka8702可以被正確相互訪問到，同步數據，若是不能相互訪問，Eureka服務中的數據不能同步共享，咱們須要在C:\Windows\System32\drivers\etc目錄下的hosts文件中添加兩行配置，以下:

127.0.0.1 eureka8701
127.0.0.1 eureka8702

    四、啓動兩個SpringcloudEureka8701ServerApplication，SpringcloudEureka8702ServerApplication服務咱們能夠看到註冊成功了。

​

Eureka8702也是如此，到此Eureka服務集羣搭建完畢

3、Eureka詳解

一、服務消費者模式

1-一、獲取服務

    消費者啓動的時候，使用服務別名，會發送一個rest請求到服務註冊中心獲取對應的服務信息，而後會緩存到本地jvm客戶端中，同時客戶端每隔30秒從服務器上更新一次。

    能夠經過eureka.client.registry-fetch-interval-seconds=30參數進行修改，該配置默認值爲30， 單位爲秒。

1-二、服務下線

    在系統運行過程當中必然會面臨關閉或重啓服務的某個實例的狀況，在服務關閉期間咱們天然不但願客戶端會繼續調用關閉了的實例。因此在客戶端程序中，當服務實例正常的關閉操做時，它會觸發一個服務下線的REST請求給Eureka Server, 告訴服務中心:「我要下線了」。服務端在接收到請求以後，將該服務狀態置爲下線(DOWN)，並將該下線事件傳播出去。

二、服務註冊模式

2-一、失效剔除

    有些時候，咱們的服務實例並不必定會正常下線，可能因爲內存溢出、網絡故障緣由使得服務不能正常工做，而服務註冊中心並未收到「服務下線」的請求。爲了從服務表中將這些沒法提供服務的實例剔除，Eureka Server 在啓動的時候會建立一個定時任務默認每隔一段時間(默認爲60秒eureka.server.eviction-interval-timer-in-ms=6000L)將當前清單中超時(默認爲90秒eureka.instance.lease-expiration-duration-in-seconds= 90)沒有續約的服務踢除出去

2-二、Eureka服務註冊中心自我保護機制

    當咱們在本地調試基於Eureka的程序時，基本上都會碰到這樣一個問題， 在服務主中心的信息面板中出現相似下面的紅色警告信息，在開發測試時，須要頻繁地重啓微服務實例，可是咱們不多會把eureka server一塊兒重啓（由於在開發過程當中不會修改eureka註冊中心），當一分鐘內收到的心跳數大量減小時，會觸發該保護機制。能夠在eureka管理界面看到Renews threshold和Renews(last min)，當後者（最後一分鐘收到的心跳數）小於前者（心跳閾值）的時候，觸發保護機制，會出現紅色的警告：

​

    實際上，該警告就是觸發了Eureka Server的自我保護機制，服務註冊到Eureka Server以後，會維護個心跳鏈接， 告訴Eureka Server本身還活着。Eureka Server在運行期間，會統計客戶端節點的心跳失敗的比例在15分鐘以內是否低於85%若是出現低於的狀況，若是低於85%，那就觸發自我保護機制，單機調試的時候很容易知足，實際在生產環境上一般是因爲網絡不穩定致使)，Eureka Server會將當前的實例註冊信息保護起來，讓這些實例不會過時，儘量保護這些註冊信息。可是，在這段保護期間內實例若出現問題，那麼客戶端很容易拿到實際已經不存服務實例，會出現調用失敗的狀況，因此客戶端必需要有容錯機制，好比可使用請使用重試、斷路器等機制。

    在沒有Eureka自我保護的狀況下,若是 Eureka Server在必定時間內沒有接收到某個微服務實例的心跳, Eureka Server將會註銷該實例,可是當發生網絡分區故障時,那麼微服務與 Eureka Server之間將沒法正常通訊,以上行爲可能變很是危險了，由於微服務自己實際上是正常的,此時不該該註銷這個微服務，若是沒有自我保護機制，那麼Eureka Server就會將此服務註銷掉。

    Eureka經過「自我保護模式」來解決這個問題——當 Eureka Server節點在短期內丟失過多客戶端時(可能發生了網絡分區故障),那麼就會把這個微服務節點進行保護。一旦進入自我保護模式, Eureka server就會保護服務註冊表中的信息,不刪除服務註冊表中的數據(也就是不會註銷任何微服務)。當網絡故障恢復後,該 Eureka Server節點會再自動退出自我保護模式。因此,自我保護模式是一種應對網絡異常的安全保護措施,它的架構哲學是寧肯同時保留全部微服務(健康的微服務和不健康的微服務都會保留),也不盲目註銷任何健康的微服務,使用自我保護模式,可讓Eureka集羣更加的健壯、穩定固然也可使用配置項: eureka.server.enable-self-preservation=fase禁用自我保護模式。

    可是Eureka Server自我保護模式也會給咱們帶來一些困擾,若是在保護期內某個服務提供者恰好非正常下線了,此時服務消費者就會拿到一個無效的服務實例,此時會調用失敗,對於這個問題須要服務消費者端具備一些容錯機制,如重試,斷路器等。

    Eureka的自我保護模式是有意義的,該模式被激活後,它不會從註冊列表中剔除因長時間沒收到心跳致使註冊過時的服務,而是等待修復,直到心跳恢復正常以後,它自動退出自我保護模式。這種模式旨在避免因網絡分區故障致使服務不可用的問題。

    例如,兩個微服務客戶端實例A和B之間有調用的關係,A是消費者,B是提供者,可是因爲網絡故障,B未能及時向Eureka發送心跳續約,這時候 Eureka不能簡單的將B從註冊表中剔除,由於若是剔除了,A就沒法從Eureka服務器中獲取B註冊的服務,可是這時候B服務是可用的;因此, Eureka的自我保護模式最好仍是開啓它。

2-三、關閉自我保護的相關配置以下

• 服務端配置

eureka: server: enable-self-preservation: false #eureka server清理無效節點的時間間隔，默認60000毫秒，即60秒 eviction-interval-timer-in-ms: 60000 # 單位毫秒

• 客戶端配置

# 心跳檢測檢測與續約時間，測試時將值設置設置小些，保證服務關閉後註冊中心能及時踢出服務 eureka: instance: # 每間隔1s，向服務端發送一次心跳，證實本身依然「存活」 lease-renewal-interval-in-seconds: 1 # 告訴服務端，若是我2s以內沒有給你發心跳，就表明我「死」了，請將我踢掉 lease-expiration-duration-in-seconds: 2

• 關閉自我保護模式Eureka服務端顯示以下：

​

 

案例源碼地址：https://gitee.com/coding-farmer/springcloud-learn

 

​

​