springCloud 之 Eureka 注册中心平滑下线客户端服务使用及原理

妖狐艹你老母 2022-11-05 00:50 547阅读 0赞

Eureka 中客户端服务下线的几种方式

一、下线的方式和存在的问题

1、直接停掉服务  
根据Eureka默认的策略，如果在一定的时间内，客户端没有向注册中心发送心跳或续约请求，那么注册中心就会将该实例从注册中心移除；但是有缺陷，因为服务直接停掉后，实例仍然会在注册中心存在一段时间（默认90s，可以自定义设置），这段时间里客户端会依然会正常从注册中心拉取（即正常使用），有流量是会进行服务调用，尤其是高并发环境下。  
2、通过注册中心接口强制下线  
通过注册中心的接口，我们可以强制下线指定的服务，场景如下：

比如有些情况是服务主机意外宕机了，也就意味着服务没办法给 eureka 心跳信息了，但是 eureka 在没有接受到心跳的情况下依赖维护该服务 90s，在这 90s 之内可能会有客户端调用 到该服务，这就可能会导致调用失败。 所以我们必须要有一个机制能手动的立马把宕机的服 务从 eureka 服务列表中清除掉，避免被服务调用方调用到。  
调用服务下线的接口： 这个接口是调用 eureka 服务端的接口，手动 通过 postman 删除，例如：

接口请求格式如下

// 注册中心zone  
eureka:  
  client:  
    serviceUrl:  
      defaultZone

发送一个delete 请求  
http://你的注册中心zone/apps/你的实例名称/你的实例地址加端口

如：http://localhost:8763/eureka/apps/web-order/localhost:micro-order:8084  
   
http://localhost:8763/eureka/apps:所连接的服务端地址  
web-order/localhost:micro-order:8084：所要删除的客户端名称和地址  
 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

调用删除接口后，服务实例会从注册中心强制下线，缺陷如下：此时如果服务仍然在线，则服务自身会通过心跳包向注册中心再次上线；另外即使服务已经挂掉（并且也调用删除接口），客户端可能依然存在此实例（还没有进行新的拉取），流量可能会调用的此挂了的服务。

3、客户端主动下线

// 客户端可以通过如下代码主动通知注册中心下线
    DiscoveryManager.getInstance().shutdownComponent();

此方案中，客户端主动下线后，依然存在问题：Eureke还会有90s保存此实例，其他客户端可以正常拉取， 即 其他种类客户端可能依然存在此实例（还没有进行新的拉取），流量可能会调用的此下线了的服务。

二、客户端服务下线或故障后存在的问题的解决方案

服务下线时固然存在相应问题，如何解决呢？

**1、重试机制**

**如果此微服务中用Ribbon 做服务调用负载均衡，可以采取重试机制。**

那么一台服务器下线，最长的不可用时间是多少呢？

#表示eureka client间隔多久去拉取服务注册信息，默认为30秒
    eureka.client.registry-fetch-interval-seconds=30

极端情况下服务上线的发现时间也需要30秒。理想情况下，在这30秒之间，请求是失败的。加入你的QPS是1000，部署了四个节点，那么在30秒中失败的请求数量会是 1000 / 4 \* 30 ，这是不可接受的。所以我们要引入重试机制。

SpringCloud在Ribbon插件中引入重试，可以按照以下的步骤：

方案一：

ribbon.OkToRetryOnAllOperations:true 
    #(是否所有操作都重试，若false则仅get请求重试)
    ribbon.MaxAutoRetriesNextServer:3 
    #(重试负载均衡其他实例最大重试次数,不含首次实例)
    ribbon.MaxAutoRetries:1
    #(同一实例最大重试次数,不含首次调用)
    ribbon.ReadTimeout:30000
    ribbon.ConnectTimeout:3000
    ribbon.retryableStatusCodes:404,500,503
    #（那些状态进行重试）
    spring.cloud.loadbalancer.retry.enable:true
    # (重试开关)

方案二：

ribbon.client.name=micro-order-test
    #点对点直连测试配置
    # 关闭ribbon访问注册中心Eureka Server发现服务，但是服务依旧会注册。
    #true使用eureka false不使用：服务类表是否从eureka 中来
    ribbon.eureka.enabled=true
    spring.cloud.loadbalancer.retry.enabled=true
    #指定调用的节点，和 ribbon.eureka.enabled=true  二选一配置；这种方式不建议使用，灵活性不好。
    #micro-order.ribbon.listOfServers=localhost:8001
    #单位ms ,请求连接超时时间
    ribbon.ConnectTimeout=1000
    #单位ms ,请求处理的超时时间
    ribbon.ReadTimeout=3000
    #接口幂等性思想，是否重试所有的接口
    ribbon.OkToRetryOnAllOperations=false
    #切换实例的重试次数
    ribbon.MaxAutoRetriesNextServer=2
    #对当前实例的重试次数 当Eureka中可以找到服务，但是服务连不上时将会重试
    ribbon.MaxAutoRetries=2
    #负载均衡的算法配置
    ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule
    #验证服务是否存活的配置
    ribbon.NFLoadBalancerPingClassName=com.netflix.loadbalancer.PingUrl

大家可以根据实际业务场景具体设置，多测试，多总结。

到此 Eureka 注册中心平滑下线客户端服务使用及原理分析完毕。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221023/730bbc6ce3354096860f3fed89c2b94c.png