Choosing Between Zookeeper and Eureka as Service Registry: Principles, Advantages, and Implementation

In microservice architecture, a registry center acts as a directory, recording the mapping between services and their network addresses, enabling loose coupling and dynamic discovery.

The article first outlines the problems of monolithic systems and introduces the three roles of a registry center: service provider, service consumer, and the registry itself, as well as their interactions.

It then compares two popular registry implementations, Zookeeper and Eureka, highlighting that Zookeeper follows the CP model (strong consistency, tolerant to network partitions) while Eureka follows the AP model (high availability, eventual consistency).

Zookeeper Overview

Zookeeper provides distributed configuration, synchronization, and naming services. It ensures data consistency by electing a leader and using a quorum for writes. The article describes the leader election process and presents key code snippets.

public void run() {
    try {
        /* Main loop */
        while (running) {
            switch (getPeerState()) {
                case LEADING:
                    LOG.info("LEADING");
                    try {
                        setLeader(makeLeader(logFactory));
                        leader.lead();
                        setLeader(null);
                    } catch (Exception e) {
                        LOG.warn("Unexpected exception", e);
                    } finally {
                        if (leader != null) {
                            leader.shutdown("Forcing shutdown");
                            setLeader(null);
                        }
                        setPeerState(ServerState.LOOKING);
                    }
                    break;
            }
        }
    } finally {
    }
}

The lead() method shows how the leader calculates a new epoch, synchronizes data, and starts the Zookeeper server.

void lead() throws IOException, InterruptedException {
    try {
        // omitted
        cnxAcceptor = new LearnerCnxAcceptor();
        cnxAcceptor.start();
        readyToStart = true;
        long epoch = getEpochToPropose(self.getId(), self.getAcceptedEpoch());
        zk.setZxid(ZxidUtils.makeZxid(epoch, 0));
        waitForEpochAck(self.getId(), leaderStateSummary);
        self.setCurrentEpoch(epoch);
        try {
            waitForNewLeaderAck(self.getId(), zk.getZxid(), LearnerType.PARTICIPANT);
        } catch (InterruptedException e) {
            // omitted
        }
        startZkServer();
        // omitted
    } finally {
    }
}

For the follower side, the run() method demonstrates how a follower connects to the leader, receives the epoch, and synchronizes data.

public void run() {
    try {
        while (running) {
            switch (getPeerState()) {
                case FOLLOWING:
                    try {
                        LOG.info("FOLLOWING");
                        setFollower(makeFollower(logFactory));
                        follower.followLeader();
                    } catch (Exception e) {
                        LOG.warn("Unexpected exception", e);
                    } finally {
                        follower.shutdown();
                        setFollower(null);
                        setPeerState(ServerState.LOOKING);
                    }
                    break;
            }
        }
    } finally {
    }
}

Eureka Overview

Eureka, an open‑source service registry from Netflix, follows the AP principle and uses a peer‑to‑peer architecture without a single master. Each Eureka server replicates registration data to its peers, providing high availability even when some nodes fail.

The article lists four practical points: client registration, peer communication, automatic failover, and self‑preservation mode.

Configuration examples for a three‑node Eureka cluster are provided, showing YAML/YML style settings for ports, service IDs, instance information, peer URLs, heartbeat intervals, and disabling self‑preservation during testing.

### Eureka01 configuration
server:
  port: 8000
spring:
  application:
    name: eureka-server
eureka:
  instance:
    hostname: 127.0.0.1
  client:
    serviceUrl:
      defaultZone: http://127.0.0.1:8100/eureka/
    register-with-eureka: true
    fetch-registry: true
server:
  enable-self-preservation: false
  eviction-interval-timer-in-ms: 2000

Similar snippets are shown for Eureka02 and a client application that registers with both servers.

Conclusion

Zookeeper guarantees strong consistency (CP) but may become unavailable during leader election or when a majority of nodes are down, while Eureka sacrifices consistency (AP) to maintain availability, returning cached data when necessary. For a service registry that rarely changes configuration, AP (Eureka) is often more suitable, though many projects still use Zookeeper due to smaller cluster sizes and acceptable risk.