spring cloud eureka parameter configuration

1.eureka.client.registry-fetch-interval-seconds
      indicates how long the eureka client takes to fetch service registration information. The default is 30 seconds. For api-gateway, if you want to quickly obtain the service registration status, you can reduce the value, such as 5 Seconds

2.eureka.instance.lease-expiration-duration-in-seconds
      leaseExpirationDurationInSeconds means that the eureka server waits for the timeout time for the next heartbeat after receiving the client's last heartbeat. If the next heartbeat is not received within this time, then The instance will be removed.

      The default is 90 seconds.
      If the value is too large, it is likely that the instance will no longer survive when the traffic is forwarded.
      If the value is set too small, the instance is likely to be removed due to temporary network jitter.
      The value should be at least greater than leaseRenewalIntervalInSeconds
3.eureka.instance.lease-renewal-interval-in-seconds
      leaseRenewalIntervalInSeconds, indicating the frequency of the eureka client sending heartbeats to the server. If the server does not receive the client's heartbeat after leaseExpirationDurationInSeconds, the instance will be removed. In addition, if the instance implements HealthCheckCallback and decides to make itself unavailable, the instance will not receive traffic.

The default is 30 seconds
. 4.eureka.server.enable-self-preservation
     Whether to enable self-preservation mode, the default is true.
      By default, if Eureka Server does not receive a heartbeat from a microservice instance within a certain period of time, Eureka Server will log out of the instance (default 90 seconds). However, when a network partition failure occurs, the microservice and Eureka Server cannot communicate normally, and the above behavior may become very dangerous-because the microservice itself is actually healthy, the microservice should not be logged out at this time.
      Eureka solves this problem by "self-protection mode" - when an Eureka Server node loses too many clients in a short period of time (a network partition failure may occur), then the node will enter self-protection mode. Once in this mode, Eureka Server will protect the information in the service registry and will no longer delete the data in the service registry (that is, no microservices will be unregistered). When the network failure recovers, the Eureka Server node will automatically exit the self-protection mode.
      To sum up, the self-protection mode is a security protection measure to deal with network anomalies. Its architectural philosophy is to prefer to keep all microservices at the same time (both healthy and unhealthy), rather than blindly deregister any healthy microservices. Using the self-protection mode can make the Eureka cluster more robust and stable.

5.eureka.server.eviction-interval-timer-in-ms
   The interval for the eureka server to clear invalid nodes, the default is 60000 milliseconds, that is, 60 seconds

6. Test environment reference configuration
eureka server
eureka:
  server:
    enable-self-preservation: false # Disable self-protection mode (default is on)
    eviction-interval-timer-in-ms: 5000 # Renewal time, that is, the interval for scanning invalid services (default is 60*1000ms)
eureka client
eureka:
  instance:
    lease-renewal-interval-in-seconds: 5 # Heartbeat time, i.e. service renewal interval (30s by default)
    lease-expiration-duration-in-seconds: 10 # Daze time, i.e. service renewal Approximate expiration time (default is 90s)
  client:
    healthcheck:
      enabled: true # Enable health check (depending on spring-boot-starter-actuator)
zuul
eureka:
  client:
    registry-fetch-interval-seconds: 5 # Default is 30 seconds