First of all, why did… Let’s look at what ZooKeeper is… ZooKeeper is an open source, highly available distributed application coordination service under the Apache Foundation that many companies use for service discovery….

However, in the cloud environment, the recovery capability in the face of device and network failures is a key issue to be considered. Therefore, when deploying applications to the cloud, you must anticipate hardware failures, network latency, and network partitions to build resilient systems. So why is it a mistake to use ZooKeeper for service discovery... The reason is as follows: In ZooKeeper, when a client node in a network partition fails to reach Quorum, it loses contact with ZooKeeper and thus cannot use its service discovery mechanism. As a result, ZooKeeper does not handle network partitioning well when used for service discovery. As a coordinating service, that's fine. For service discovery, however, information that may contain errors is better than no information at all. While client caching and other techniques can be used to remedy this deficiency, as companies like Pinterest and Airbnb have done, it does not solve the problem at the root if Quorum is completely unavailable, or if both cluster partitions and clients happen to be connected to healthy nodes that are not part of the Quorum, The client state will still be lost. More importantly, the essence of the above approach is to try to improve the availability of a consistent system with caching by building an AP system on top of a CP system, which is simply the wrong approach. Service discovery systems should be designed for availability from the start. CAP theory aside, ZooKeeper is so difficult to set up and maintain that Knewton has repeatedly had problems with incorrect use. Some seemingly simple things, such as rebuilding Watcher on the client side, handling sessions, and exceptions, are also very error-prone. In addition, ZooKeeper does have some problems, such as Zookeeper-1159 and ZooKeeper-1576.Copy the code

Because of these problems, they switched to Eureka. This is an open source service discovery solution developed by Netflix with high availability and resilience. By contrast… It has the following advantages…. If a server fails, Eureka does not require any kind of election and the client will automatically switch and connect to a new Eureka server. When it recovers, it can be automatically added to the Eureka node cluster. And it is designed to handle a wider range of network partitioning issues with zero downtime. In the event of a network partition, Eureka will continue to accept new registrations and publish. This ensures that the new service can still be used by any client on the same side of the partition. Eureka has a service heartbeat concept that prevents stale data: If a service has not sent a heartbeat for a long time, Eureka will remove it from the service registry. But when network partitions occur and Eureka loses too many clients in a short period of time, it deactivates this mechanism and goes into “self-protection mode.” When the network is restored, it automatically exits the mode again. In this way, while errors may exist in the data it retains, no valid data is lost. Eureka will have a cache on the client side. Service registration information is not lost even if all Eureka servers are unavailable. Caching is appropriate because it is only used if all Eureka servers are not responding. Eureka is built for service discovery. It provides a client library that provides service heartbeats, service health checks, automatic publishing, and cache flushes. With ZooKeeper, you need to implement these functions yourself. Management is simple and it is easy to add and remove nodes. It also provides a clear and concise web page listing all services and their health status. Eureka also provides a REST API that allows users to integrate it into other possible uses and query mechanisms. In short, cloud platforms are not always reliable… Service discovery needs to be as available and resilient as possible… And Eureka is designed for exactly that…