eureka自我保护时间_SpringCloud Eureka 失效剔除和自我保护

最新推荐文章于 2024-08-26 15:22:38 发布

投妍帮

最新推荐文章于 2024-08-26 15:22:38 发布

阅读量1.6k

点赞数

文章标签： eureka自我保护时间

本文链接：https://blog.csdn.net/weixin_42382748/article/details/112340563

版权

本文介绍了Eureka Server的失效剔除和自我保护机制。当服务下线或网络故障时，Eureka通过定时任务剔除超时未续约的服务。自我保护模式在服务心跳比例低于85%时启动，防止误判服务下线，确保网络不稳定时大部分服务仍可用。文章探讨了自我保护的触发条件、效果及关闭保护的注意事项，并强调服务消费者需具备容错机制。

摘要由CSDN通过智能技术生成

目标：

配置eureka失效剔除和自我保护

作用对象：

eureka-server

如下的配置都是在Eureka Server服务端进行：

服务下线

当服务进行正常关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线了”。服务中心接受到请求之后，将该服务置为下线状态。

失效剔除

有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作，而服务注册中心并未收到“服务下线”的请求。相对于服务提供者的“服务续约”操作，服务注册中心在启动时会创建一个定时任务，默认每隔一段时间(默认为60秒)将当前清单中超时(默认为90秒)没有续约的服务剔除，这个操作被称为失效剔除。可以通过 eureka.server.eviction-interval-timer-in-ms 参数对其进行修改，单位是毫秒。

自我保护

我们关停一个服务，很可能会在Eureka面板看到一条警告：

操作方式：

1：先正常的启动所有的服务。能够正常的提供服务和消费服务。

2：把user-service服务关停。模拟网络抖动或者故障造成服务下线。这个时候eureka-server会启动保护机制

模拟场景：

# 查看所有java的运行进程
> jps

2：通过 taskkill /PID 57640 /F

日志信息如下：

 Running the evict task with compensationTime 0ms

看到中间的红色的大写字母了么?翻译一下:
注意,Eureka可能会错误的将已经下线的实例申明为上线,续订低于阈值因此实例不会过期,仅仅是为了安全起见
这句话比较拗口,但是大概的意思就是,即使微服务挂掉了,我Eureka也会说他没有挂掉,这个是为了安全考虑.

WTF,为了啥安全? 怎么就安全了？既然微服务下线了,Eureka你直接说微服务下线不就行了,微服务上线,你就请求路由到上线的微服务这不就行了?

为什么需要搞这一套了?

直觉告诉我事情肯定没有那么的简单,既然他弄了肯定会有他的道理

查了一些资料,看了一些介绍,大概的意思就是为了防止网络阻塞的问题

想象一个场景,以前在农村的小黑网吧里面,也就2m的网络大概也就200kb/s的下载速度,却要给4-6台左右的电脑使用,带宽就比较的紧张了的,我以前在农村网吧上网的时候,老板就说,不要开迅雷下载啊,影响大家玩游戏

这个时候游戏服务器就相当于是Eureka,想一想,如果有人在网吧下载东西,导致其他的几个人网卡,玩游戏连接不了服务器,那么游戏服务器该怎么办呢?

立刻判断用户已经下线?

当然不是,比如最近的手机吃鸡游戏刺激战场,在网络卡的情况下是提醒再次等待连接,多次连接不行才让你下线重新登录.

所以Eureka也是这个道理.只不过他的保护模式有点过头了.

他为什么要这么保护么？

我们没有看源码只能猜测下:我觉得可能有这几种情况,一种是体验不好,如果网络环境糟糕,频繁上下线会很麻烦,在游戏中本身就存在很多的用户的上线和下线行为，游戏服务器必定会对此做一些优化，但是微服务是跑得应用怎么能随随便便的下线了，尽管对于EurekaServer而言，微服务是Client端，但是对于前端而言，他们都是Server，必须要稳定

第二个就是浪费时间,Tcp通信都还要3次握手,频繁的通信断开连接,时间大量的花费在沟通上,得不偿失.

这是触发了Eureka的自我保护机制。当服务未按时进行心跳续约时，Eureka会统计服务实例最近15分钟之内之后心跳续约的比例是否低于了85%。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。

Eureka在这段时间内不会剔除任何服务实例，直到网络恢复正常。生产环境下这很有效，保证了大多数服务依然可用，不过也有可能获取到失败的服务实例，因此服务调用者必须做好服务的失败容错。

问题1：85%是如何计算出来的 85%活着的服务继续提供

这种85%是如何计算出来的呢？比如你有10个user-service节点注册到eureka-server中，这个时候挂了两台。那么比例就是：(10-2)/10 = 80% 。这个时候就会引发自我保护机制，15分钟内如果是挂一台当然就是90%是不会触发保护机制。

问题2：自我保护机制的效果

一旦进入到保护模式，所以的eureka服务都不再被踢出来。

一种是体验不好,如果网络环境糟糕,频繁上下线会很麻烦,在游戏中本身就存在很多的用户的上线和下线行为，游戏服务器必定会对此做一些优化，但是微服务是跑得应用怎么能随随便便的下线了，尽管对于EurekaServer而言，微服务是Client端，但是对于前端而言，他们都是Server，必须要稳定

第二个就是浪费时间,Tcp通信都还要3次握手,频繁的通信断开连接,时间大量的花费在沟通上,得不偿失.

问题3：eureka为什么要有自我保护机制

Eureka Server 在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 会将这些实例保护起来，让这些实例不会过期，但是在保护期内如果服务刚好这个服务提供者非正常下线了，此时服务消费者就会拿到一个无效的服务实例，此时会调用失败，对于这个问题需要服务消费者端要有一些容错机制，如重试，断路器等。

我们在单机测试的时候很容易满足心跳失败比例在 15 分钟之内低于 85%，这个时候就会触发 Eureka 的保护机制，一旦开启了保护机制，则服务注册中心维护的服务实例就不是那么准确了，此时我们可以使用eureka.server.enable-self-preservation=false来关闭保护机制，这样可以确保注册中心中不可用的实例被及时的剔除(不推荐)。

eureka:
  server:
    # 服务失效剔除时间间隔，默认60秒 eureka服务定时扫描失效的服务，把失效的服务剔除
    eviction-interval-timer-in-ms: 60000
    # 关闭自我保护模式(默认是打开的)
    enable-self-preservation: true

重点

eureka的服务注册同步时间30秒，目的是为了保证后续的后续服务能够继续注册eureka钟，服务拉取时间也是30秒，如果在同步的过程中，出现了服务故障，eureka-server就开启一个线程去执行和连接通讯，如果90秒之内还没有连接上，就直接认为该服务是可以踢出的服务。eureka其实并不会这样做，因为eureka默认会启动保护机制，如果你坏的服务和好的比例如果在15分钟内如果超过的阈值低于85%会出现红色警告。目的让有警醒的作用，告诉你修复服务了。如果你15分钟内一直没有修复，超过15分钟，eureka就启动剔除机制，把坏服务剔除掉，目的就是节约内存空间，让后更多其他的服务注册进来。并且红色警告消失。

红色警告消失的临界点：

1：在15分钟把哪些坏的服务修复成功。

2：15分钟之后，把坏的服务剔除掉了。红色警告也会消失。