springboot-eureka exchange mechanism

I. Introduction

The article made reference to official documents, mainly describes the exchange mechanism between the eureka client and eureka server; peer to peer to peer replication of the exchange mechanism;

eureka official documents

Exchanges between the two server client

Communication between the client and the server euraka mainly by the following aspects;

2.1 Register

Register (service registry); Eureka client will be registered information on self running instance of the Eureka server, such as ip address, host name, health status;

2.2 Renew

Renew (service contract); Eureka client will Eureka server 30 seconds to every send heartbeat; renewal notification object they represent examples of Eureka server is in the living state; Eureka server if the heartbeat is not received within 90 seconds renewal, this example will be removed from the list of services; official advice is not to modify the renewal interval, because the server you want to use this information to confirm the exchange between Eureka server and Eureka client whether widespread problem;

2.3 Fetch Registry

Fetch Registry (crawl registration list); Eureka clients will crawl from the list of services registered in Eureka server and cached locally; Eureka clients cache the list of local service information will be updated regularly at intervals of 30 seconds increment information (last catch take the current listing service between the different information crawled); delta typically Eureka server saves information for three minutes; therefore, Eureka clients each incremental crawls service information may be the same instance; Eureka client automatically the process repeats information;

If the information is in the lead for some reason does not match the crawl, Eureka Client will re-fetch the list of registered service information; information is captured Eureka json or xml format, usually josn format, and to be a compressed information, the compressed information is not compressed fine information is the same, the compression is to reduce the volume of the object, to improve performance;

2.4 Cancel

The Cancel (offline service); the Eureka client sends a request to the offline Eureka server, Eureka server instance of the client will be removed from the registration list; offline transmission request code as follows:

DiscoveryManager.getInstance().shutdownComponent()

2.5 Time Lag

Time Lag (time difference); all Eureka client operations will next reaction to Eureka Server or other Eureka client; Eureka server since the information is cached and updated in accordance with the effective period of time, Eureka Client will increment periodically updated information according to time period; Thus, information may occupy about 2 minutes to transmit all of the updated Eureka Client;

Exchanges among the three peer to peer

3.1 Troubleshooting

Communication between the Eureka Eureka clients and server exchange between the same zone; zone, or if the server is not the same problem occurs in, client will fail over to the other server process Zone, each node will have in a for special processing zone fault;

3.2 peer to peer

If the server started to accept traffic, Eureka client all operations are executed on the server cluster node near a server will attempt to replicate the known information into their own node; if Eureka clinet operation fails for some reason, this information it will be left over until the next heartbeat coordinate the heartbeat will be replicated between the server;

If the server is started, it will attempt to get information about replicate in the vicinity of a node over; if you copy over information from this node problems, will give up with peer to peer (peer replication); if the client renewal time low a threshold value (less than 85% within 15 minutes), then the server will stop these expired client to protect information has been registered;

peer to peer is the eureka self-protection mechanism; when the presence of network partitions between Eureka client with the Eureka server, Eureka server will protect the saved information at this time Eureka client can not register itself with the Eureka server, the best approach It is trying to register themselves with other Eureka server; server can not be obtained in this case from a nearby node registration information, then will wait 5 minutes for the client registration information, so traffic is tilted to a group instance, will cause capacity problems;

Disconnection between 3.3 peer

Peer between a case where disconnection occurs:

1. Heartbeat replication between peers will fail, server will check into this and into the self-protection mechanism to protect the information currently already saved;

2. server will be isolated cases, in other words some Eureka Client will receive a new registration information, while others can not receive; that is, we often say that the loss of data;

3. When the network is restored and stable, can be healthy exchange between peers, registration information is automatically synchronized to the other server;