eureka心跳_Eureka的服务健康检测和部署机制

微服务的健康状态检测有服务实例主动上报和服务发现中心定期去检测两种方式，Eureka采用的是主动上报心跳的方式，如下图所示：

image.png

Eureka上报心跳机制：

心跳往上报的时候，上报的内容包含了服务名和具体的服务实例信息以及服务的状态，具体格式如下：

PUT /eureka/apps/{appId}/{instanceId}?status=UP

其中的appId就是服务实例名称，instanceId中包含了服务的ip地址和端口号，一个典型的示例:

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

默认的是30S上报一次心跳，如果连续三次没有上报心跳(就是前文的Eureka参数配置有提到的默认是90S秒)会剔除掉该服务实例。

Eureka 的定制检查

有些时候我们检查服务状态是否健康需要根据服务的以下特定的指标参数去做判断，比如数据连接状态，磁盘使用情况，限流控制情况等等，这个时候需要引入HeahCheckHandler去做定制检查。

定制注册时需要开启healthcheck，可以在配置文件中做如下指定:

eureka.client.healthcheck.enabled=ture

至于具体的健康检查标准，需要在EurekaHealthCheckHandler里面去处理，需要在里面指定一系列像Indicator这种的健康的指标，每个Indicator就是健康检查的一个检查点，比如DiskSpaceHealthIndicator，RefreshScopeHealthIndicator，HystrixHealthIndicator等等。

Eureka查看服务状态信息

服务的心跳上报过后就可以通过Restful接口查看到服务的状态信息了，以上面的ORDER-SERVICE服务为例查看服务状态信息的命令就是

GET /eureka/apps/ORDER-SERVICE

查看到的内容像这样：

DISCOVERY-EUREKA-CLIENT

localhost:order-service:8886

192.168.1.6

8886

UP

UP

[http://localhost:8886/health

… …

Eureka与Ribbon配合实现负载均衡

上文提到了服务的状态如何上报，如何检测，而这些都是实现服务的正常路由和负载均衡的基础，也就是只有知道哪些服务是正常的可以工作的。请求过来时才能决策如何分配这些流量打到正常的服务实例上面，先来看一个基础的软负载的工作示意图：

image.png

这里看到是一个Ribbon服务SVC2 调边界服务SVC1的过程。首先SVC1有两个实例，一个已经启用一个还在starting状态。他们主动向Eureka服务器报自己的状态，Ribbon通过Get接口获取服务的状态信息，得知只有Instance1是UP状态时，会将请求的流量都打到Instance1上，不会去访问Instance2了。调用的时候直接访问，而不用通过/health接口去检查服务实例的状态是否正常了。

这里只是用作示例，实际的环境中可能有多个示例是UP状态的，这个时候会根据Ribbon的负载均衡策略将请求流量达到UP的服务实例上。

还有一个问题需要注意，这里的服务注册，可用的列表相应更新操作都不是即时完成的，都是有时间延迟的，包含如下几个过程：

服务注册延时(30S)

Eureka服务器响应延迟(30S)

Eureka客户端更新延迟(30S)

Ribbon服务列表更新延迟(30S)

以上延迟默认都是30S，也就是如果我们不去调整默认参数，一个完整的实例信息新的最大延迟可以达到2分钟。

Eureka服务实例的蓝绿部署

最后说一下服务实例蓝绿部署的操作。所谓蓝绿部署，就是在部署新版本的时候可以通过Eureka把一些老的服务实例拉出，让流量都打到新实例上。如果工作正常就完全切换过去，把就实例删除，如果一旦有异常的话可以恢复，把流量重新打到老的工作正常的服务实例上去，从而保证该服务一直是出于可用的状态。

这里看一个示意图，如下：

image.png

SVC1的两个实例都是可以正常工作的，报的UP状态，这个时候如果要把某个实例拉出，可以通过Asgard发布管理工具(这个工具也是Netfix提供的)发送状态切换命令将某个实例拉出。

拉出的实例命令格式如下：

PUT /eureka/apps/{appId}/{instanceId}/status?value={status}

一个具体的实例命令:PUT /eureka/apps/ORDER-SERVICE/localhost:order-service:8886/status?value=OUT_OF_SERVICE,这样就把order服务的一个实例localhost:order-service:8886拉出了。

如果要恢复实例重新工作，可以删除这个服务状态就可以了，使用命令格式如下：

DELETE /eureka/apps/{appId}/{instanceId}/status

拉出过后Ribbon就不会将请求打到OUT_OF_SERVICE状态的服务了，老服务拉出后如果流量打到新服务有异常可以恢复回去。

另外对于Asgard，需要了解他会对服务做健康检查，对于在Eureka服务端注册上的实例一旦通过Asgard检查认为正常了，就会去发布下一个服务实例。这样就不用等每个实例都报了心跳再去发布下一个实例，加快了服务发布的过程。