Eureka project of self-protection mode SpringCloud

By default, if Eureka Server does not receive a heartbeat micro service instances within a certain time, Eureka Server will log off the instance (default 90 seconds). But when the network partition failure occurs between the micro and the Eureka Server service can not communicate, above behaviors may become very dangerous - because micro service itself is actually healthy, then this should not be written off this micro-services.

Eureka to solve this problem through the "limp home mode" - when the Eureka Server node losing too much in a short time a client (network partition failure may have occurred), then the node goes into self-preservation mode. Once in this mode, Eureka Server service will protect the information in the registry, delete data no longer service registry (which is not written off any micro-services). When the network fault recovery, the Eureka Server node will automatically exit the self-protection mode.

In summary, the self-protection mode is a security measure to respond to network anomalies. Its architecture is rather philosophy while retaining all micro-services (health services and unhealthy micro-micro services will be kept), nor blindly cancellation of any healthy micro-services. Use self-protection mode, allowing Eureka clusters more robust and stable.

In Spring Cloud can be used eureka.server.enable-self-preservation = false to disable self-protection mode.

 

Self-protection into the visual performance is as follows:

 

The official description is as follows:

When a Eureka server is started, it will try to get all the registration information from a neighboring node,

If you get information from a neighbor in the problem, the server will try to obtain from other nodes until all nodes have failed.

If this service successfully acquired from other nodes to the registration information, it is a flush threshold (heartbeat threshold) based on these settings.

If a moment, the heart rate is below a threshold percentage of the value of this service will stop removing instance, to protect information about the current instance is already registered, that is, into self-preservation mode.

 

Specific self-protection logic is as follows:

1. Suppose two client registered to Eureka server, each client sends a heartbeat every 30s, the server takes a minute received four beats. Based on this spring added to a minimal value 1 beat (by setting eureka.instance.registry.expectedNumberOfRenewsPerMin), this way, the minimum heart rate became 5, and this value is multiplied by a minimum threshold required percentage 0.85 (eureka .server.renewalPercentThreshold), and it is approximately the smallest integer larger than itself * 0.85 = 4.25 5 -> 5. This threshold will be updated every 15 minutes (by setting eureka.server.renewalThresholdUpdateIntervalMs), thus the heart rate at any time point within 15 minutes in this server received less than five times, the server proceeds to self-preservation mode, and stop removing the instance information. 
2. Eureka server is assumed that each client is sent at a fixed frequency heartbeats per 30s. If the two registered client, server to receive a desired one minute (2 + 2 + 1) * 0.85 = 5 beats, if the received number is smaller than this value, it will activate the self-preservation mode. Suppose now that each client sends heart beat much faster (10s once), server will receive 12 times in one minute, even if there is a service goes down, also received six times, still greater than the expected five times, so do not will trigger self-preservation mode would have fired, which is why no official proposed changes eureka.instance.leaseRenewalIntervalInSeconds value.