一、概念

1.1、什么是服務治理

Spring Cloud 封裝了 Netflix 公司開發(fā)的 Eureka 模塊來實現(xiàn)服務治理

服務治理就是提供了微服務架構(gòu)中各微服務實例的快速上線或下線且保持各服務能正常通信的能力的方案總稱。

服務治理的優(yōu)點:

1. 更高的可用性：服務治理可以支持動態(tài)的服務實例集群環(huán)境,任何服務實例可以隨時上線或下線。并且當一個服務實例不可用時,治理服務器可以將請求轉(zhuǎn)給其他服務提供者,當一個新的服務實例上線時,也能夠快速地分擔服務調(diào)用請求。
2. 負載均衡：服務治理可以提供動態(tài)的負載均衡功能,可以將所有請求動態(tài)地分布到其所管理的所有服務實例中進行處理。
3. 提升應用的彈性：服務治理的客戶端會定時從服務治理服務器中復制一份服務實例信息緩存到本地中,這樣即使當服務治理服務器不可用時,服務消費者也可以使用本地的緩存去訪問相應的服務,而不至于中斷服務。通過這種機制,極大地提高了應用的彈性。
4. 高可用性集群：可以構(gòu)建服務治理集群,通過互相注冊機制,將每個治理服務器所管轄的服務信息列表進行交換,使服務治理服務擁有更高的可用性。

1.2、 什么是Eureka

Eureak 是Netflix 開源微服務框架中一系列項目中的一個。Spring Cloud對其進行了二次封裝,形成了Spring Cloud Netflix 子項目,但未對Netflix微服務實現(xiàn)原理進行更改,只是進行了Spring Boot化,使開發(fā)者更容易使用和整合。

在Eureka中,對于服務治理有如下3個概念:

1. 服務治理服務器(Eureka服務器) ：Eureka采用了CS的設計架構(gòu)，Eureka Server 作為服務注冊功能的服務器，也就是服務注冊中心（這里的Eureka Server指的是我們自己專門寫一個Java應用來引用Eureka Server的依賴，將這個應用作為注冊中心）。而系統(tǒng)中的其他微服務，使用 Eureka的客戶端連接到 Eureka Server并維持心跳連接。這樣系統(tǒng)的維護人員就可以通過 Eureka Server 來監(jiān)控系統(tǒng)中各個微服務是否正常運行。
2. 服務注冊代理(服務提供者)：如果一個微服務是一個服務提供者，那么可以通過服務注冊代理將服務配置信息注冊到治理服務器上。服務注冊代理可以理解為一個Eureka客戶端，負責將微服務所提供的服務向Eureka服務器執(zhí)行注冊、續(xù)約和注銷等操作，以使服務消費者可以發(fā)現(xiàn)并進行消費。在服務注冊時需要向服務治理服務器提供服務名稱、宿主服務器IP地址、服務端口號、域名等主要數(shù)據(jù)。
3. 服務發(fā)現(xiàn)客戶端(服務消費者)：也是一個Eureka客戶端。它在啟動時會默認從所服務治理服務器中獲取所有的服務注冊表信息，通過所獲取到的服務注冊列表信息來消費相應的服務。

1.3、 Eureka包含兩個組件

Eureka Server提供注冊服務功能

各個微服務節(jié)點通過配置啟動后，會在EurekaServer中進行注冊，這樣EurekaServer中的服務注冊表中將會存儲所有可用服務節(jié)點的信息，服務節(jié)點的信息可以在界面中直觀看到。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

EurekaClient通過注冊中心進行訪問

EurekaClient可以分為提供者和消費者，他們都是一個Java客戶端，客戶端同時也具備一個內(nèi)置的、使用輪詢(round-robin)負載算法的負載均衡器。在應用啟動后，將會向Eureka Server發(fā)送心跳(默認周期為30秒)。如果Eureka Server在多個心跳周期內(nèi)沒有接收到某個節(jié)點的心跳，EurekaServer將會從服務注冊表中把這個服務節(jié)點移除（默認90秒）

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

1.4、 什么場景使用Eureka

準確來說是什么場景需要使用注冊中心：

大并發(fā)量的應用情況下就需要搭建集群（這里的集群指的不是Eureka注冊中心集群，而是指的微服務各個模塊的集群），搭建集群我們就需要通過注冊中心來實時掌握每個應用的情況，如果根本沒有大并發(fā)場景，項目雖然也拆分了服務，但是用不到集群，那我們大可不必使用注冊中心，使用注冊中心從某種意義上來講，增加了程序的復雜度，而且還得時刻維護注冊中心，有點大材小用了。

1.5、 Eureka停更

關(guān)于停更問題我在這篇博客已經(jīng)講的很清楚了：https://blog.csdn.net/weixin_43888891/article/details/125193088?spm=1001.2014.3001.5501

1.6、代碼要實現(xiàn)的內(nèi)容

二、單機Eureka構(gòu)建步驟

使用Eureka那就意味著一定是微服務架構(gòu)，這就涉及到了聚合工程，本篇博客的代碼完全是基于本人上一篇博客 搭建的聚合工程 來進行開發(fā)的。

idea聚合工程搭建詳解：https://blog.csdn.net/weixin_43888891/article/details

2.1、搭建Eureka Server

1、建Module：cloud-eureka-server7001

2、改pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>mscloud</artifactId><groupId>com.gzl.cn</groupId><version>1.0-SNAPSHOT</version></parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>cloud-eureka-server7001</artifactId>
    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>
    <dependencies>
        <!--eureka-server-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>
        <!-- 引入自己定義的api通用包，可以使用Payment支付Entity -->
        <dependency>
            <groupId>com.gzl.cn</groupId>
            <artifactId>cloud-api-common</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
        <!--boot web actuator-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <!--一般通用配置-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </dependency>
    </dependencies>
</project>

3、寫YML

server:
  port: 7001
eureka:
  instance:
    hostname: localhost #eureka服務端的實例名稱
  client:
    #false表示不向注冊中心注冊自己。
    register-with-eureka: false
    #false表示自己端就是注冊中心，我的職責就是維護服務實例，并不需要去檢索服務
    fetch-registry: false
    service-url:
      #設置與Eureka Server交互的地址查詢服務和注冊服務都需要依賴這個地址。
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

4、主啟動類

@SpringBootApplication
@EnableEurekaServer
public class EurekaSever7001Application {
    public static void main(String[] args) {
        SpringApplication.run(EurekaSever7001Application.class, args);
    }
}

5、啟動測試

//localhost:7001/

2.2、搭建Eureka Client端的提供者

這里我們直接接著上一篇文章中的cloud-provider-payment8001服務進行調(diào)整

1、在原有cloud-provider-payment8001服務的pom當中添加以下依賴

<!--eureka-client-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2、添加yml

eureka:
  client:
    #表示是否將自己注冊進EurekaServer默認為true。
    register-with-eureka: true
    #是否從EurekaServer抓取已有的注冊信息，默認為true。單節(jié)點無所謂，集群必須設置為true才能配合ribbon使用負載均衡
    fetchRegistry: true
    service-url:
      defaultZone: http://localhost:7001/eureka

3、啟動類添加注解

@EnableEurekaClient

4、測試

先要啟動EurekaServer確保 //localhost:7001/ 可以訪問 然后再啟動cloud-provider-payment8001

微服務注冊名配置說明：

5、自我保護機制

下面一排紅字不用管，他是Eureka的自我保護機制，在最文章后面我會具體講他的作用。

2.3、搭建Eureka Client端的消費者

這里我們直接接著上一篇文章中的cloud-provider-payment8001服務進行調(diào)整

1、在原有cloud-consumer-order80服務的pom當中添加以下依賴

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
 </dependency>

2、添加yml

eureka:
  client:
    #表示是否將自己注冊進EurekaServer默認為true。
    register-with-eureka: true
    #是否從EurekaServer抓取已有的注冊信息，默認為true。單節(jié)點無所謂，集群必須設置為true才能配合ribbon使用負載均衡
    fetchRegistry: true
    service-url:
      defaultZone: http://localhost:7001/eureka

3、啟動類添加注解

@EnableEurekaClient

4、測試

先要啟動EurekaServer, 7001服務 再啟動服務提供者provider, 8001服務 最后啟動服務消費者consumer，80服務 訪問：//localhost/consumer/payment/get/1

三、Eureka集群

通過上面的練習，我們會發(fā)現(xiàn)根本沒體會到Eureka作用是什么，沒有Eureka服務照樣可以運行使用，這也就是上面提到的，假如微服務不使用集群的話，完全沒必要使用注冊中心。下面我們進行分別搭建Eureka集群，和微服務集群。

3.1、Eureka集群原理說明

微服務RPC遠程服務調(diào)用最核心的是什么

高可用，試想你的注冊中心只有一個only one， 它出故障了那就呵呵(￣▽￣)"了，會導致整個為服務環(huán)境不可用，所以需要搭建Eureka集群

3.2、EurekaServer集群環(huán)境構(gòu)建步驟

1、參考cloud-eureka-server7001 新建 cloud-eureka-server7002（直接復制就行）

2、改pom

3、父工程的pom當中添加model

正常通過ide創(chuàng)建，他是會自動在父工程添加model的，而我們是復制的所以需要手動添加

4、修改啟動名字：EurekaSever7002Application

5、修改映射配置

添加：

127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com

6、修改yml（7001和7002都需要修改），由于7002是直接復制的，所以7002的yml端口號需要改成7002

7002主要是修改端口和hostname，,7001的yml當中的hostname修改為eureka7001.com

server:
  port: 7002
eureka:
  instance:
    hostname: eureka7002.com #eureka服務端的實例名稱

7、將 支付服務8001微服務 和 訂單服務80微服務 發(fā)布到上面2臺Eureka集群配置中（兩個服務都需要修改yml）

http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka

8、測試

先要啟動EurekaServer, 7001/7002服務 //eureka7001.com:7001/ 再要啟動服務提供者provider, 8001 再要啟動消費者,80 訪問：//localhost/consumer/payment/get/1

3.3、支付服務提供者8001集群環(huán)境構(gòu)建

1、參考cloud-provider-payment8001 新建 cloud-provider-payment8002（直接復制就行） 2、改pom

3、父工程的pom當中添加model

4、修改啟動名字：PaymentMain8002 5、修改yml（主要就是修改端口號為8002） 6、修改8001/8002的Controller

主要是方便區(qū)分我們調(diào)用的是哪個服務

3.4、調(diào)整80消費服務

1、訂單服務訪問地址不能寫死

// 通過在eureka上注冊過的微服務名稱調(diào)用
public static final String PaymentSrv_URL = "http://CLOUD-PAYMENT-SERVICE";

2、使用@LoadBalanced注解賦予RestTemplate負載均衡的能力

spring-cloud-starter-netflix-eureka-client依賴當中就依賴了ribbon依賴，所以我們不用添加ribbon依賴就能使用他的注解。

一旦地址改為以服務名稱訪問的形式"//CLOUD-PAYMENT-SERVICE"，就必須添加這個負載均衡的注解，不然訪問80服務的接口就會報錯。

3、測試

先要啟動EurekaServer, 7001/7002服務再要啟動服務提供者provider, 8001/8002服務然后最后啟動80服務訪問：//localhost/consumer/payment/get/31 多次訪問這個接口，返回的日志當中的端口號會交替出現(xiàn)，這就是負載均衡。當服務提供者8001和8002任意一個掛掉之后，并不會影響服務調(diào)用。Ribbon和Eureka整合后Consumer可以直接調(diào)用服務而不用再關(guān)心地址和端口號,且該服務還有負載功能了。

3.5、Eureka集群嚴重問題

在測試過程發(fā)現(xiàn)的問題，所以記錄一下！

訪問：//eureka7001.com:7001/

訪問：//eureka7002.com:7002/

這時候會發(fā)現(xiàn)所有服務全注冊到了7001，而7002實際上并沒有服務，當我們把7001服務關(guān)閉后，會發(fā)現(xiàn)過一段時間服務自動就注冊到了7002，可能需要個幾秒，這幾秒的過程當中如果調(diào)用服務是會報錯的！

為什么會都優(yōu)先注冊到7001而不是7002呢？跟配置文件寫的順序有關(guān)！

假設7001注冊中心掛掉的同時8001服務也掛掉了，然后先恢復7001服務，然后再恢復8001服務。這時候會出現(xiàn)以下情況。8001注冊到了7001注冊中心，而其他沒有掛掉的服務，由于7001掛掉了之后注冊在7001的服務全部轉(zhuǎn)移到了7002注冊中心。

這個時候會引發(fā)一個非常嚴重的問題，就是服務提供者的集群失效！

多次訪問80服務的接口，會發(fā)現(xiàn)一直是調(diào)用的8002服務，他不會去調(diào)用8001，因為80服務注冊在了7002注冊中心，而8001注冊在了7001注冊中心，服務都不在一個注冊中心，所以他根本調(diào)用不了。

解決辦法： 假如注冊中心和一個服務掛掉之后，一定要先想辦法先恢復服務，而不是先恢復掛掉的注冊中心！先恢復8001服務的話，他會直接注冊到7002注冊中心，就完全避免了這樣的問題。當然這里啟動8001服務的時候會報錯但是不影響的，因為他啟動的時候會先去注冊到7001，然后發(fā)現(xiàn)7001掛掉了這時候會報錯，然后自動注冊到7002。

從這個問題也間接的會發(fā)現(xiàn)，微服務框架當中，有時候程序啟動的先后順序至關(guān)重要！

3.6、主機名稱修改 和 ip提示

1、主機名稱修改

這里一個是應用名稱，一個是主機名稱

2、ip提示

當我們服務多了，有時候以應用名稱根本無法快速鎖定他在哪臺服務器部署，所以可以添加以下配置。

3.7、服務發(fā)現(xiàn)Discovery

對于注冊進eureka里面的微服務,可以通過服務發(fā)現(xiàn)來獲得該服務的信息

在8001的PaymentController添加一個接口：

DiscoveryClient 導包的時候?qū)旅娴陌?/p>

import org.springframework.cloud.client.discovery.DiscoveryClient;

@Resource
private DiscoveryClient discoveryClient;
@GetMapping(value = "/payment/discovery")
public Object discovery() {
    // 獲取注冊的服務
    List<String> services = discoveryClient.getServices();
    for (String element : services) {
        System.out.println(element);
    }
    // 根據(jù)服務名稱獲取服務詳細信息
    List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
    for (ServiceInstance element : instances) {
        System.out.println(element.getServiceId() + "\t" + element.getHost() + "\t" + element.getPort() + "\t"
                + element.getUri());
    }
    return this.discoveryClient;
}

測試：//localhost:8001/payment/discovery 訪問后看控制臺輸出內(nèi)容！

四、Eureka心跳機制

4.1、什么是心跳機制

在了解保護機制之前，我們有必要先了解一下Eureka的心跳機制。

使用注冊中心，那我們的服務信息就需要注冊到注冊中心，注冊中心起到的作用是服務治理，那他就需要時刻掌握服務是否宕機，心跳機制就是Eureka client一旦注冊到注冊中心后，就需要每隔一段時間告訴Eureka server一下，我還是活的。

4.2、Eureka Client心跳頻率配置

在每一個Eureka Client啟動的時候，都會有一個HeartbeatThread的心跳線程，這個線程的作用就是保證默認30秒的時候向Eureka Server發(fā)送一個信息的請求，告訴Eureka Server當前的Eureka Client還存活著。

下面這個參數(shù)可以來配置心跳間隔時間（這個是在Eureka的client端配置的）：

eureka:
  instance:
    lease-renewal-interval-in-seconds: 30

4.3、Eureka Server端接收到心跳做了什么操作

Eureka Server在接收到請求之后，肯定是先去自己的注冊表中去，找到請求的對應的服務信息，在這個服務信息里面有個Lease的對象，這個里面就是可以進行心跳續(xù)約操作的，更新Lease對象里面的LastUpdateTimestamp時間戳，每一次接收到都會更新這個時間戳的。

4.4、Eureka Server查看心跳是否收到

Eureka Server在啟動的時候啟動的時候會每60秒遍歷一次注冊表中的信息，然后查看注冊表中的信息是否有過期的，如果過期會加入到一個列表里面單獨處理。

清理間隔時間配置（單位毫秒，默認是60*1000，在Eureka的server端配置的）：

eureka:
  server:
    eviction-interval-timer-in-ms: 60

4.5、Eureka Client心跳最大等待時間

Eureka服務端在收到最后一次心跳后等待時間上限，單位為秒(默認是90秒)，超時將剔除服務。 通過下面可以配置等待時間（這個是在Eureka的client端配置的）：

eureka:
  instance:
    lease-expiration-duration-in-seconds: 90

4.6、總結(jié)

通過以上了解，我們一共接觸了三個時間配置，一個是注冊中心的掃描過期時間，掃描過期時間就好比，租車公司要定期查看哪些車租聘日到期了，需要進行收回。還有一個客戶端設置的 租期更新時間間隔，這個時間就是租戶需要隔一段時間告訴租聘公司，我還要繼續(xù)租這個車，還有一個是租期到期時間，這個時間就是假如客戶端超過這個時間沒有給租聘公司發(fā)送心跳，那么就認為不租了。

server端:
eureka.server.eviction-interval-timer-in-ms//清理間隔（單位毫秒，默認是60*1000）
client端：
eureka.instance.lease-renewal-interval-in-seconds =10//租期更新時間間隔（默認30秒）
eureka.instance.lease-expiration-duration-in-seconds =30//租期到期時間（默認90秒）

五、Eureka自我保護機制

首先明確觀點：Eureka自我保護機制有很多bug，而且中文資料很缺乏，網(wǎng)上普遍是一篇博客抄來抄去的，本人通過案例也確實發(fā)現(xiàn)很多bug的地方，如果鉆牛角尖的話，可能幾天都學不完！

5.1、什么是自我保護機制

保護模式主要用于一組客戶端和Eureka Server之間存在網(wǎng)絡分區(qū)場景下的保護。為了防止EurekaClient可以正常運行，但是 與 EurekaServer網(wǎng)絡不暢通情況下（網(wǎng)絡延遲等原因），在保護模式開啟的情況下，EurekaServer不會立刻將EurekaClient服務剔除。

如果在Eureka Server的首頁看到以下這段提示，則說明Eureka進入了保護模式：

這個需要在注冊中心配置的！

server:
    #關(guān)閉自我保護機制，保證不可用服務被及時踢除，默認為true開啟的
       enable-self-preservation: false

5.2、為什么會出現(xiàn)自我保護機制

一句話：某時刻某一個微服務因為網(wǎng)絡原因不可用了,Eureka不會立刻清理,依舊會對該微服務的信息進行保存，屬于CAP里面的AP分支。

因為網(wǎng)絡通信是可能恢復的，但是Eureka客戶端只會在啟動時才去服務端注冊。如果因為網(wǎng)絡的原因而剔除了客戶端，將造成客戶端無法再注冊到服務端。為了避免此問題，Eureka提供了自我保護機制。

CAP即：

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance（分區(qū)容忍性）

清理條件：

1. Eureka服務端會檢查最近15分鐘內(nèi)所有Eureka 實例正常心跳占比（這個15分鐘是在源碼當中有個每15分鐘執(zhí)行一次的定時任務），如果低于85%就會觸發(fā)自我保護機制。
2. 觸發(fā)了保護機制，Eureka將暫時把這些失效的服務保護起來，不讓其過期，但這些服務也并不是永遠不會過期（該現(xiàn)象可能出現(xiàn)在如果網(wǎng)絡不通但是EurekaClient未出現(xiàn)巖機）。
3. Eureka在啟動完成后，每隔60秒會檢查一次服務健康狀態(tài)（這個60秒就是上面提到的Eureka Server查看心跳是否收到默認的配置）
4. 如果這些被保護起來失效的服務過一段時間后（默認90秒，這個90秒就是上面提到的心跳最大等待時間）還是沒有恢復，就會把這些服務剔除。如果在此期間服務恢復了并且實例心跳占比高于85%時，就會自動關(guān)閉自我保護機制。
5. 此時如果換做別的注冊中心如果一定時間內(nèi)沒有收到心跳會將剔除該服務，這樣就出現(xiàn)了嚴重失誤，因為客戶端還能正常發(fā)送心跳，只是網(wǎng)絡延遲問題，而保護機制是為了解決此問題而產(chǎn)生的。它的設計哲學就是寧可保留錯誤的服務注冊信息，也不盲目注銷任何可能健康的服務實例。一句話講解：好死不如賴活著

綜上，自我保護模式是一種應對網(wǎng)絡異常的安全保護措施。它的架構(gòu)哲學是寧可同時保留所有微服務（健康的微服務和不健康的微服務都會保留）也不盲目注銷任何健康的微服務。使用自我保護模式，可以讓Eureka集群更加的健壯、穩(wěn)定。

5.3、如何選擇關(guān)閉還是開啟自我保護機制

Eureka服務端默認情況下是會開啟自我保護機制的。但我們在不同環(huán)境應該選擇是否開啟保護機制。

自我保護機制的配置是（默認是開啟的）：eureka.server.enable-self-preservation=true

一般情況下，我們會選擇在 開發(fā)環(huán)境下關(guān)閉自我保護機制，而在生產(chǎn)環(huán)境下啟動自我保護機制。

開發(fā)環(huán)境下，我們我們啟動的服務數(shù)量較少而且會經(jīng)常修改重啟。如果開啟自我保護機制，很容易觸發(fā)Eureka客戶端心跳占比低于85%的情況。使得Eureka不會剔除我們的服務，從而在我們訪問的時候，會訪問到可能已經(jīng)失效的服務，導致請求失敗，影響我們的開發(fā)。

在生產(chǎn)環(huán)境下，我們啟動的服務多且不會反復啟動修改。環(huán)境也相對穩(wěn)定，影響服務正常運行的人為情況較少。適合開啟自我保護機制，讓Eureka進行管理。

5.4、Eureka控制臺參數(shù)

如下我啟動了3個服務：

Lease expiration enabled：Eureka自動保護機制啟動后該值為false。

Renews threshold：Eureka Server 期望每分鐘收到客戶端實例續(xù)約的閱值。

Renews threshold = 服務實例總數(shù) *（60/續(xù)約間隔）*自我保護續(xù)約百分比閾值因子（閾值因子默認85%，續(xù)約間隔默認是30）。

Renews (last min)： Eureka Server 最后1分鐘收到客戶端實例續(xù)約的總數(shù)。

Renews（last min) = 服務實例總數(shù) * (60/續(xù)約間隔）

如果自我保護模式開啟了，且當續(xù)約閾值>0，上一分鐘的續(xù)約數(shù)>閾值，那么可以清理。言外之意就是，當上一分鐘續(xù)約數(shù)<閾值，那么就不清理（保護了）（Renews (last min) < Renews threshold）

5.5、測試開啟了自我保護機制

什么都沒配置，只是啟動了三個服務，然后等了一會就進入保護模式了。對于這一點我也不是很理解。進入保護模式后，我隨便關(guān)掉了一個服務，Eureka控制臺上也就幾秒鐘立馬就消失了，并沒有向上面所說的，進入保護模式后，不會輕易移除服務！

我開啟了自我保護機制，并且給每個要注冊的服務設置如下配置：

eureka:
  instance:
    #Eureka服務端在收到最后一次心跳后等待時間上限，單位為秒(默認是90秒)，超時將剔除服務
    lease-expiration-duration-in-seconds: 2
    #Eureka客戶端向服務端發(fā)送心跳的時間間隔,單位為秒(默認是30秒)
    lease-renewal-interval-in-seconds: 1

注意要觀察Renews (last min)和Renews threshold值的時候，啟動項目后一定要等個1分鐘才可以，等一分鐘過后如下：

Renews threshold完全跟上面提到的算法是不一致的，而且差距還很大，而Renews (last min)卻差距不是很大。針對于此問題，我也搜了很多相關(guān)資料，由于Eureka已經(jīng)停更，很多人已經(jīng)棄用，并沒有太多的人關(guān)注這個問題了。

當我關(guān)閉8001服務的時候，Eureka上的8001服務并沒有立馬消失，而是停留了幾秒鐘，狀態(tài)顯示的是DOWN。

5.6、關(guān)閉自我保護機制

eureka:
  server:
    enable-self-preservation: false

關(guān)閉后，啟動注冊中心就會看到以下字樣！

六、Eureka健康檢查

由于server和client通過心跳保持服務狀態(tài)，而只有狀態(tài)為UP的服務才能被訪問 看eureka界面中的status

比如心跳一直正常，服務一直UP，但是此服務DB連不上了，無法正常提供服務

我們需要將微服務的健康狀態(tài)也同步到server只需要啟動eureka的健康檢查這樣微服務就會將自己的健康狀態(tài)同步到eureka

這個需要在Eureka client端設置，而且默認就是開啟的。

eureka:
  client:
    healthcheck:
      enabled: true

剛開始我以為是只要這個設置true，然后當服務的mysql掛掉后，會自動更新注冊中心的狀態(tài)，然后可以避免其他服務調(diào)用異常的服務，然而并不是，他還需要配置很多東西，并沒有我想象的那么神奇！

到此這篇關(guān)于關(guān)于Eureka的概念作用以及用法詳解的文章就介紹到這了,更多相關(guān)Eureka概念作用以及用法內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論