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

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：所要删除的客户端名称和地址
 

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

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 注册中心平滑下线客户端服务使用及原理分析完毕。