What is 1. Eureka
Eureka is a REST-based services, mainly for AWS cloud location service, in order to achieve load balancing and failover server transfer of the intermediate layer
In Spring Cloud micro-service architecture typically used as registration centers
We call this service for Eureka Server, as well as interact with a client called Eureka Client
2. Eureka High Level Architecture
As shown above, wherein
Application Server represents a service provider
Application Client represents the service consumer
Make Remote Call representing remote call
Eureka service on the registration, and then sends a heartbeat every 30 seconds to update their lease. If the client can not repeatedly renew the lease, it will be removed from the registry server in about 90 seconds. Registration information and updates are replicated to all nodes in the cluster eureka. The client from any district can find registry information (occurs every 30 seconds) to locate their services (possible in any area) and long-distance calls.
(PS: Eureka Client needs Eureka Server every 30 seconds to send a heartbeat, while the latest update registration information on Server locally, repeatedly if Server does not receive a heartbeat from the client, it will be removed in 90 seconds on the Server)
Communication between the client and the server 3. Eureka
Service Discovery has two modes: one is a client discovery mode, one is the server discovery mode. Eureka uses client discovery mode.
3.1. Register (Register)
Eureka client information about registering to run instances of the server Eureka. Registration occurs at the first heartbeat.
3.2. Renew (update / renew)
Eureka client needs to update the latest registration information (renewal), by sending a heartbeat every 30 seconds. Update Notification is to tell the Eureka server instances are still alive. If the server within 90 seconds did not see the update, it will be deleted from the registry instance. Recommended not to change the update interval because the server uses this information to determine whether the problem is widespread communication between the client and server exist.
3.3. Fetch Registry (crawl registration information)
Eureka client obtains information from the registry server and cached locally. After that, the client uses this information to locate other services. By acquiring the incremental update between the acquisition period and a current acquisition period, the information is updated (every 30 seconds) on a regular basis. When it is retrieved might return the same instance. Eureka client automatically repeats the process information.
3.4. Cancel (Cancel)
Eureka Eureka client sends the server a cancel shutdown request. This will remove the instance registry server instances, the instances effectively removed from the traffic.
4. Eureka limp home mode
If the server detects Eureka expected to exceed the number of registered clients in an elegant way not to terminate the connection, and at the same time are waiting to be deported, then they will go into self-protection mode. This is done to ensure that the catastrophic event does not erase the network eureka registry data, and propagated down to all clients.
Any client, if the update fails three consecutive beats, then it will be considered non-normal termination, wrong sentences will be removed. When more than 15% of currently registered instances of the client are in this state, then the self-protection will be turned on.
When the self-protection turned on, eureka server will stop excluding all instances, until:
- The number of heartbeats renew it sees back to the top of the expected threshold, or
- Self-protection is disabled
By default, self-protection is enabled, and the default threshold value is 15% greater than the number of currently registered
5. Eureka VS Zookeeper
5.1. Eureka assurance AP
Eureka is between server nodes, etc., as long as there is a node, you can provide normal service.
All operations Eureka clients may take some time to be reflected in Eureka server, and then reflected in the other Eureka client. That is, the client obtains the registration information may not be up to date, it does not guarantee strong consistency
5.2. Zookeeper guarantee CP
Zookeeper cluster has a Leader, multiple Follower. Leader is responsible for writing, Follower responsible for reading, ZK client to connect to any node are the same, the write operation will be synchronized later returned to complete after all the Follower. If the Leader hung up, then the re-election of a new Leader, during which the service is unavailable.
5.3. Why Eureka
Most distributed systems can be attributed to two problems: data consistency and prevent single point of failure. And then, even if do not agree within a period of time, there will not be much impact as the registry, so the choice between A and C A is more suitable for the scene.
6. Other relevant
7. References
https://github.com/Netflix/eureka/wiki/Understanding-eureka-client-server-communication