Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to achieve a registry in ZooKeeper". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Implementation registry API

According to the description of registry principles, the registry must provide the following basic API, such as:

Service registration interface: the service provider completes service registration by invoking the service registration interface.

Service anti-registration interface: the service provider completes the service unregistration by invoking the service anti-registration interface.

Heartbeat reporting interface: the service provider reports the node survival status by calling the heartbeat reporting interface.

Service subscription interface: service consumers complete service subscription by calling service subscription interface to obtain a list of available service provider nodes.

Service change query interface: service consumers get the latest list of available service nodes by calling the service change query interface.

In addition, in order to facilitate management, the registry must also provide some background managed API, such as:

Service query API: query which service information is currently registered in the registry.

Service modification interface: modifies the information of a service in the registry.

Cluster deployment

As a bridge between service providers and service consumers, the importance of registry is self-evident. Therefore, registries generally use cluster deployment to ensure high availability, and through distributed consistency protocols to ensure that the data between different nodes in the cluster are consistent.

Take the open source registry ZooKeeper as an example, the ZooKeeper cluster contains multiple nodes, and service providers and service consumers can communicate with any node because their data must be the same. Why? This starts with how ZooKeeper works:

Each Server stores a piece of data in memory, and Client's read request can request any Server.

When ZooKeeper starts, a leader (Paxos protocol) is elected from the instance.

Leader handles operations such as data updates (ZAB protocol).

An update operation succeeds if and only if most Server are successfully modified in memory.

In this way, ZooKeeper ensures high availability and data consistency.

Catalog storage

Taking ZooKeeper as an example, registries generally use a hierarchical directory structure to store service information:

Each directory is called znode in ZooKeeper, and it has a unique path identification.

Znode can contain data and child znode.

There can be multiple versions of the data in the znode. For example, if there are multiple versions of the data stored in a znode, you need to bring the version information to query the data under this path.

Service health status detection

In addition to supporting the most basic service registration and service subscription functions, the registry must also have the health status detection function of the service provider node, so as to ensure that all the service nodes stored in the registry are available.

Or take ZooKeeper as an example, it is based on the ZooKeeper client and server persistent connection and session timeout control mechanism to achieve service health detection.

In ZooKeeper, when a connection is established between the client and the server, the session is established and a globally unique Session ID is generated. The server and the client maintain a long connection. During the SESSION_TIMEOUT cycle, the server will detect whether the link with the client is normal. The specific method is that the client sends heartbeat messages (ping messages) to the server regularly, and the server resets the next SESSION_TIMEOUT. If the server does not receive the heartbeat message from the client after the SESSION_TIMEOUT is exceeded, the server thinks that the Session is over, and the ZooKeeper will think that the service node is no longer available and will delete its information from the registry.

Notification of change in service status

Once the registry detects that a service provider node has been added or removed, it must immediately notify all service consumers who subscribe to the service and refresh the locally cached service node information. ensure that service invocations do not request unavailable service provider nodes.

Continue to take ZooKeeper as an example, based on ZooKeeper's Watcher mechanism, to achieve service status change notification to service consumers. When service consumers call the getData method of ZooKeeper to subscribe to the service, they can also obtain the changes of the service through the process method of the listener Watcher, and then call the getData method to obtain the changed data and refresh the locally cached service node information.

Whitelist mechanism

In the actual testing and deployment of micro-services, it usually includes multiple environments, such as a production environment and a test environment. When developers conduct business self-testing and testing, when conducting regression testing, they generally use the test environment, and the deployed RPC Server nodes are registered with the test registry cluster. However, it is common for developers or tests to mistakenly register the service nodes in the test environment with the online registry cluster during deployment, so that online traffic will be called to the RPC Server nodes in the test environment, which may cause unexpected consequences.

To prevent this from happening, the registry needs to provide a protection mechanism. You can think of the registry as a room with access control, which can only be entered by RPC Server with an access card. In practical application, the registry can provide a whitelist mechanism, and only the RPC Server added to the whitelist of the registry can call the registration interface of the registry, which can prevent the nodes in the test environment from accidentally running into the online environment.

Solution

At present, there are two main solutions for service registration and discovery:

In-application registration and discovery: the registry provides the SDK of the server and the client. Business applications realize the registration and discovery of services by introducing the SDK provided by the registry and interacting with the registry through SDK.

Out-of-application registration and discovery: business applications themselves do not need to deal with the registry through SDK, but interact with the registry in other ways to indirectly complete service registration and discovery.

The difference between the two solutions lies in the application scenario. The solution in the application is generally suitable for service providers and service consumers who belong to the same technical system. The out-of-application solution is generally suitable for business scenarios where service providers and service consumers adopt different technology architectures. For example, the service provider provides C++ service, while the service consumer is a Java application. In this case, the adoption of an out-of-application solution does not depend on a specific technology system. At the same time, for containerized cloud applications, it is generally not suitable to adopt the solution of SDK in the application, because it will invade the business, and the solution outside the application can solve this problem.

High availability of registry selection

As a communication link between service providers and service consumers, the high availability of registry is very important. Just imagine, if the registry is not available, service providers will not be able to expose their services, and service consumers will not be able to know the specific address of the service they want to invoke. There are two main ways to achieve high availability:

Cluster deployment, as the name implies, ensures high availability by deploying multiple instances to form a cluster. In this way, even if some machines are down, migrating access to normal machines can ensure normal access to the service.

Multi-IDC deployment is deployed in more than one data center, which ensures that even if a data center is unavailable due to force majeure factors such as power outage or fiber optic cable disconnection, it can still ensure normal access to the service by moving the request to another data center.

Data consistency

In order to ensure the high availability of registries, registries are often deployed in clusters and are usually deployed in more than one data center, which leads to another question: how to ensure data consistency among multiple data centers? How to ensure that access to any machine in the data center can get the correct data?

This paper deals with the famous CAP theory in distributed systems, that is, it is impossible to satisfy consistency, availability and partition fault tolerance at the same time, in which C (Consistency) represents consistency, A (Availability) represents availability, and P (Partition Tolerance) represents partition fault tolerance.

Why can't CAP be satisfied at the same time?

You can imagine that in a distributed system, there are multiple nodes, which are connected by the network. Normally, data on any other node can be accessed from one node through the network.

However, there may be a network failure, resulting in the entire network being divided into disconnected areas, which is called zoning. Once there is a partition, then the nodes in one area will not be able to access the data on other nodes, and the best way is to copy the data to the nodes in other areas, so that even if there is a partition, you can also access the data on the nodes in any area, which is called partition fault tolerance.

However, data inconsistency may occur when data is copied to multiple nodes, which is called consistency. To be consistent, you must wait for the data on all nodes to be updated before it is available, which is availability.

Generally speaking, the more data nodes, the higher the fault tolerance of partitions, but the more difficult it is to ensure data consistency. In order to ensure the consistency of data, it will bring the problem of usability.

While the registry generally adopts distributed cluster deployment, it is also faced with the problem of CAP, which can not be satisfied at the same time according to CAP, so different registry solutions choose different directions, which can be roughly divided into two kinds.

CP registry, sacrificing availability to ensure strong data consistency, the most typical example is ZooKeeper,etcd,Consul. There is only one Leader in the ZooKeeper cluster, and when the Leader is not available, a new Leader is elected by the Paxos algorithm. The purpose of this Leader is to ensure that only this Leader is written when writing information, and the Leader will synchronize the information to the Followers, which ensures strong data consistency. However, if there is a problem with the network between multiple ZooKeeper, resulting in multiple Leader and brain fissure, the registry will not be available. Both etcd and Consul clusters use the raft protocol to ensure strong consistency, and the registry is not available if a brain fissure occurs.

AP-type registry, sacrificing consistency to ensure availability, the most typical example is Eureka. By contrast, Zookeeper,Eureka does not have to elect a Leader, and each Eureka server keeps the service registration address separately, so it is possible that the data information is inconsistent. But when there is a problem with the network, each server can complete an independent service.

For the registry, the most important function is the registration and discovery of services. when there is a problem with the network, the requirement of availability is much higher than that of data consistency. Even if unavailable service nodes are introduced into the registry because of data inconsistency, it can be avoided by other measures, such as the rapid failure mechanism of the client, as long as the final consistency is achieved, it is sufficient for the registry. Therefore, it is generally more appropriate to choose an AP-type registry.

This is the end of the content of "how to realize the registry of ZooKeeper". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.