Eureka Service Governance - self-protection mechanism

What is a self-protection mechanism?

In Eureka, there are two roles:

  • EurekaServer (registry server)
  • EurekaClient (registered clients)

Self-protection mechanism when in fact the case EurekaServer and EurekaClient network does not make sense, EurekaServer EurekaClient service will not reject.

Through a scene to find out:

There are two services: customer service app-user, order service app-order, customer service did a cluster, there are two machines, namely 8010 and 8011

Now order the use of load balancing polling mechanism, call the user interface, you can see that 8010 and 8011 polling access.

 8010 now that if this service is down, what would happen?

When accessing 8010, on the error, let's look at the list of registered Eureka, and in 8010 was still down in the list

Self-protection mechanism Description:

By default, "EurekaClient client" periodically (default 5 seconds) heartbeat packets are sent to the "EurekaServer registration center", that is to EurekaServer EurekaClient periodically sends a request, if EurekaServer to receive, we know that the current EurekaClient is alive status.

If EurekaServer within a certain time (typically 90 seconds by default), the heartbeat packet is not received EurekaClient transmitted, the service will be removed from the list of services. But if you lose the heartbeat of a large number of service instances in a short time, this time EurekaServer will open a self-protection mechanism, not excluding service.

Open self-protection mechanism in what circumstances?

Local environment
proposed closure of self-protection mechanism. Because in the local development environment, EurekaServer end relatively restart the frequency is not high, but the need to restart after EurekaClient end, it may change the code, the frequency is relatively high; it will not restart after the end EurekaClient timely whereabouts EurekaServer sends heartbeat package, EurekaServer end will be considered to be a network delays or other reasons, will not eliminate the service, so it will affect the development efficiency.

生产环境
建议开启自我保护机制。因为生产环境不会频繁重启服务器,并且EurekaClient端与EurekaServer端存在网络延迟的几率较高,所以需要开启自我保护机制避免误删服务。

如何关闭自我保护机制?

在EurekaServer端的yml配置文件中加入如下配置:

server:
    #开发环境关闭自我保护机制,保证不可用的服务及时剔除
    enable-self-preservation: false
    #间隔2秒钟剔除一次
    eviction-interval-timer-in-ms: 2000

然后再在EurekaClient端的yml配置文件中添加如下配置:

#心跳检测与续约时间(开发环境可以将值设小一点,保证服务关闭后注册中心能及时剔除)
#Eureka客户端向服务端发送心跳的时间间隔,单位为秒(客户端告诉服务端自己会遵循该规则)
lease-renewal-interval-in-seconds: 1
#Eureka服务端在收到最后一次心跳之后的等待的时间上限,单位为秒,超过就进行剔除(客户端告诉服务端自己会遵循该规则)
lease-expiration-duration-in-seconds: 2

同样还是用之前的例子,把服务都打开,看一下注册列表: 

user有两台,然后现在把8011这台服务关了,再刷新一下,8011就被剔除了。

这里需要注意一下,刚刚剔除完8011,order调用user的时候,还是在8010和8011两台服务之间进行轮询访问,当访问到8011的时候还是会报错,其实这是因为Ribbon存在30秒左右的缓存导致的。

如果服务真的宕机了怎么办?

  • 在本地调用应该有重试机制,访问不通的时候就做重试,如果重试多次还不行,就直接轮询到下一台服务器进行访问。
  • 保证接口网络延迟幂等性问题,防止用户重复提交。
  • 做好服务降级。
发布了46 篇原创文章 · 获赞 0 · 访问量 2023

Guess you like

Origin blog.csdn.net/hon_vin/article/details/102818384