Skip to content

Latest commit

 

History

History
93 lines (56 loc) · 3.52 KB

8.Eureka进阶之健康检查和蓝绿发布.md

File metadata and controls

93 lines (56 loc) · 3.52 KB
Raw

Eureka进阶之健康检查和蓝绿发布

The Mystery of Eureka Health Monitoring
Spring Cloud Netflix Eureka - The Hidden Manual

报心跳式健康检查

健康检查是微服务框架中非常重要的一种技术。

健康检查一般有主动心跳的方式，就是注册中心主动去心跳检测注册上来的服务是否还存活。

而Eureka采用的是报心跳健康检查的方式，微服务会定期，主动报心跳到注册中心。

默认时间间隔是30s

扩展

开发人员可以通过EurekaClient#registerHealthCheck定制心跳检测策略

SpringCloud 也提供了一些手段来定制健康检查：

  • eureka.client.healthcheck.enable=true
  • EurekaHealthCheckHandler
    • DiskSpaceHealthIndicator
    • RefreshScopehealthIndicator
    • HystrixHealthIndicator

只有当DiskSpaceHealthIndicator这些端点都健康的请款下，可以认为当前服务是健康状态。

获取应用信息

可以调用eureka的restful api查看应用的信息

GET /eureka/apps/ORDER-SERVICE

<?xml version="1.0" encoding="UTF-8"?> 
<application>
    <name>DISCOVERY-EUREKA-CLIENT</name> 
    <instance>
        <instanceId>localhost:order-service:8886</instanceId> 
        <ipAddr>192.168.1.6</ipAddr>
        <port>8886</port>
        <status>UP</status>
        <overriddenstatus>UP</overriddenstatus> 
        <healthCheckUrl>http://localhost:8886/health</healthCheckUrl>
        ... ...
    </instance>
</application>

Ribbon软负载决策

Ribbon如何与Eureka健康检查互相作用呢？

如下，有两个Instance，其中一个处于UP状态，另一个还在注册中的状态。

Ribbon的核心组件中有一个服务列表更新组件，它会定期更新Eureka中的注册列表。

当客户端发起调用的时候，Ribbon只会选择哪些处于UP状态的Instance进行调用。

更新延迟

  1. Service Instance注册到Eureka上面并不是马上就是UP状态，还需要30s之后发送心跳检测后才是UP状态
  2. Ribbon或者其他服务获取Eureka服务器的列表是也是存在延迟的，存在一个响应延迟，最大30s
  3. Ribbon服务列表更新是固定周期的，也不是实时的
  4. Eureka客户端更新延迟也是同样固定周期的，可能存在延迟

蓝绿发布

Eureka提供了专门的API用来显式的设置服务的状态，这样的话，在服务发版的时候，一些老版本的服务节点可以通过调用接口显式的踢出Eureka，那个Ribbon检测到Out_OF_SERVICE状态后，就不会负载到这个实例。

Asgard发布管理工具就是专门用来设置服务节点下线状态的工具。

通过Health端点检查快速发布

上面也提到了，服务注册到Eureka上面并不是马上就是UP状态，中间会有一段时间的延迟。

那么这样对于服务发布来说的话，会非常慢。因此Netflix的内部规范要求，每个服务必需要提供health check端点。

在服务发版的时候，主要服务注册到Eureka上，Asgard拿到服务列表之后，回去调用对应服务提供的health check端点进行健康检查。