Eureka source code analysis

Thinking about the Problems

What kind of a way to use Eureka registry to store machine address and port number sent by each service when registering?
Each service to find Eureka Server pulled registry when what frequency?
Each service is how to pull the registry?
A few hundred service, large distributed systems deployed thousands of machines, and how much would Eureka Server Access pressure?
Eureka Server Technically how withstood ten million visits a day?

Notes premise

Eureka Client Components within each service, by default, every 30 seconds a request is sent to the Eureka Server, to pull recent change in the service information.
Eureka has a heartbeat mechanism, each Eureka Client will be sent once every 30 seconds to beat Eureka Server, inform people say, buddy, my service instance is still alive! If a Eureka Client for a long time did not send a heartbeat to Eureka Server, then it shows that the service instance has hung up.

Eureka heartbeat mechanism .png

Eureka Server registry to store configuration

Assume a set of large-scale distributed systems, a total of 100 services, each deployed on 20 machines, the machine is 4-core 8G standard configuration. You deployed the equivalent of a total of 100 * 20 = 2000 service instances, there are 2000 machines.
Internal service instance on each machine has a Eureka Client component, it will request once every 30 seconds Eureka Server, pulling registry changes. Further, Eureka Client will on each service instance every 30 seconds to transmit a heartbeat request Eureka Server.

Standard algorithms, each service instance requests per minute secondary pulling registry, heartbeat request transmitted twice per minute.
Such a service instance requests 4 times per minute, 2000 8000 requests service instances per minute.
Converted to per second, it is 8000/60 = 133 times or so, we probably estimate for the Eureka Server will be requested 150 times per second.
That day, then, is 8000 * 60 * 24 = 11,520,000, that is, ten million visits a day.

So a proper pull by setting the registry and send the heartbeat, can ensure that large-scale systems in the request will not be much pressure Eureka Server.

Source analysis

Memory Registry class .png

As shown above, the figure called the registry the name of CocurrentHashMap, the registry is the core structure.
We can see from the code, Eureka Server registry based on pure memory, which maintains a data structure in memory directly.
Registration, service off the assembly line, service failures each service, all will maintain and update the registry in memory.
Each service every 30 seconds pulling the registry when, Eureka Server is stored directly in memory of a change of registry data to them on it.
Similarly, every 30 seconds to initiate a heartbeat, the heartbeat is updated at this time pure memory Map data structure.

registry data structure

First of all, this service is ConcurrentHashMap of key names, such as "xxx-service", is a service name.
value represents a multiple service instances of a service.
Example: for example, "xxx-service" can have three service instances, each instance of the service deployed on a single machine.

As the Map value of

Map<String, Lease<InstanceInfo>>

The Map is the key service instance id
Lease value is a class called, it is a generic InstanceInfo stuff is called.
InstanceInfo, we see to know the name of justice, on behalf of the InstanceInfo service instance specific information, such as machine ip address, hostname and port number.
Lease, which will maintenance time for each service sent last heartbeat

Eureka Server-side multi-level caching mechanism

Eureka Server while reading and writing in order to avoid concurrency conflicts caused by memory data structure, using a multi-level caching mechanism to further improve the response speed of the service request.

Pulling the registry:

First, check the cached in the registry from ReadOnlyCacheMap.
If not, find ReadWriteCacheMap in cache registry.
If you do not, you get the actual registry data from memory.

Steps to change the registry occur:

Will update the registry data changes in memory, while the expired out ReadWriteCacheMap.
This process does not affect ReadOnlyCacheMap provide people query the registry.
A period of time (default 30 seconds), pull each service registry will directly read ReadOnlyCacheMap.
After 30 seconds, the background thread Eureka Server discovery ReadWriteCacheMap has cleared, the cache will be cleared ReadOnlyCacheMap.
Next time there is a pull service registry, will get the latest data from memory, and at the same time filling each cache.

What are the advantages of multi-level caching mechanism is?

As far as possible to ensure that the registry data memory read and write without frequent conflicts.
And further to ensure that a large number of requests Eureka Server, are quick to go from pure memory, high performance.

Multi-level caching mechanism .png

to sum up

Eureka request by setting the appropriate frequency (pulling registry 30-second intervals, send heartbeat intervals of 30 seconds), can ensure a large number of system request Eureka Server hundreds per second.
At the same time by pure memory registry to ensure that all requests are processed in memory to ensure high performance.
In addition, multi-level caching mechanism ensures that no concurrency conflicts for frequent memory data structure of read and write operations to further enhance performance.

Reproduced in: https: //www.jianshu.com/p/fcda678e8bf4