运行阶段执行健康检查的目的是为了从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客户端(或服务器)都是不调用/health端点来确定实例的健康状态,Eureka实例的运行状况由HealthCheckHandler实现确定,只要应用程序正在运行,默认情况下HealthCheckHandler始终会通知应用程序处于某种 UP 状态。
Eureka允许通过EurekaClient#registerHealthCheck()API 插入自定义的HealthCheckHandlers,如果在Spring Cloud设置了以下属性,则会注册一个新的Spring自己的处理程序EurekaHealthCheckHandler:
eureka.client.healthcheck.enabled=true
该EurekaHealthCheckHandler汇总了多个健康指标,如健康状况:
DiskSpaceHealthIndicator
RefreshScopeHealthIndicator
HystrixHealthIndicator
它将这些状态会映射到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=/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, 而是依赖于注册表中可用的、已发布实例状态。
像Asgard这样的部署工具可以做出部署决策 - 在滚动部署期间,Asgard部署了一个新版本的微服务,在 部署其余实例之前一直等待当前实例转换到UP 状态。但是,status Asgard 不是依赖于注册表中可用的实例状态(即属性),而是 通过调用 healthCheckUrl来了解实例状态 ,这可能是因为status 属性的值可能会变得陈旧(因为它取决于下一节中描述的几个因素),但在这种情况下,实时健康状态很重要,以避免部署延迟。
由于下面列出的原因,Eureka服务器注册表健康状况的并不总是准确的。
因此,客户端应遵循适当的故障转移机制来补充这种不准确性。
“随着微服务架构的发展,Spring Cloud 使用得越来越广泛。驰狼课堂http://www.chilangedu.com (QQ群:348039381) Spring Boot 快速入门,Spring Boot 与Spring Cloud 整合,docker+k8s,大型电商商城等多套免费实战教程可以帮您真正做到快速上手,将技术点切实运用到微服务项目中。”
下一篇 Spring Cloud系列教程 | 第四篇:Eurake的自我保护机制