This is the 16th day of my participation in the August More Text Challenge

The purpose of RPC is to make remote call as simple and convenient as local call. RPC consists of three parts: client, server, and registry.

So, how does the interface published by the server expose to the client? How does the client get the server’s address and create a connection to perform the calling logic?

This article will explain the production scenario requirements and selection principles of the registry by analyzing a real case of a full-link service avalanche caused by Zookeeper.

0.1 Registry

As is shown in

The Provider registers services with the registry and reports heartbeat messages of service nodes.

Consumers need to subscribe to the service they are interested in from the registry, cache the node information of the corresponding service locally, and receive notification of service changes from the registry.

The authority of the registry is also very clear, is to maintain the service information and service instance node information, at the same time monitor the heartbeat of the service node, confirm the node status, in the node state is not healthy, from the instance list removed; At the same time, when the node list changes, responsible for informing subscribers, in order to achieve timely update of services and data consistency

0.2 Implementation scheme of the Zookeeper Registry

ZK was really hot, and it’s not so bad now. Many years ago, colleagues used to joke that as long as ZK was used in the architecture, it could be called distributed.

ZK is often mentioned as the registry model. So how does ZK implement the registry?

The ability to create nodes

Persistent nodes. After a node is created, it exists until a delete operation actively clears the node.

Temporary nodes. Bind its own life cycle to client state. If the client session fails, the node is automatically cleared. Note that session invalidation is mentioned here, not disconnection.

The ability to listen for notifications

The Watch mechanism. A zK node can be monitored, including changes in the data stored in the directory, changes in the sub-node directory, and any changes can be notified to the client that set up the monitoring. This function is the most important feature of ZooKeeper for applications. The functions realized by this feature include centralized configuration management, cluster management, and distributed locks.

These two key capabilities of ZK make it possible to become a registry.

The Zookeeper registry

As shown in the figure above, ZK creates the persistent node of the Service. Under the Service, it creates two child nodes, Provider and Consumer, which are also persistent. There are many temporary nodes under Provider and Consumer, and each temporary node represents an application instance. This facilitates dynamic addition and subtraction based on instance state. The entire capability of the registry is then realized by using the Wtach mechanism to listen to the server heartbeat and notify clients of changes to the service node.