1. 程式人生 > >Spring Cloud Eureka 自我保護機制

Spring Cloud Eureka 自我保護機制

Eureka Server 在執行期間會去統計心跳失敗比例在 15 分鐘之內是否低於 85%,如果低於 85%,Eureka Server 會將這些例項保護起來,讓這些例項不會過期,但是在保護期內如果服務剛好這個服務提供者非正常下線了,此時服務消費者就會拿到一個無效的服務例項,此時會呼叫失敗,對於這個問題需要服務消費者端要有一些容錯機制,如重試,斷路器等。

我們在單機測試的時候很容易滿足心跳失敗比例在 15 分鐘之內低於 85%,這個時候就會觸發 Eureka 的保護機制,一旦開啟了保護機制,則服務註冊中心維護的服務例項就不是那麼準確了,此時我們可以使用eureka.server.enable-self-preservation=false

來關閉保護機制,這樣可以確保註冊中心中不可用的例項被及時的剔除(不推薦)。

自我保護模式被啟用的條件是:在 1 分鐘後,Renews (last min) < Renews threshold

這兩個引數的意思:

  • Renews thresholdEureka Server 期望每分鐘收到客戶端例項續約的總數
  • Renews (last min)Eureka Server 最後 1 分鐘收到客戶端例項續約的總數

具體的值,我們可以在 Eureka Server 介面可以看到:

可以看到,我們部署了 3 個 Eureka Server(自注冊模式),另外,又部署 7 個服務,註冊到 Eureka Server 叢集,引數值分別為:

  • Renews threshold:17
  • Renews (last min):20

下面說下Renews thresholdRenews threshold具體計算方式。

Renews threshold 計算程式碼:

this.expectedNumberOfRenewsPerMin = count * 2;
this.numberOfRenewsPerMinThreshold = (int) (this.expectedNumberOfRenewsPerMin * serverConfig.getRenewalPercentThreshold());

count表示服務的數量,如果 Eureka Server 開啟自注冊模式,也算一個服務,比如我們上面的示例,count

的值就是 10(3 個自注冊服務 + 7 個獨立服務),serverConfig.getRenewalPercentThreshold()預設是 0.85(可以通過eureka.server.renewal-percent-threshold配置)。

所以,根據上面的分析,我們可以計算出Renews threshold的值:(int)(10 * 2 * 0.85) = (int)17 = 17

Renews (last min)計算方式:count * 2,數值 2 表示每 30 秒 1 個心跳,每分鐘 2 個心跳的固定頻率因子,所以具體值為:10 * 2 = 20

如果在 1 分鐘後,Renews (last min) < Renews threshold,預設需等待 5 分鐘(可以通過eureka.server.wait-time-in-ms-when-sync-empty配置),即 5 分鐘後你會看到下面的提示資訊:

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

解決方式有三種:

  • 關閉自我保護模式(eureka.server.enable-self-preservation設為false),不推薦
  • 降低renewalPercentThreshold的比例(eureka.server.renewal-percent-threshold設定為0.5以下,比如0.49),不推薦
  • 部署多個 Eureka Server 並開啟其客戶端行為(eureka.client.register-with-eureka不要設為false,預設為true),推薦

Eureka 的自我保護模式是有意義的,該模式被啟用後,它不會從註冊列表中剔除因長時間沒收到心跳導致租期過期的服務,而是等待修復,直到心跳恢復正常之後,它自動退出自我保護模式。這種模式旨在避免因網路分割槽故障導致服務不可用的問題。例如,兩個客戶端例項 C1 和 C2 的連通性是良好的,但是由於網路故障,C2 未能及時向 Eureka 傳送心跳續約,這時候 Eureka 不能簡單的將 C2 從登錄檔中剔除。因為如果剔除了,C1 就無法從 Eureka 伺服器中獲取 C2 註冊的服務,但是這時候 C2 服務是可用的。

所以,Eureka 的自我保護模式最好還是開啟它。

Eureka Server 單機版配置示例:

debug: true
spring:
  application:
    name: eureka-server
logging:
  level:
    com.netflix.eureka: 'off'
    com.netflix.discovery: 'off'
server:
  port: 8100
eureka:
  instance:
    hostname: localhost
  server:
    enable-self-preservation: false #關閉自我保護機制
  client:
    register-with-eureka: false
    fetch-registry: false
    service-url:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

參考資料:

相關推薦

Spring Cloud Eureka 自我保護機制

Eureka Server 在執行期間會去統計心跳失敗比例在 15 分鐘之內是否低於 85%,如果低於 85%,Eureka Server 會將這些例項保護起來,讓這些例項不會過期,但是在保護期內如果服務剛好這個服務提供者非正常下線了,此時服務消費者就會拿到一個無效的服務例項,此時會呼叫失敗,對於這個問題需要

Spring Cloud系列教程第九篇-Eureka自我保護機制

Spring Cloud系列教程第九篇-Eureka自我保護機制 本文主要內容: 1:自我保護介紹 2:導致原因分析 3:怎麼禁止自我保護   本文是由凱哥(凱哥Java:kagejava)釋出的《spring cloud系列》教程的總第九篇: 本文是幾個維度中的第一個維度:註冊與發現維度配置中

Eureka自我保護機制

預設情況下,當eureka server在一定時間內沒有收到例項的心跳,便會把該例項從登錄檔中刪除(預設是90秒),但是,如果短時間內丟失大量的例項心跳,便會觸發eureka server的自我保護機制,比如在開發測試時,需要頻繁地重啟微服務例項,但是我們很少會把eureka

深入理解Eureka自我保護機制(五)

為什麼要有自我保護機制 眾所周知,Eureka在CAP理論當中是屬於AP , 也就說當產生網路分割槽時,Eureka保證系統的可用性,但不保證系統裡面資料的一致性, 舉個例子。當發生網路分割槽的時候,Eureka-Server和client端的通訊被終止,server端收不

spring cloud中微服務之間的調用以及eureka自我保護機制

技術 頁面 dba mapping arch 之間 tga build ng- 上篇講了spring cloud註冊中心及客戶端的註冊,所以這篇主要講一下服務和服務之間是怎樣調用的 不會搭建的小夥伴請參考我上一篇博客:idea快速搭建spring cloud-註冊中心與註冊

Spring Cloud Eureka原理分析(二):續租、下線、自我保護機制和自動清理(服務端)

續租、下線等操作比較直觀,實際上也不復雜。讓我們自己想想它們大概會在服務端有什麼操作。 renew: 更新Lease的lastUpdateTimestamp, 更新一下InstanceInfo的最新狀態。然後呼叫其他同伴節點的renew介面。 cancel:把lease從registry中移除,設

spring cloud中微服務之間的呼叫以及eureka自我保護機制

這篇主要講一下服務和服務之間是怎樣呼叫的 如果想學習Java工程化、高效能及分散式、深入淺出。微服務、Spring,MyBatis,Netty原始碼分析的朋友可以加我的Java高階交流:854630135,群裡有阿里大牛直播講解技術,以及Java大型網際網路技術的視訊免費分享給大家。 我自己搭建了一個客戶

Spring Cloud Eureka 服務關閉但是未從註冊中心刪除 自我保護機制,以及如何關閉自我保護機制的辦法

自我保護背景 首先對Eureka註冊中心需要了解的是Eureka各個節點都是平等的,沒有ZK中角色的概念, 即使N-1個節點掛掉也不會影響其他節點的正常執行。 預設情況下,如果Eureka Server在一定時間內(預設90秒)沒有接收到某個微服務例項的心跳,Eure

Spring Cloud Eureka 服務關閉但是未從註冊中心刪除 自我保護機制

背景:由於Eureka擁有自我保護機制,當其登錄檔裡服務因為網路或其他原因出現故障而關停時,Eureka不會剔除服務註冊,而是等待其修復。這是AP的一種實現。  為了讓其有精準的 CP健康檢查,可以採取讓其剔除不健康節點。 server端: eureka.server.

Spring Cloud Eureka自我保護模式與實例下線剔除

see ogg per 操作 enabled eas sse 親測 掉線 之前我說明了Eureka註冊中心的保護模式,由於在該模式下不能剔除失效節點,故按原有配置在實際中不剔除總感覺不是太好,所以深入研究了一下。當然,這裏重申一下,不管實例是否有效剔除,消費端實現Ribbo

Spring CloudEureka自我保護環境搭建

Eureka詳解   服務消費者模式   獲取服務  消費者啟動的時候,使用服務別名,會發送一個rest請求到服務註冊中心獲取對應的服務資訊,讓後會快取到本地jvm客戶端中,同時客戶端每隔30秒從伺服器上更新一次。 可以通過 fetch-inte vall-secon

Spring Cloud系列教程 | 第四篇:Eurake的自我保護機制

Eurake的自我保護機制     從CAP定理角度看,Eureka是一個AP系統,以高可用性為主,而zookeeper則是CP,以高一致性為主,所以如果使用ZK在服務發現和註冊方面,可用服務資訊雖然很及時,但是會出現不可用情形,造成無法克服的生產事故。Eure

[Spring Cloud] Eureka自我保護模式及相關問題

一、Eureka 的自我保護模式 訪問Eureka主頁時,如果看到這樣一段大紅色的句子: EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE

SpringCloud-Eureka服務註冊與發現之自我保護機制(四)

當我們進行SpringCloud微服務開發的時候,有可能會出現如下的一些紅色提示資訊。這個是Eureka的自我保護機制。 自我保護機制 :預設情況下,如果Eureka Server在一定時間內沒有接收到某個微服務例項的心跳,Eureka S

Eureka控制檯相關介紹及自我保護機制解說

一、Eureka控制檯簡介 對於Eureka大家都有所瞭解,不懂請參考:https://blog.csdn.net/forezp/article/details/81040925 1.進入Eureka控制檯首頁,首先看HOME頁的頭部 【System Stat

Netflix Eureka原始碼分析(18)——eureka server網路故障時的的自我保護機制原始碼剖析

假如說,20個服務例項,結果在1分鐘之內,只有8個服務例項保持了心跳 --> eureka server是應該將剩餘的12個沒有心跳的服務例項都摘除嗎? 這個時候很可能說的是,eureka server自己網路故障了,那些服務沒問題的。只不過eureka server

SpringCloud學習筆記三---Eureka資訊顯示問題, 自我保護機制及叢集搭建

一   Eureka整合到專案中出現的一些細節顯示問題 問題1.  註冊的服務中包含主機名稱 解決方法: 修改microservicecloud-provider-dept-8001  yml檔案中的配置,    instance:     instance-id

SpringCloud-Eaureka主機對映名稱修改、Eureka自我保護機制

                                        Eaureka主機對映名稱修改 Eaureka主機對映名稱修改 # eureka 客戶端配置 eureka: client: service-url: defa

SpringCloud之eureka詳解(自我保護機制)

1、長時間沒有訪問、檢測不到心跳,或者修改例項名稱,eureka啟動自我保護機制(好死不如賴活著-哈哈) 即:某一個時刻,某一個微服務不可用了,eureka不會立即清理,依舊會對該微服務的資訊進行儲存!!! 自我保護機制詳解: 2、eureka叢集搭建(3個eu

【一起學原始碼-微服務】Nexflix Eureka 原始碼十一:EurekaServer自我保護機制竟然有這麼多Bug?

前言 前情回顧 上一講主要講了服務下線,已經註冊中心自動感知宕機的服務。 其實上一講已經包含了很多EurekaServer自我保護的程式碼,其中還發現了1.7.x(1.9.x)包含的一些bug,但這些問題在master分支都已修復了。 服務下線會將服務例項從登錄檔中刪除,然後放入到recentQueue中,下