運行階段執行健康檢查的目的是為了從Eureka服務器注冊表中識別并刪除不可訪問的微服務，Eureka?服務器并不是向客戶端發送心跳請求，而是反過來，Eureka?客戶端將心跳發送到Eureka服務器，讓服務器了解其狀態。

這些心跳機制就需要在微服務嵌入一個客戶端，用來發送心跳，但是客戶端本身必須確定其健康狀態，而且Eureka服務器必須為客戶端公開一些REST操作以讓其發布心跳。

Eureka服務器向客戶端公開下面資源以讓其發送心跳：

PUT /eureka/apps/{app id}/{instance id}?status={status}

{instance id}采用 ?hostname:app id:port，其中app id代表標識唯一的Eureka客戶端實例，Eureka服務器會識別一些狀態數值：UP; DOWN; STARTING; OUT_OF_SERVICE; UNKNOWN.

客戶端發送心跳時的URL如下：

PUT /eureka/apps/ORDER-SERVICE/localhost:order-service:8886?status=UP

Eureka服務器收到心跳請求后，會續訂該實例的租約。如果是第一個心跳，則Eureka服務器以404響應，之后客戶端必須首先發送注冊請求。

此外，?Eureka服務器公開以下操作以允許健康狀態的修改和刪除：

PUT /eureka/apps/{app id}/{instance id}/status?value={status}

DELETE /eureka/apps/{app id}/{instance id}/status

修改操作(即PUT上面的操作)是用于手動獲取健康的實例OUT_OF_SERVICE時操作，或者使用Asgard等管理工具?(暫時禁止某些實例的流量)時操作。

這種修改操作對于“紅/黑”部署非常有用，在這種情況下，你可以在一段時間內運行較舊版本的微服務(如果新版本不穩定，則可以輕松回滾到舊版本)。完成新版本的部署并且新版本開始為請求提供服務后，可以讓舊版本OUT_OF_SERVICE(但不會讓他們停止)暫停提供請求服務。即

PUT /eureka/apps/ORDER-SERVICE/localhost:order-service:8886/statusvalue=OUT_OF_SERVICE

上面修改的狀態也可以被丟棄，我們可以指示讓Eureka服務器開始遵守實例本身發布的狀態，如下所示：

DELETE /eureka/apps/ORDER-SERVICE/localhost:order-service:8886/status

當您發現微服務的新版本不穩定并且您希望獲得舊版本(即已經被打上OUT_OF_SERVICE標記的版本)以開始提供請求時，上述辦法非常有用。

Eureka的健康檢查

客戶端需要在工程中添加組件依賴:

org.springframework.boot

spring-boot-starter-actuator

1.5.14.RELEASE

然后在配置文件里面加上健康狀態檢查配置:

eureka:

client:

healthcheck:

enabled:true

這時，啟動自己的服務，通過http://localhost:port/health訪問就可以得到服務的健康狀態信息：

{"description":"Composite Discovery Client","status":"UP"}

當這個配置設置為false時，服務將不會把健康狀態傳遞給Eureka，那么Eureka就不會再更新Status信息，但是此時仍能夠通過上面的地址獲取這個真實的狀態信息。

應用狀態的取值：UP，DOWN，OUT_OF_SERVICE，UNKNOWN等；只有標記為UP的微服務會被請求；

通過在application.yml中配置eureka.client.healthcheck.enabled = true，應用程序會將自己Spring Boot Actuator的/heath端點的健康狀態傳播到Eureka Server

這里的/health檢查包括下面這些，其中還包括redis、mysql、hystrix等監控的檢查：

如健康狀況：

DiskSpaceHealthIndicator

RefreshScopeHealthIndicator

HystrixHealthIndicator

它將這些狀態會映射到Eureka支持的狀態之一，之后被映射后的狀態將通過心跳傳播到Eureka服務器。

列如一個應用實例在監控檢查的時候發現當前的磁盤空間不夠用了，就會通過心跳傳遞給Eureka服務器，這里時候你在Eureka服務器查詢到當前應用實例的狀態就是down狀態

其他應用通過Eureka服務器獲得當前應用實例的狀態就是down，就無法訪問改應用實例，應用實例只有up狀態才能訪問

Erueka狀態變更說明

STARTING ： 表示服務正在啟動中

DOWN： 表示服務已經宕機，無法繼續提供服務

UP ： 服務正常運行

OUT_OF_SERVICE : 不再提供服務，其他的Eureka Client將調用不到該服務，一般有人為的調用接口設置的，如：強制下線。

UNKNOWN： 未知狀態

容器啟動

在容器剛剛啟動，實例化instance信息的時候，默認狀態為STARTING

在Eureka Client端，有一個40秒執行一次的定時任務，會定時的去掃描自身的信息，查看自身信息是否發生改變，

其中就有一個對狀態的檢測，這個時候，如果設置了健康檢查器，那么會以健康檢查的結果為準，判斷當前實例的

狀態，然后會通過心跳實例的最新狀態重新注冊到Eureka上面去。

Eureka客戶端健康端點

Eureka客戶端在向服務器注冊時會在其POST的內容中加入healthCheckUrl?，這個healthCheckUrl的值是由以下實例屬性計算得出：

eureka.instance.health-check-url

eureka.instance.health-check-url-path

.health-check-url-path的默認值是?/health，這是Springboot默認專門用于檢查健康的actuator端點，除非.heath-check-url被專門配置了。

如果實現自定義健康狀況端點或更改默認健康檢查路徑，則應配置這些屬性：

endpoints.health.path=/new-heath

# either relative path

eureka.instance.health-check-url-path=${endpoints.health.path}

# or absolute path

eureka.instance.health-check-url=http://${eureka.hostname}:${server.port}/${endpoints.health.path}

如果你引入一個 management.context-path

management.context-path=/admin

# either relative path

eureka.instance.health-check-url-path=${management.context-path}/health

# or absolute path

eureka.instance.health-check-url=http://${eureka.hostname}:${server.port}/${management.context-path}/health

健康狀況的試驗

Eureka服務器并不關心客戶端的狀態 - 它只記錄客戶端狀態，當有人查詢其注冊表時，它也會發布客戶的健康狀況。即

GET /eureka/apps/ORDER-SERVICE

DISCOVERY-EUREKA-CLIENT

localhost:discovery-eureka-client:8886

192.168.1.6

8886

UP

UP

http://localhost:8886/health

...

...

這個響應有三個與健康有關的重要信息：?status?、overridenstatus和healthCheckUrl

status?是Eureka實例本身發布的健康狀況。

overriddenstatus?是手動或通過工具強制執行的健康狀態。比如PUT /eureka/apps/{app id}/instance id}/status?value={status}操作用于修改發布的狀態，那么status和overriddenstatus都將變更為新的狀態。

healthCheckUrl?是客戶端公開GET其健康狀態的端點。

其他工具則可以利用這些健康信息：

客戶端負載平衡器(如Ribbon)可以做出負載平衡決策?: Ribbon?讀取 ?status? 屬性并僅使用具有UP? 負載平衡狀態的實例 ?。但是，Ribbon不會調用 ?healthCheckUrl，?而是依賴于注冊表中可用的、已發布實例狀態。如一個應用實例在Eureka在服務器上面的狀態是down，Ribbon從Eureka服務器上面讀取實例的狀態是down，那么Ribbon就不會調用down狀態的應用實例，但是你直接通過postman請求改應用實例是可以的，但是通過Ribbon是無法遠程訪問改應用實例的

健康狀況的準確性

由于下面列出的原因，Eureka服務器注冊表健康狀況的并不總是準確的。

CAP中的AP?- 由于Eureka在CAP定理方面定位于高度可用的系統，因此在網絡分區期間，集群Eureka服務器之間的信息可能不一致。

服務器響應緩存?- Eureka服務器維護一個響應緩存，默認情況下每30秒更新一次。因此，實際上在 ?GET /eureka/apps/{app id}/?響應中出現?UP?的實例可能已經DOWN?了?。

定期調度心跳?- 由于客戶端默認情況下每30秒發送一次心跳，因此服務器注冊表中實例的運行狀況可能不準確。

自我保護?- 當Eureka服務器沒有收到超過某個閾值的心跳時，它會停止失效注冊表中的客戶端，從而會使注冊表不準確。

因此，客戶端應遵循適當的故障轉移機制來補充這種不準確性。

Spring boot admin 節點狀態一直為DOWN的排查(忽略某一個節點的健康檢查)

某個應用實例運行成功后服務節點一直顯示為DOWN，訪問 http://127.0.0.1:8081/actuator/health健康檢查端點返回值如下

可以看出redis 宕機了，但其實我項目本身沒有使用redis。，我們可以在應該實例的健康檢查中忽略redis的檢查，這里在eureka服務器上面改應用實例的狀態就不是down狀態了。

在顯示DOWN的客戶端添加如下配置(忽略redis的健康檢查)：

spring:

profiles:

active: dev

management:

health:

redis:

enabled:falseendpoint:

health:

show-details: always

endpoints:

web:

exposure:

include:"*"server:

port:8081

在spring boot admin監控中，一個應用下面存在3個應用實例，只要其中的一個應用實例的狀態為down，那么該應用的狀態就是down只要其中一個監控內容為DOWN,則該節點的總體狀態就為DOWN

總結

以上是生活随笔為你收集整理的服务器状态显示down,Eureka心跳健康检查机制和Spring boot admin 节点状态一直为DOWN的排查（忽略某一个节点的健康检查）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。