If you see the following tips in this Eureka Server home page, then Eureka has entered the 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.
Protected mode is mainly used for protection in the presence of network partition scenes or network problems between a group of clients and Eureka Server. Once in protected mode, Eureka Server will try to protect its information service registry, delete data no longer service registry (which is not written off any micro-services).
How to solve Eureka Server node has been shut down is not kicked out of the question
During development, we often want to Eureka Server can quickly and effectively kicked out of the node has been shut down, but the novice because the Eureka self-protection mode, and the reason for the long cycle of the heartbeat, often encounter Eureka Server has not kicked shut down problem nodes.
Solutions are as follows:
(1) Eureka Server side: Configuring shut down to protect themselves, and demand configuration Eureka Server node to clean up invalid time interval.
self--eureka.server.enable Preservation # set to false, shut down to protect themselves eureka.server.eviction -interval-timer- in -ms # cleanup interval (in milliseconds, the default is 60 * 1000 )
(2) Eureka Client side: open configuration health check, update and renew demand configuration time and expiration time.
eureka.client.healthcheck.enabled # open health check (need-the Boot-starter- the Spring Actuator dependent) eureka.instance.lease -renewal-interval- in - seconds The # renewal update interval (default 30 seconds) eureka.instance. Lease -expiration-duration- in -seconds # renew the expiration time (default 90 seconds)
Note:
Change the frequency of updates Eureka will break the self-protection function server in a production environment is not recommended to customize these configurations.