eureka 服务实例实现快速下线快速感知快速刷新配置解析

Spirng Eureka 默认配置解读

默认的Spring Eureka服务器,服务提供者和服务调用者配置不够灵敏,总是服务提供者在停掉很久之后,服务调用者很长时间并没有感知到变化。或者是服务已经注册上去了,但是服务调用方很长时间还是调用不到,发现不了这个服务。

 

Spring Eureka 默认配置下:

描述如下:

  1. EurekaServer默认有两个缓存,一个是ReadWriteMap,另一个是ReadOnlyMap。有服务提供者注册服务或者维持心跳时时,会修改ReadWriteMap。当有服务调用者查询服务实例列表时,默认会从ReadOnlyMap读取(这个在原生Eureka可以配置,SpringCloud Eureka中不能配置,一定会启用ReadOnlyMap读取),这样可以减少ReadWriteMap读写锁的争用,增大吞吐量。EurekaServer定时把数据从ReadWriteMap更新到ReadOnlyMap中。ReadWriteMap是一个Guava Cache,过期时间是可以配置的。
  2. 服务提供者注册服务后,会定时心跳。这个根据服务提供者的Eureka配置中的服务刷新时间决定。还有个配置是服务过期时间,这个配置在服务提供者配置但是在EurekaServer使用了,但是默认配置EurekaServer不会启用这个字段。需要配置好EurekaServer的扫描失效时间,才会启用EurekaServer的主动失效机制。在这个机制启用下:每个服务提供者会发送自己服务过期时间上去,EurekaServer会定时检查每个服务过期时间和上次心跳时间,如果在过期时间内没有收到过任何一次心跳,同时没有处于保护模式下(参考第一篇的Eureka自我保护机制),则会将这个实例从ReadWriteMap中去掉。
  3. 在默认没有启用EurekaServer主动失效服务实例的情况下,服务过期是利用ReadWriteMap超时缓存失效实现的,只有发送心跳的实例缓存不会失效。
  4. 服务调用者有本地缓存,定时从Eureka服务器上增量拉取所有服务实例列表

原因分析

 

服务提供者和服务调用者配置不够灵敏,总是服务提供者在停掉很久之后,服务调用者很长时间并没有感知到变化的原因:
EurekaServer自己的ReadWriteMap缓存失效延迟,刷新到ReadOnlyMap的延迟,服务调用者自己本地缓存刷新的延迟。

 

服务已经注册上去了,但是服务调用方很长时间还是调用不到,发现不了这个服务:
刷新到ReadOnlyMap的延迟,服务调用者自己本地缓存刷新的延迟

解决方案

EurekaServer修改如下配置:

 1 #eureka server刷新readCacheMap的时间,注意,client读取的是readCacheMap,这个时间决定了多久会把readWriteCacheMap的缓存更新到readCacheMap上
 2 #默认30s
 3 eureka.server.responseCacheUpdateIntervalMs=3000
 4 #eureka server缓存readWriteCacheMap失效时间,这个只有在这个时间过去后缓存才会失效,失效前不会更新,过期后从registry重新读取注册服务信息,registry是一个ConcurrentHashMap。
 5 #由于启用了evict其实就用不太上改这个配置了
 6 #默认180s
 7 eureka.server.responseCacheAutoExpirationInSeconds=180
 8 
 9 #启用主动失效,并且每次主动失效检测间隔为3s
10 eureka.server.eviction-interval-timer-in-ms=3000

Eureka服务提供方修改如下配置:

1 #服务过期时间配置,超过这个时间没有接收到心跳EurekaServer就会将这个实例剔除
2 #注意,EurekaServer一定要设置eureka.server.eviction-interval-timer-in-ms否则这个配置无效,这个配置一般为服务刷新时间配置的三倍
3 #默认90s
4 eureka.instance.lease-expiration-duration-in-seconds=15
5 #服务刷新时间配置,每隔这个时间会主动心跳一次
6 #默认30s
7 eureka.instance.lease-renewal-interval-in-seconds=5!

Eureka服务调用方修改如下配置:

1 #eureka client刷新本地缓存时间
2 #默认30s
3 eureka.client.registryFetchIntervalSeconds=5
4 #eureka客户端ribbon刷新时间
5 #默认30s
6 ribbon.ServerListRefreshInterval=5000

 

转载于:https://www.cnblogs.com/Mao-admin/p/10272828.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Eureka是Netflix开源的一款服务发现组件,用于实现服务架构中的服务注册与发现。当Eureka服务下线时,意味着无法继续使用Eureka提供的服务发现功能。 服务下线可能是由于多种原因引起的,例如服务器故障、网络问题或者人为操作。无论是哪种原因,服务下线都会对微服务架构的正常运行产生一定的影响。 首先,Eureka服务下线会导致服务注册和发现功能失效。其他微服务无法通过Eureka来获取服务的地址和端口信息,这会导致微服务之间的通信出现问题。无法及时发现和注册新的服务,也无法及时从服务列表中移除已下线服务,可能会影响负载均衡和故障恢复策略的实施。 其次,Eureka服务下线还会影响监控和故障转移等功能。Eureka可以通过健康检查等机制来对服务进行监控,当服务不可用时,可以及时通过故障转移来保证系统的可用性。但是一旦Eureka服务下线,这些功能就无法正常使用,将导致监控和故障转移的失效。 为了应对Eureka服务下线的情况,可以考虑以下几个解决方案。首先,可以使用其他的服务发现组件替代Eureka,如Consul或ZooKeeper,这些组件也提供了类似的服务注册和发现功能。其次,可以采用主备模式,即配置多个Eureka服务器,其中一个为主服务器,其他为备份服务器,当主服务器宕机时,备份服务器可以接替其功能。最后,还可以考虑增加监控和报警机制,及时发现Eureka服务的异常情况,并及时采取相应的措施来修复问题。 总之,Eureka服务下线对微服务架构的正常运行会带来一定的影响,需要采取相应的解决方案来应对这种情况。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值