1. An overview of the

Based on the previous overview of the Spring Cloud series of four Eurekas and the service registry cluster, this article continues to introduce new Eureka content:

  • Important categories: cluster PeerAwareInstanceRegistryImpl
  • Impact of a new Eureka Server node added to the cluster
  • The impact of registering a new service Register
  • Renew Service Heartbeat
  • Services offline and removed
  • Self protection mode

2. Synchronize the Eureka Server cluster

2.1. Structure diagram of Eureka official website

The following operations need to be understood in combination with the following figure:

2.2. PeerAwareInstanceRegistryImpl

Cluster related important class com.net flix. Eureka. Registry. PeerAwareInstanceRegistryImpl: To ensure that the status of all Eureka Server nodes in the cluster is synchronized, all the following operations are synchronized to all services in the cluster: Registers, Renewals, Cancels, Expirations and Status Changes of services. Here are some partial methods:

  • SyncUp: When the Eureka Server is restarted or a new Eureka Server node is added, initialization is performed to obtain all instance registration information from other nodes in the cluster, so that the service can be provided normally. When Eureka Server starts, it gets all registration information from other nodes, and if it fails to get synchronization, it denies service for a period of time (this value is determined).
  • ReplicateToPeers: Registers, Renewals, Cancels, Expirations and Status Changes will be synchronized to all cluster nodes.
  • Register: Registers the instance and copies the instance information to all eureka server nodes. If other Eureka servers call this node, the instance information is updated only on this node, avoiding notifying other nodes to perform the update
  • Renew: Heartbeat, synchronize cluster
  • cancel
  • other

The states of Eureka Server clusters are asynchronously synchronized. Therefore, it is not guaranteed that the states of Eureka Server clusters are consistent, but the final state is basically guaranteed.

2.3. Impact after a New Eureka Server node is added to the cluster

When new nodes are added to the cluster, what will happen to the existing Eureka Server and Eureka Client and how will they discover new Eureka Server nodes?

  • Added Eureka Server: Added when Eureka Server is restarted or a new Eureka Server node is added, it obtains all instance registration information from other nodes in the cluster. If synchronization fails to be obtained, it will deny service for a certain period of time (determined by eureka. Server. Peer-eureka – nodess-update-interval-ms).
  • Existing Eureka Server and Service Consumer how to discover a new Eureka Server

    • Existing Eureka Server: Instance registration information is periodically synchronized between Eureka Servers. In this way, even if the new Application Service registers with only one Eureka Server in the cluster, over time all Eureka servers in the cluster will have information about this instance. How do Eureka Server nodes discover each other? Each node updates node information periodically (the time is determined by Eureka.server. Peer-eureka -nodes-update-interval-ms) to discover each other.
    • Service Consumer: When the Service Consumer starts, it reads the address information of the Eureka Server from the configuration file. When a Eureka Server is added to a cluster, how does the Service Provider discover the Eureka Server? The Service Consumer calls the Eureka Server cluster interface periodically (this value is determined by eureka-client-eureka-service-url-poll-interval-seconds). Get all Eureka Server information and update the local configuration.

2.4. Impact of new service registration

The Service Provider provides services externally and registers itself with the Eureka Server. If the configuration parameters of eureka. Client. RegisterWithEureka = true (default true), to the eureka Server registration for registration, eureka Server will save the registration information into memory.

Service Consumer in order to avoid each call to the Service request need to Eureka Server for a Service instance registration information, right now you need to set up Eureka. Client. FetchRegistry = true, it will be in the local cache all instances registration information. To ensure the validity of cached data, it periodically updates instances to the registry (the value is defined by eureka.client.registrie-fetch -interval-seconds, default is 30s).

2.5. Renew Service Heartbeat

The service instance periodically updates its status to the Eureka Server by renewing the heartbeat frequency (eureka. Instance. lease-renewal-interval-in-seconds specifies the heartbeat frequency. The default value is 30 seconds). When the Eureka Server receives the heartbeat, it notifies the other Eureka servers in the cluster to update the status of this instance. Service Provider/Service Consumer periodically updates cached instance information.

2.6. Services offline and removed

There are two cases of a service being taken offline:

  • When the Service Provider Service is shutdown, it notifies the Eureka Server to remove it, preventing clients from invoking the offline Service.
  • Eureka Server will be timed (eureka.server.eviction-interval-timer-in-ms, default is 0, instances will not be deleted by default) for checking. If the instance does not receive heartbeat within a certain period (defined by eureka.instance.lease-expiration-duration-in-seconds, 90s by default), the instance is deregister.

In this case, The maximum value of the Eureka Client is [eureka.instance.lease-renewal- interval-seconds +] Eureka.client. registry-fetch-interval-seconds] indicates that the service is offline. Similarly, after a new service is online, the service consumers of Eureka Client need at most the same amount of time to discover that the service is online

When the service goes offline, it will be updated to the cache of other nodes of Eureka Server and Eureka Client. The process is similar to the register process above

2.7. Self-protection mode

If the number of times that the Eureka Server receives a Renew in the last 1 minute is less than the threshold (the expected minimum value), the self-protection mode is triggered. In this case, the Eureka Server considers that the network is faulty and does not dereject any expired instances. When the number of times that the Eureka Server receives renew exceeds the threshold, the Eureka Server exits the self-protection mode.

Self-protection mode threshold calculation:

  • Expected number of heartbeats per instance = 60/ Heartbeat interval seconds per instance
  • Threshold = Sum of expected heartbeats of all instances registered to the service * self-protection coefficient

All the above parameters can be configured:

  • Instance Heartbeat interval: eureka.instance.lease-renewal-interval-in-seconds
  • Self-protection factor: Eureka.server. renewal- Percent-threshold

It is recommended to turn this option off if our instances are small and internal. We can also disable the self-preservation factor by eureka.server.enable-self-preservation = false

2.8 configure the demo

The demo configuration is as follows:

server: port: 10761 spring: application: name: Cloud-registration-center ## Eureka: primary configuration property in EurekaInstanceConfigBean and EurekaClientConfigBean PreferIpAddress: true; lease-renewal- interval-seconds: Lease -expiration-duration-in-seconds: 7 Client: # Disable eureka client # enabled: False # registerWithEureka: true # fetchRegistry: False # How often does the client update the Eureka Server information from the Eureka Server cluster eureka-service-url-poll-interval-seconds Registrie-fetch -interval-seconds: 5 registrie-fetch -interval-seconds: http://127.0.0.1:10761/eureka/ # set in eureka server address, can simultaneously to multiple service registration # defaultZone: http://192.168.21.3:10761/eureka/, http://192.168.21.4:10761/eureka/ server: # renewal - percent - threshold: 0.1 # disable self-preservation mode enable-self-preservation mode If enable-self-preservation=true, set this parameter to true. # renewal-percent-threshold: Eviction -interval-timer-in-ms, iction is designed to be used at any time. The default is 0 eviction-interval-timer-in-ms. If the Eureka Server fails to obtain the registration information from the neighboring Eureka Server, how long does it wait to provide the registration service? 6000000 # Time frequency for updating node information between clusters peer-eureka-nodes-update-interval-ms: 60000Copy the code

3. Code

Please use tag V0.5 instead of master as I can’t guarantee that the master code will always be the same