"Go" Spring cloud Eureka parameter configuration

Eureka.client.registry-fetch-interval-seconds

Indicates how often Eureka client interval to pull the service registration information, the default is 30 seconds, for Api-gateway, if you want to quickly get the service registration status, you can reduce the value, such as 5 seconds

Eureka.instance.lease-expiration-duration-in-seconds

Leaseexpirationdurationinseconds, which indicates that Eureka server first receives the client's heartbeat, waits for the next heartbeat timeout, and then removes the instance if the next heartbeat is not received.

• Default is 90 seconds

• If the value is too large, it is very likely that the traffic will be forwarded to the past, the instance has not survived.

• If the value is set too small, then instance is likely to be removed due to temporary network jitter.

• The value should be at least greater than leaserenewalintervalinseconds

Eureka.instance.lease-renewal-interval-in-seconds

Leaserenewalintervalinseconds that indicates how often the Eureka client sends the heartbeat to the server side. If the server side does not receive a heartbeat from the client after Leaseexpirationdurationinseconds, the instance will be removed. In addition, if the instance implements the Healthcheckcallback and decides to let itself unavailable, the instance will not receive traffic.

• Default 30 seconds

Eureka.server.enable-self-preservation

Whether to turn on self-protection mode, which is true by default.

By default, if Eureka server does not receive a heartbeat for a microservices instance for a certain amount of time, Eureka server will unregister the instance (the default is 90 seconds). However, when a network partition failure occurs, the MicroServices and Eureka Server can not communicate properly, the above behavior can become very dangerous-because the microservices itself is actually healthy, at this time should not unregister the micro-service.

Eureka solves this problem through "self-protection mode"-when the Eureka server node loses too many clients in a short period of time (a possible network partition failure), the node enters a self-protected mode. Once in this mode, Eureka Server protects the information in the service registry and no longer deletes the data in the service registry (that is, it does not unregister any microservices). When a network failure is restored, the Eureka server node automatically exits self-protected mode.

In conclusion, self-protection mode is a kind of security protection measure to deal with network anomaly. Its architectural philosophy is rather to keep all microservices at the same time (healthy microservices and unhealthy microservices will remain), nor blindly write off any healthy microservices. Using the self-protection mode, you can make the Eureka cluster more robust and stable.

Eureka.server.eviction-interval-timer-in-ms

Eureka Server cleans up the time interval for invalid nodes, default 60000 milliseconds, which is 60 seconds

Go Spring cloud Eureka parameter configuration