Service Discovery: Zookeeper vs etcd vs Consul

Service Discovery: Zookeeper vs etcd vs Consul

[Editor's note] This article compares three service discovery tools, Zookeeper, etec, and Consul, and explores the best service discovery solution for your reference only.

If you use a predefined port, the more services, the higher the possibility of conflict. After all, it is impossible for two services to listen to the same port. Managing a crowded column table of all ports used by hundreds of services is itself a challenge. After being added to this list, the databases and quantities required by these services will increase. Therefore, we should deploy a service that does not require a specified port and let Docker allocate a random port to us. The only problem is that we need to find the port number and let others know.

When we start to deploy services on one of the servers in a distributed system, things will become more complicated. We can choose to pre-define which server to run and which service method, however, this leads to many problems. We should do our best to use server resources as much as possible, but if we pre-define the deployment location of each service, it is almost impossible to use server resources as much as possible. Another problem is that automatic scaling of services will be very difficult, let alone automatic recovery, for example, Server failure. On the other hand, if we deploy the service to a running server with only a minimum number of containers, we need to add IP addresses to the data list, the data needs to be discovered and stored somewhere.

There are many other examples when we need to store and discover some information related to the services that are working.

To locate the service, we need at least two useful steps.

Service Registration-the information stored in this step includes at least the host and port information of the running service.

Service Discovery-this step allows other users to discover information stored during service registration.

In addition to the above steps, we also need to consider other aspects. If a service stops working and a new service instance is deployed/registered, should the service be canceled? What if there are multiple copies of the same service? How should we implement load balancing? What if a server goes down? All these problems are closely related to registration and development. Now, we are limited to the scope of service discovery (common names, around the above steps) and tools used for service discovery tasks, most of them use highly available Distributed Key/value storage.

Service Discovery tools

The main goal of the service discovery tool is to search for services and interact with each other. Therefore, the tool needs to know every service. This is not a new concept. Many similar tools existed before Docker, however, containers bring a new level of demand for these tools.

The basic idea behind service discovery is that each new instance (or application) of the service can identify the current environment and storage information. The stored registry information is usually in the format of key/value pairs. As service discovery is often used in distributed systems, this information is required to be scalable and support fault tolerance and all nodes in Distributed clusters. The primary purpose of such storage is to provide all interested parties with at least information such as service IP addresses and ports for mutual communication between them, this data is often extended to other types of information.

Service Discovery tools tend to provide APIs for service registration and service information search.

For example, we have two services: one is the provider and the other is the consumer of the first service. Once the service provider is deployed, we need to store the information in the service discovery registry. Then, when the consumer tries to access the service provider, it first queries the service registry and calls the service provider using the obtained IP address and port. To decouple the specific implementation of the service provider in the registry, we often use a proxy service. In this way, the consumer always requests information from a proxy with a fixed IP address, and the proxy uses service discovery in turn to find the service provider Information and redirect the request. In this article, we will implement the request through reverse proxy later. Now it is important to understand the service discovery process based on three roles (service consumers, providers, and proxies.

The service discovery tool looks for data. At least we should be able to find out where the service is located? Is the service healthy and available? What is the configuration? Since we are building a distributed system on multiple servers, this tool must be robust enough to ensure that the downtime of one node does not compromise data. At the same time, each node should have exactly the same data copy. Further, we hope to start the server, kill the service, or replace the new version of the service in any order, we should be able to reconfigure the service and view the corresponding data changes.

Let's take a look at some common options to accomplish the goals we set above.

Manual Configuration

Most services still need to be manually managed. We determine in advance where to deploy the service, how to configure and hope that the service will continue to work normally for whatever reason. Such a goal cannot be easily achieved. Deploying the second service instance means we need to start manual processing throughout the process. We need to introduce a new server or find out which server has low resource utilization, create a new configuration set and start the service. The situation may become more and more complex. For example, the response time of manual management caused by hardware failure may become slow. Visibility is another pain point. We know what Static configurations are. After all, we have prepared them in advance. However, most services have a lot of dynamically generated information, which is not easily visible, there is no separate place for us to refer to the data as needed.

The response time will inevitably slow down. As there are many mobile components that need to be manually processed, fault recovery and monitoring will become very difficult to manage.

Although in the past or when the number of services/servers was small, there was an excuse not to do this job. With the emergence of service discovery tools, this excuse no longer exists.

Zookeeper

Zookeeper is one of the oldest projects of this type. It originated from Hadoop and helped maintain various components in Hadoop clusters. It is very mature and reliable and used by many large companies (such as YouTube, eBay and Yahoo. The data storage format is similar to the file system. If the data is stored in a server cluster, Zookeper shares the configuration status across all nodes, and each cluster selects a leader, the client can connect to any server to obtain data.

The main advantage of Zookeeper is its maturity, robustness, and rich features. However, Zookeeper also has its own shortcomings. Using Java for development and complexity is the culprit. Although Java is great in many aspects, and then it is too heavy for this type of work, Zookeeper uses Java and a considerable number of dependencies make it very hungry for resource competition. Because of these problems, Zookeeper becomes very complex and maintenance requires more knowledge than what we expect from such applications. This is because of its rich features, but it has switched from its advantage to its burden. The more features and features the application has, the higher the possibility that these features will not be needed. Therefore, we will eventually pay the complexity cost for those features that are not needed.

Zookeeper paves the way for considerable improvements in other projects. "Big Data players" are using it because there is no better choice. Today, Zookeeper is already in the old state, so we have a better choice.

Etcd

Etcd is a key-Value Pair storage system using the HTTP protocol. It is a distributed and function-level configuration system that can be used to build a service discovery system. It is easy to deploy, install and use, and provides reliable data persistence features. It is secure and the documentation is complete.

Etcd is a better choice than Zookeeper because it is simple. However, it must be used with some third-party tools to provide service discovery.

Now, we have a place to store service-related information. We also need a tool to automatically send information to etcd. But why do we need to manually send the data to etcd? Even if we want to manually send the information to etcd, we usually do not know what the information is. Remember this, the Service may be deployed on a server running a minimum number of containers, and a port is randomly allocated. Ideally, this tool should monitor Docker containers on all nodes and update etcd whenever a new container is running or an existing container is stopped, registrator is one of the tools that can help us achieve our goals.

Registrator

Registrator automatically registers and registers the service by checking whether the container is online or stopped. Currently, it supports etcd, Consul, and SkyDNS 2.

Registrator and etcd are simple but powerful combinations and can run many advanced technologies. Every time we open a container, all data is stored in etcd and transmitted to all nodes in the cluster. We will decide what information is ours.

There is still one piece of the above-mentioned jigsaw puzzle game. We need to create a configuration file and store the data in etcd, and run some commands to create these configuration files.

Confd

Confd is a lightweight configuration management tool. It is commonly used to keep the configuration file up-to-date by using the data stored in etcd, consul, and some other data registries, it can also be used to reload the application when the configuration file changes. In other words, we can reconfigure all services with the information stored in etcd (or other registration centers.

Last thoughts on etcd, Registrator, and Confd combinations

When etcd, Registrator, and Confd are combined, you can obtain a simple and powerful method to automate all of our service discovery and required configurations. This combination also shows the effectiveness of the correct combination of "small" tools. These three things can accomplish what we need as we wish. If the range is slightly smaller, we will not be able to accomplish the goals we are facing, and the other side will introduce unnecessary complexity and server resource overhead if they take a larger scope into account during design.

Before we make our final decision, let's look at another tool combination with the same goal. After all, I should not be satisfied with some alternatives.

Consul

Consul is a highly consistent data storage service that uses gossip to form a dynamic cluster. It provides hierarchical key/value storage, which not only stores data, but also registers various tasks of the device, from sending data change notifications to running health checks and custom commands, the specifics depend on their output.

Unlike Zookeeper and etcd, Consul is embedded to implement a service discovery system, so you do not need to build your own system or use a third-party system. In addition to the features mentioned above, this discovery system also includes node health check and services running on it.

Zookeeper and etcd only provide original key/value queue storage, requiring application developers to build their own systems to provide service discovery. Consul provides an internal service discovery framework. The customer only needs to register the service and perform service discovery through the DNS or HTTP interface. The other two tools require a hand-prepared solution or third-party tools.

Consul provides out-of-the-box native support for multiple data centers. The gossip system not only works on nodes in the same cluster, but also works across data centers.

Consul also has another good feature that distinguishes it from other tools. It can be used not only to discover deployed services and the information of nodes on which they reside, but also through HTTP requests, TTLs (time-to-live) and custom commands provide extended health check features.

Registrator

Registrator has two Consul protocols, in which the consulkv protocol produces results similar to the etcd protocol.

In addition to the common IP addresses and ports stored in etcd or consulkv protocols, the Registrator consul protocol stores more information. We can get the information of the Service Running node, as well as the service ID and name. We can also store additional information with some additional environment variables according to certain labels.

Consul-template

Confd can be used for Consul as it works with etce, but Consul has its own template service, which is more compatible with Consul.

Through the information obtained from Consul, Consul-template is a very convenient way to create a file, and an additional benefit is that after the file is updated, you can run any command, just like confd, you can also use the Go template format for Consul-template.

Consul health check, Web interface, and data center

Monitoring the health status of cluster nodes and services is as important as testing and deploying them. Although we should work toward a stable environment with never-faults, we should also acknowledge that there will be unexpected faults at any time and we are always ready to take appropriate measures. For example, we can monitor the memory usage. If the threshold is reached, migrate some services to another node in the cluster, which is a precaution before a "disaster" occurs. On the other hand, not all potential faults can be detected and taken in a timely manner. A single service may be white, and a complete node may also stop working due to hardware failure. In this case, we should prepare to act as soon as possible, for example, replacing a node with a new service that fails to be migrated. Consul has a simple, elegant, but powerful way to perform health checks. When the health threshold reaches a certain number, it helps users define the actions they should perform.

If you search for "etcd ui" or "etec dashboard" on Google, you may find only a few available solutions. You may ask why we haven't introduced it to users yet. This is a simple reason, etcd is only used to store key/value pairs. Rendering data through a UI is not very useful, because we can easily obtain the data through etcdctl. This does not mean that the etcd UI is useless, but it will not have much impact due to its limited scope of use.

Consu is not just a simple key/value pair storage, as we have seen, in addition to storing simple key/value pairs, it also has a service concept and data. It can also perform health check, so it becomes a good candidate dashboard, where we can see the status and running services of our nodes. Finally, it supports the concept of multiple data centers. The combination of all these features allows us to see the necessity of introducing dashboard from different perspectives.

Through the Consul Web interface, you can view all the services and nodes, monitor the health check status, and read the set key/value pair data by switching the data center.

Thoughts on Consul, Registrator, Template, health check, and Web UI

Consul and the tools we discussed above provide better solutions in many cases than etcd. This is a simple and powerful solution designed for service architecture and discovery. It provides a complete and concise solution. In many cases, this is the best service discovery and a tool to meet health check requirements.

Conclusion

All these tools are based on similar principles and architectures. They run on nodes and need to be run by arbitration. They are highly consistent and all provide some form of key/value pair storage.

Zookeeper is one of the oldest ones. its service life shows its complexity, resource utilization, and goal, it is designed in a different era than the other tools we evaluate (even if it is not too old ).

Etcd, Registrator, and Confd are very simple but powerful combinations that can solve most problems, if not all of them meet service discovery needs. It also shows that we can combine very simple and specific tools to obtain powerful service discovery capabilities. Each of them executes a very specific task, communicate through well-designed APIs and have the ability to work relatively autonomously. microservices are used in both architecture and functional approaches.

The difference between Consul is that native support for multiple data centers and health checks is not required by third-party tools, which does not mean that third-party tools are not good. In fact, in this blog, we try our best to combine different tools by choosing tools that do better and do not introduce unnecessary features. Use the correct tool to get the best results. If the tool introduces features that are not required by the work, the work efficiency will decrease. On the other hand, it is useless if the tool does not provide the features required by the work. Consul balances the weight well and achieves the goal well by using a small amount of things.

Consul uses gossip to disseminate cluster information, making it easier to build than etcd, especially for big data centers. The ability to store data as a service makes it more complete and useful than only the key/value pairs of etcd (even if Consul has this option ). Although we can insert multiple keys in etcd to achieve the same goal, the Consul service achieves a more compact result, generally, you only need to perform one query to obtain all service-related data. In addition, Registrator implements two Consul protocols to merge them into one, especially adding Consul-template to the puzzle. Consul's Web UI provides a great way to visualize services and health checks.

I cannot say that Consul is a clear winner, but has a slight advantage over etcd. Service discovery, as a concept and tool, is quite new. We can expect many changes in this field. Adhering to the open mind, you can retain your attitude towards the suggestions in this article, try different tools, and draw your own conclusions.

Original article: Service Discovery: Zookeeper vs etcd vs Consul

(Translation: Hu Zhen)

========================================================== ========================================================== ==================

Description: Hu Zhen, former chief architect and CTO of an Internet Financial startup company, is now in charge of technical management and Architecture Design in the architecture group of Ping An financial technology center.

-------------------------------------- Split line --------------------------------------

Ubuntu 14.04 installs distributed storage Sheepdog + ZooKeeper

CentOS 6 installs sheepdog VM distributed storage

ZooKeeper cluster configuration

Use ZooKeeper to implement distributed shared locks

Distributed service framework ZooKeeper-manage data in a distributed environment

Build a ZooKeeper Cluster Environment

Test Environment configuration of ZooKeeper server cluster

ZooKeeper cluster Installation

-------------------------------------- Split line --------------------------------------

This article permanently updates the link address: