Suppose you publish a service and have deployed it on a machine, if I want to call this service, how do I know the address of the machine you deployed?
This problem is the same as I want to eat KFC. I can search for KFC on Google Maps, and Google Maps will return the addresses of all KFC stores, so I choose the nearest one to eat. Here, Google Maps plays a role similar to a registration center, including the addresses of all KFC stores.
In the same way, I want to know the address of this server, can I go to a place like "Google Maps" to check it? Yes, in a distributed system, there is a similar concept, but its name is not a map, but a registration center. But the principle is similar to that of the map, that is, the address of the machine where the service is deployed is recorded in the registration center. When the service consumer needs it, he only needs to query the registration center and enter the provided service name to get the address and initiate a call.
Let me explain in detail the principle and implementation of the registration center.
Registry principle
Under the microservice architecture, there are three main roles: service provider (RPC Server), service consumer (RPC Client) and service registry (Registry). Please see the following picture for the interaction relationship between the three, let me explain briefly one time.
-
RPC Server provides services. When starting, it registers its own services with the Registry according to the configuration information in the service release file server.xml, and periodically sends heartbeat reports to the Registry to report the survival status.
-
The RPC Client invokes the service. When it starts, it subscribes to the Registry according to the information configured in the service reference file client.xml, caches the service node list returned by the Registry in the local memory, and establishes a connection with the RPC Sever.
-
When the RPC Server node changes, the Registry will change synchronously, and the RPC Client will refresh the service node list cached in the local memory after sensing it.
-
The RPC Client selects an RPC Sever to initiate the call based on the load balancing algorithm from the list of service nodes cached locally.
Registry implementation
The realization of the registration center mainly involves several issues: what interfaces the registration center needs to provide and how to deploy them; how to store service information; how to monitor the survival of service provider nodes; Control access to the registry.
1. Registry API
According to the description of the registration center principle, the registration center must provide the following most basic APIs, for example:
-
Service registration interface: The service provider completes the service registration by calling the service registration interface.
-
Service anti-registration interface: The service provider completes service deregistration by calling the service anti-registration interface.
-
Heartbeat report interface: The service provider completes the node survival status report by calling the heartbeat report interface.
-
Service subscription interface: The service consumer completes the service subscription by calling the service subscription interface, and obtains a list of available service provider nodes.
-
Service change query interface: Service consumers obtain the latest list of available service nodes by calling the service change query interface.
In addition, in order to facilitate management, the registration center must also provide some background management APIs, such as:
-
Service query interface: query which service information is currently registered by the registration center.
-
Service modification interface: modify the information of a service in the registry.
2. Cluster deployment
As a communication bridge between service providers and service consumers, the registration center is self-evident. Therefore, the registration center generally adopts cluster deployment to ensure high availability, and uses a distributed consistency protocol to ensure that the data between different nodes in the cluster is consistent.
Take the open source registration center ZooKeeper as an example. The ZooKeeper cluster contains multiple nodes. Service providers and service consumers can communicate with any node because their data must be the same. Why? This starts with the working principle of ZooKeeper:
-
Each server stores a piece of data in memory, and the client's read request can request any server.
-
When ZooKeeper starts, a leader (Paxos protocol) will be elected from the instance.
-
Leader is responsible for processing data updates and other operations (ZAB protocol).
-
An update operation succeeds if and only if most of the servers successfully modify it in memory.
In this way, ZooKeeper ensures high availability and data consistency.
3. Directory storage
Still taking ZooKeeper as an example, the registration center generally adopts a hierarchical directory structure to store service information:
-
Each directory is called a znode in ZooKeeper, and it has a unique path identifier.
-
znode可以包含数据和子znode。
-
znode中的数据可以有多个版本，比如某一个znode下存有多个数据版本，那么查询这个路径下的数据需带上版本信息。
4. 服务健康状态检测
注册中心除了要支持最基本的服务注册和服务订阅功能以外，还必须具备对服务提供者节点的健康状态检测功能，这样才能保证注册中心里保存的服务节点都是可用的。
还是以ZooKeeper为例，它是基于ZooKeeper客户端和服务端的长连接和会话超时控制机制，来实现服务健康状态检测的。
在ZooKeeper中，客户端和服务端建立连接后，会话也随之建立，并生成一个全局唯一的Session ID。服务端和客户端维持的是一个长连接，在SESSION_TIMEOUT周期内，服务端会检测与客户端的链路是否正常，具体方式是通过客户端定时向服务端发送心跳消息（ping消息），服务器重置下次SESSION_TIMEOUT时间。如果超过SESSION_TIMEOUT后服务端都没有收到客户端的心跳消息，则服务端认为这个Session就已经结束了，ZooKeeper就会认为这个服务节点已经不可用，将会从注册中心中删除其信息。
5. 服务状态变更通知
一旦注册中心探测到有服务提供者节点新加入或者被剔除，就必须立刻通知所有订阅该服务的服务消费者，刷新本地缓存的服务节点信息，确保服务调用不会请求不可用的服务提供者节点。
继续以ZooKeeper为例，基于ZooKeeper的Watcher机制，来实现服务状态变更通知给服务消费者的。服务消费者在调用ZooKeeper的getData方法订阅服务时，还可以通过监听器Watcher的process方法获取服务的变更，然后调用getData方法来获取变更后的数据，刷新本地缓存的服务节点信息。
6. 白名单机制
In actual microservice testing and deployment, there are usually multiple sets of environments, such as one production environment and one test environment. When developing a business self-test and testing a regression test, the test environment is generally used, and the deployed RPC Server node is registered to the test registration center cluster. However, it often occurs that during development or test deployment, the service node in the test environment is mistakenly registered with the online registration center cluster. In this case, the online traffic will be called to the RPC Server node in the test environment, which may cause unexpected results. s consequence.
In order to prevent this from happening, the registration center needs to provide a protection mechanism. You can imagine the registration center as a room with access control, and only the RPC Server with the access control card can enter. In practical applications, the registration center can provide a whitelist mechanism. Only RPC Servers added to the whitelist of the registration center can call the registration interface of the registration center. In this way, nodes in the test environment can be prevented from accidentally running into the online environment. to go.
Summarize
The registration center can be said to be the key to the realization of service, because after service, the service provider and the service consumer do not run in the same process to achieve decoupling, which requires a link to connect the service provider and the service consumer. And the registration center just assumes this role. In addition, the service provider can expand or reduce nodes arbitrarily. Through the service health status detection, the registration center can keep the latest service node information and notify the service consumers who subscribe to the service of the change.
Registration centers generally adopt distributed cluster deployment to ensure high availability, and in order to achieve multi-active in different places, some registration centers also adopt multi-IDC deployment, which creates high requirements for data consistency. These are the registration centers in Problems that must be resolved during implementation.
This article is published by mdnice multi-platform