目录
1.概览(Overview)
- 名词解释:
- eureka三个角色:
-
- eureka-server:独立的jvm实例,作为注册中心存在
- service-provider:发布服务的实例,通常是业务微服务(必须将自己注册到eureka-server中)
- service-consumer:服务的消费/使用者,通常也是业务微服务(仅需拉取eureka-server中的注册列表,无需将自己注册)
-
- 额外说明:一般情况下,我们的微服务既可以是provider,也可以是consumer,他俩的区别就是是否会向eureka-server发起注册
- eureka三个角色:
- 问题:开发生产环境中经常遇到的问题就是Spring cloud-eureka中的注册慢问题
- consumer端等待provider端注册时间长
- eureka-server剔除无效实例慢
- 本文主要解决以上问题
2.详细说明(Details)
先附上官方的注册慢问题解决方案(2.2的文档,1.4.7文档已经找不到了,仅供参考,具体以下方配置为主)。
下面,结合我们的实际使用过程,针对注册慢,剔除慢均进行了解决
-
减少延迟方式:以减少延时为解决办法,在减少心跳间隔、缓存时效基础上,缩小cosumer(zuul/其他client端) 感知 已剔除provider服务的时间
先奉上Spring cloud体系中各角色的配置
1、eureka-server # 服务端剔除间隔(默认60*1000) eureka.server.eviction-interval-timer-in-ms=500 2、service-provider # 实例续期持续多久后失效(默认90s) eureka.instance.lease-expiration-duration-in-seconds=2 # 实例续期心跳间隔(默认30s) eureka.instance.lease-renewal-interval-in-seconds=1 3、service-consumer(zuul/其他client) # 向eureka拉取注册列表的间隔(默认30s) eureka.client.registryFetchIntervalSeconds=2 # ribbon服务列表刷新间隔(单位ms) ribbon.ServerListRefreshInterval=500
3.补充说明
对于我们在向其他服务发起请求,服务注册列表未更新时导致的问题,可以通过设置重试尽量规避(前提时多实例并非全部down掉)。
Springcloud 体系下底层路由算法使用的时ribbon,因此我们可以使用如下方式:
配置重试次数方式:在consumer上通过增加重试次数,直到找到可用provider服务的方式【该方式不会解决注册慢的问题,但会通过重试减少错误请求发生率】
# zuul(或其他client)中配置重试次数,前缀为clientName,默认为applicationName,这样,当遇到无效服务时,会继续向其他服务发送重试,直到达到最大次数后仍未连接成功
***.ribbon.MaxAutoRetriesNextServer=3
如:face-compare-stat.ribbon.MaxAutoRetriesNextServer=3