极简Spring Cloud实战最新章节_胡劲寒著

2.2 进阶场景

尝试过Eureka的基本使用场景后，虽然功能能够实现，但是落实到具体的企业级应用场景时，必然会有许多需要自定义的配置以及一些生产环境可能需要用到的参数。下面列出一些场景供读者参考。

（1）Eureka的健康检查

默认情况下，Eureka通过客户端心跳包来检测客户端状态，并不是通过spring-boot-actuator模块的/health端点来实现的。默认的心跳实现方式可以有效地检查Eureka客户端进程是否正常运作，但是无法保证客户端应用能够正常提供服务。由于大多数微服务应用都会有一些外部资源依赖，比如数据库、Redis缓存等，如果应用与这些外部资源无法连通时，实际上已经不能提供正常的对外服务了，但因为客户端心跳依然在运行，所以它还是会被服务消费者调用，而这样的调用实际上并不能获得预期的效果。当然，我们可以开启Eureka的健康检查，这样应用状态就可以同步给Eureka了。在application.yml中添加如下配置即可：

eureka:
    client:
        healthcheck:
            enabled:true

Eureka中的实例一共有如下几种状态：UP、DOWN、STARTING、OUT_OF_SERVICE、UNKNOWN。如果需要更多的健康检查控制，可以实现com.netflix.appinfo.Health-CheckHandler接口，根据自己的场景进行操作。

警告 eureka.client.healthcheck.enabled=true只能在application.yml中设置，如果在bootstrap.yml中设置，会导致Eureka注册为UNKNOWN的状态。

（2）自我保护模式

Eureka在设计时，认为分布式环境的网络是不可靠的，可能会因网络问题导致Eureka Server没有收到实例的心跳，但是这并不能说明实例宕了，所以Eureka Server默认会打开保护模式，它主要是网络分区场景下的一种保护。

一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除里面的数据（即不会注销任何微服务）。在这种机制下，它仍然鼓励客户端再去尝试调用这个所谓down状态的实例，当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。若确实调用失败，熔断器就派上用场了。

关于熔断器，第6章会详细介绍并演示。

通过修改注册中心的配置文件application.yml，即可打开或关闭注册中心的自我保护模式：

eureka:
    server:
        enable-self-presaervation: false           #关闭自我保护模式（默认为打开）

综上，自我保护模式是一种应对网络异常的安全保护措施。它的理念是宁可同时保留所有实例（健康实例和不健康实例都会保留），也不盲目注销任何健康的实例。使用自我保护模式，可以让Eureka集群更加健壮、稳定。

（3）踢出宕机节点

自我保护模式打开时，已关停节点是一直显示在Eureka首页的。

关闭自我保护模式后，由于其默认的心跳周期比较长等原因，要过一会儿才会发现已关停节点被自动踢出了。若想尽快踢出，就只能修改默认的心跳周期参数了。

注册中心的配置文件application.yml需要修改的地方如下所示：

eureka:
    server:
        enable-self-preservation: false       # 关闭自我保护模式（默认为打开）
        eviction-interval-timer-in-ms: 1000   # 续期时间，即扫描失效服务的间隔时间
                                                （默认为60*1000ms）

客户端的配置文件application.yml需要修改的地方为：

eureka:
    instance:
        lease-renewal-interval-in-seconds: 5   # 心跳时间，即服务续约间隔时间（默认为30s）
        lease-expiration-duration-in-seconds: 15  # 发呆时间，即服务续约到期时间（默认为90s）
    client:
        healthcheck:
            enabled: true          #开启健康检查（依赖spring-boot-starter-actuator）

注意更改Eureka Server的更新频率将打破注册中心的自我保护功能，不建议生产环境自定义这些配置。

（4）注册服务慢的问题

客户端去注册中心默认持续30s，直到实例自身、服务端、客户端各自元数据本地缓存同步完成后服务才可用（至少需要3次心跳周期）。可以通过eureka.instance.leaseRenewalIntervalInSeconds修改这个周期，改善客户端链接到服务的速度。不过，考虑短期的网络波动以及服务续期等情况，在生产环境最好用默认设定。

（5）服务状态显示UNKNOWN

如果在Eureka监控页面发现服务状态显示UNKNOWN，则很大可能是把微服务的eureka.client.healthcheck.enabled属性配置在bootstrap.yml里面的问题。比如，实际测试发现，Eureka首页显示的服务状态，本应是UP(1)，却变成大红色的粗体UNKNOWN(1)。

（6）自定义InstanceId

两个相同的服务（端口不同），如果注册时设置的都是${spring.application.name}，那么Eureka首页只会看到一个服务名字，而无法区分有几个实例注册上来了。于是，可以自定义生成InstanceId的规则。

Eureka服务名默认如下：

${spring.cloud.client.hostname}:${spring.application.name}:${spring.application.instance_id:${server.port}}

可以在配置文件中通过eureka.intance.intance_id来自定义：

eureka:
    instance:
        #修改显示的微服务名为：IP:端口
        instance-id: ${spring.cloud.client.ipAddress}:${server.port}

（7）自定义Eureka控制台服务的链接

既然微服务显示的名称允许修改，那么其对应的点击链接也是可以修改的。

同样，还是修改微服务的配置文件，如下所示：

eureka:
    instance:
        # ip-address: 192.168.6.66  #只有prefer-ip-address=true时才会生效
        prefer-ip-address: true     #设置微服务调用地址为IP优先（默认为false）

Eureka首页显示的微服务调用地址，默认是 http://hostName:port/info 。

而在设置prefer-ip-address=true之后，调用地址会变成 http://ip:port/info 。

这时若再设置ip-address=192.168.6.66，则调用地址会变成 http://192.168.6.66:2100/info 。

（8）健康度指示器

一个Eurake实例的状态页和健康指示器默认为/info和/health，这两个是由Spring Boot Actuator应用提供的访问端点。可以通过以下方式进行修改：

application.yml
eureka:
    instance:
        statusPageUrlPath: ${management.context-path}/info
        healthCheckUrlPath: ${management.context-path}/health

这些地址会被用于Eureka对客户端元数据的获取，以及健康检测。

（9）就近原则

用户量比较大或者用户地理位置分布范围很广的项目，一般都会有多个机房。这个时候如果上线服务的话，我们希望一个机房内的服务优先调用同一个机房内的服务，当同一个机房的服务不可用时，再去调用其他机房的服务，以达到减少延时的作用。Eureka有Region和Zone的概念，可以理解为现实中的大区（Region）和机房（Zone）。Eureka Client在启动时需要指定Zone，它会优先请求自己Zone的Eureka Server获取注册列表。同样，Eureka Server在启动时也需要指定Zone。如果没有指定，其会默认使用defaultZone。

（10）高可用配置

Eureka Server也支持运行多实例，并以互相注册的方式（即伙伴机制）来实现高可用的部署，即每一台Eureka都在配置中指定另一个Eureka地址作为伙伴，它在启动时会向伙伴节点获取注册列表。如此一来，Eureka集群新加机器时，就不用担心注册列表的完整性。所以，只需要在Eureka Server里面配置其他可用的serviceUrl，就实现了注册中心的高可用。

我们新建两个Eureka服务端项。第1个服务端项为EurekaServer1项目中的配置文件/src/main/resources/application.yml。

server:
    port: 8989
eureka
    serviceUrl:
        defaultZone:

第2个服务端项为EurekaServer2项目中的配置文件/src/main/resources/application.yml。

server:
    port: 9898
eureka
    serviceUrl:
        defaultZone:

启动Server1、Server2后，分别访问 http://127.0.0.1:8989/eureka/ 、 http://127.0.0.1:9898/eureka/ ，发现DS Replicas、General Info模块出现了对方的信息。读者可以自行测试，分别单独向Server1或者Server2进行服务注册时，都会自动同步给另外一个注册中心。

在生产环境中大于两台注册中心的条件下，可以同理将其配置成如图2-4所示的双向环形。

图2-4 双向环