Eureka self protection

The fault phenomenon ：

summary

Protection mode is mainly used for a group of clients and Eureka Server There is protection in the network partition scenario .- Once you enter protection mode ,Eureka Server Will try to protect the information in its service registry , Data in the service registry is no longer deleted , That is, no microservices are logged off .

If in Eureka Server See the following tip on the homepage of , shows Eureka Get into Protected mode :
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT.RENEWALS ARE LESSER THAN THRESHOLD AND HENCE thE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE

Cause ：
In a word ： At some point, a microservice is unavailable ,Eureka It won't clean up immediately , The information of the micro service will still be saved .

Belong to CAP Inside AP Branch .

Why does it produce Eureka Self-protection mechanism ?
In order to prevent EurekaClient It works , But with the EurekaServer When the network is not working ,EurekaServer Not immediately EurekaClient Service to eliminate

What is self-protection mode ?
By default , fruit EurekaServer I haven't received a... Within a certain period of time Heartbeat of a microservice instance ,EurekaServer The instance will be deregistered ( Default 90 second ). But when the network partition fails ( Time delay 、 Carton 、 crowded ) when , Micro service and EurekaServer Unable to communicate between , The above behavior may become very dangerous, because the micro service itself is actually healthy , This is not the time to log off the micro service .Eureka adopt “ Self-protection model ” To solve this problem when EurekaServer When a node loses too many clients in a short time ( A network partition failure may have occurred ), Then this node will go into self-protection mode .

for example

Self-protection mechanism ∶ By default EurekaClient Timing to EurekaServer Send heartbeat packets from the client

If Eureka stay server End in a certain period of time ( Default 90 second ) Have not received EurekaClient Send heartbeat packets , The service will be removed directly from the service registration list , But in a short time ( 90 In the second ) A large number of service instances are lost in the , Now Eurekaserver Will open up self-protection mechanism , The service will not be excluded （ This phenomenon may occur if the network is not connected, but EurekaClient For downtime , At this time, if you change to another registration center, if you do not receive a heartbeat within a certain time, the service will be rejected , This is a serious mistake , Because the client can send heartbeat normally , It's just network latency , The protection mechanism is to solve this problem ).

In self-protection mode ,Eureka Server Protects information in the service registry , No more service instances are logged off .
Its design philosophy is that it would rather keep the wrong service registration information , And don't blindly log off any possible healthy service instances . In a word ： Better to live than to die .

Sum up , Self protection mode is a kind of security protection measures to deal with network abnormalities . Its architectural philosophy is to retain all micro services at the same time （ Healthy microservices and unhealthy microservices will keep ） And don't blindly log off any healthy microservices . Use self-protection mode , It can make Eureka Clusters are more robust 、 Stable .

How to prohibit self-protection ：

1、 Registry Center eureakeServer End 7001
Eureka Self-protection mechanism enable-self-preservation: true Default Is open , When closing, you only need to register in the registry eureakeServer Terminal application.yml Add... To the document

eureka:
   server:
     # Turn off self-protection , Ensure that unavailable services are kicked out in time 
     enable-self-preservation: false
     # Heartbeat time 10 second 
     eviction-interval-timer-in-ms: 10000

design sketch ：

On the client side payment8001 Of application.yml File to add

eureka：   
  instance:
        instance-id: payment8001
        prefer-ip-address: true
        # Heartbeat detection and renewal time 
        # It was not set smaller during development , Ensure that the registry can remove the service even after the service is closed 
        #Eureka Time interval between client sending heartbeat to server , The unit is in seconds ( The default is 30 second )
        lease-renewal-interval-in-seconds: 1
        #Eureka The maximum waiting time of the server after receiving the last heartbeat , The unit is in seconds ( The default is 90 second ), Timeout will eliminate the service 
        lease-expiration-duration-in-seconds: 2

design sketch ：

At this time only payment8002.

explain Eureka Self protection has been turned off .

Be careful ：

In the case of cluster configuration , No such configuration is required for both server and client .