Comprehensive Service Discovery

Consul follows a server-agent architecture comprising the cluster of Consul nodes and the computers running applications (i.e., MySQL, Nginx, or any other tool) on which the associated Consul agent works. It registers the host services in the cluster so that they are listed in the service database in Consul.

If another service wants to use RabbitMQ, for example, it asks for the corresponding host for RabbitMQ in Consul and receives the appropriate answer. Consul also configures its own DNS entries so that legacy software is also able to cope with this system: The client, for example, always connects to the host _rabbitmq._amqp.service.consul, where Consul defines the address for a RabbitMQ host.

It's not easy to fool Consul: If an agent claims that MySQL is running on the local host, you can define your own health checks in Consul. Consul only forwards the host for MySQL to requesting clients if the MySQL server also responds to incoming monitoring requests. The parameters are arbitrary. If, for example, the load on the target host is too high, Consul notices this and diverts traffic to other hosts. Basically, Consul behaves like a well-configured load balancer that can also store the configuration of services on request.

Clustering Capabilities!

Like Etcd, Consul offers an inherent cluster mode. Unlike Etcd, Consul is equipped out of the box with support for real multi-data-center installations, although it also uses Raft to produce a consensus in the cluster.

Consul is familiar with three consistency models: In addition to the strictly consistent model, the default model is a compromise between forced consistency and the rare circumstances when a cluster reads information from the database that is no longer current.

The model is, however, consistent. The "stale" model allows Consul instances to edit requests themselves, even if they belong to a cluster partition without a majority in the quorum (Figure 5). Administrators can basically choose what they prefer: functionless Consul instances (because they have no majority in the quorum) or clients that might recover old input.

Figure 5: Like Etcd, Consul uses bootstrapping, in which system nodes agree as a first step.

In multi-data-center installations, each data center has its own Consul cluster and all clusters are loosely connected.

All cluster information is generally available to each Consul instance in each data center, but a data center failing never affects the Consul cluster at other locations. Because all Consul agents in a data center only talk to the Consul instances there, requests for other cluster partitions are forwarded within the Consul server.

Like Etcd, Consul also has bridges to the old world. Consul Template, introduced at the end of 2014, provides an option to generate template-based configuration files for services. Consul Template is a standalone service similar to confd in Etcd.

ZooKeeper

ZooKeeper is sort of the "grandpa" among the subjects. The project, which is under the Apache umbrella, has the longest history of all the tested tools. Not surprisingly, various features in Etcd and Consul are clearly tailored to offer functionality that appears to be missing in ZooKeeper. ZooKeeper certainly has a powerful circle of supporters, though: The project, which once belonged to Hadoop, is used by large companies such as Rackspace and eBay. The already typical division into several components is also found in ZooKeeper. First, ZooKeeper is equipped with a service for holding configuration data. Although it also offers a RESTful interface, it is currently marked as experimental. The developers prefer to see it when users access ZooKeeper using the tested Java or C clients.