Introduction to the
Eureka itself is an open source Netflix service registration and discovery product that comes with a Java package.
In its implementation, nodes are equal to each other, and the failure of some registry nodes does not affect the cluster, even if only one node remains in the cluster, it can still provide discovery services. Eureka Clients caches information about service invocations even if all service registration nodes are down. This ensures that our calls to each other between microservices are robust.
Zookeeper provides open source distributed configuration services, synchronization services, and name registration for large-scale distributed computing. What was once a subproject in the Hadoop project to control data in the cluster has been upgraded to a stand-alone top-level project. It is also used in many scenarios as a Service discovery Service solution.
contrast
There is a famous CAP theorem in distributed systems (C- data consistency; A- Service availability; Fault tolerance of p-service to network partition failure, these three characteristics cannot be satisfied in any distributed system at the same time, at most two at the same time);
Zookeeper
Zookeeper is designed based on CP, that is, the access request to Zookeeper at any time can obtain consistent data results, and the system is fault-tolerant to network segmentation, but it cannot guarantee the availability of each service request.
From a practical point of view, when Zookeeper is used to obtain the service list, if Zookeeper is selecting the master or more than half of the machines in the Zookeeper cluster are unavailable, data cannot be obtained. Therefore, Zookeeper cannot guarantee service availability.
Of course, in most distributed environments, especially when it comes to data storage, data consistency should be guaranteed first, which is why ZooKeeper is designed to be CP.
For service discovery scenarios, however, the situation is different: even if different nodes in the registry store different information about service providers for the same service, the consequences are not catastrophic. For service consumers, the ability to spend is the most important thing — it’s better to try and consume a service instance if you have information that may not be correct than not to consume because you can’t get instance information. (Try and fail quickly, then update the configuration and try again.) So availability is more important for service discovery than data consistency — AP trumps CP.
Eureka
Spring Cloud Netflix followed AP principles when designing Eureka. Eureka Server can also run multiple instances to build a cluster and solve a single point problem. However, unlike ZooKeeper’s leader election process, Eureka Server uses peer-to-peer communication.
This is a decentralized architecture. There is no master/slave distinction and each Peer is Peer. In this architecture, nodes improve availability by registering with each other, and each node needs to add one or more valid ServiceurLs to point to other nodes. Each node can be treated as a copy of another node.
If a Eureka Server goes down, requests from the Eureka Client are automatically switched to the new Eureka Server node. After the Server is recovered, The Eureka Server is managed by the Server cluster again. When a node starts receiving a client request, all operations are replicated to a replicateToPeer (node to node replication) operation that replicates the request to all other nodes currently known to the Eureka Server.
When a new Eureka Server node is started, it first attempts to obtain all instance registry information from neighboring nodes to complete initialization. Eureka Server obtains all nodes through the getEurekaServiceUrls() method and updates them periodically through heartbeat renewal.
By default, if the Eureka Server does not receive the heartbeat of a service instance within a certain period of time, the Eureka Server will log out of the instance (90 seconds by default). Run the eureka.instance.lease-expiration- durations-in-seconds command to configure the timeout duration. When a Eureka Server node loses too many heartbeats in a short period of time (such as a network partition failure), the node goes into self-protection mode.
Follow the public account Java Technology Stack, reply: Cloud, you can get a series of Spring Cloud tutorials I put together.
“What is the self-protection model?”
By default, the Eureka Server triggers self-protection if the number of heartbeat renewals received by the Eureka Server per minute is lower than a threshold (number of instances/number of heartbeat intervals per instance) and the self-protection coefficient lasts for 15 minutes. In self-protection mode, Eureka Server protects the information in the service registry and does not deregister any service instances.
When the number of heartbeats it receives rises above the threshold, the Eureka Server node automatically exits self-protection mode. Its design philosophy, as mentioned earlier, is that it is better to retain incorrect service registration information than to blindly unregister any potentially healthy service instances.
This mode can be disabled by eureka.server.enable-self-preservation = false, and eureka.instance.lease-renewal-interval-in-seconds can be used to change the heartbeat interval. The eureka.server.renewal- Percent-threshold can be used to change the self-protection coefficient (0.85 by default).
Specific combat can refer to the article “Spring Cloud Eureka self-protection mechanism combat”.
conclusion
ZooKeeper is based on CP and does not guarantee high availability. If ZooKeeper is selecting an owner or more than half of the machines in the ZooKeeper cluster are unavailable, data cannot be obtained. Eureka is ap-based and highly available, allowing access to locally cached data even when all machines are down.
As a registry, the configuration does not change very often, only when the release and machine failure. CP is not appropriate for configurations that change infrequently, and aps can sacrifice consistency to ensure availability when they encounter problems, both by returning old data and caching data.
So Eureka is ideally suited to be a registry.
In a real world, most projects would probably use ZooKeeper because the cluster is not large enough and you rarely get to the point where more than half of the machines used as registries hang up. So it’s not really a big deal.
