The framework of SpringCloud is no stranger, and it is the leader in the field of microservices in the industry. Today, let's take a look at how to choose the right registration center according to business needs?
The registration center is a key component of microservice management node communication and core configuration. From the premise of distributed multi-node, the most important thing to solve is the consistency problem under distributed. Different business scenarios have different requirements for AP and CP models.
1. Background knowledge of registration center - CAP theory
CAP is three important metrics for distributed systems:
- C - Consistency consistency: On multiple distributed nodes, reading the same key content is the same.
- If the key is set to value1 on node A, and node A fails, switch to another node B to query and find that the key is value1. If the value is inconsistent or does not exist, there is a consistency problem.
- When the service has a data inconsistency problem, it means that if an external query is made, the response data may be an old version, or the response data may be a new version, or the content of the concurrent query response is different.
- At this time, the system should not return any data to avoid data inconsistency. After recovery, provide accurate data.
- A - Availability-availability: On multiple distributed nodes, if some nodes fail, or the communication between some nodes is interrupted, and the service can be provided normally within the response time allowed by the business, the service has high availability.
- You can quickly remove faulty nodes through the service cluster, and still provide services to the outside world.
- Or both the normal and faulty nodes can provide external services, but the normal and faulty nodes cannot communicate, so there may be consistency problems.
- Or the node can receive the request normally, but finds that there is a problem with the internal data of the node, even if there is data consistency, it must provide external services.
- P - Partition tolerance-Partition fault tolerance: Distributed systems often have multiple nodes. If multiple nodes suddenly fail to communicate with each other, but can still provide external services, it has partition fault tolerance.
- In a distributed system, if there is a communication interruption problem between nodes due to network, machine and other reasons, it is said that the distributed system has a partition.
- At this time, even if a partition failure occurs, the system can still run normally, and each service node can still provide external services.
In distributed storage, the CAP theory must not be satisfied, and there must be a trade-off, so the choice of AP/CP appeared.
From the repeated understanding and study of the above two theories of C\A, we can clearly see the difference between the CP and AP systems:
- CP system: Data consistency is required. Once a node fails and the data is consistent, client requests will be stuck or rejected until the node can provide consistent data.
- Typical components are Zookeeper.
- Usually financial systems require strong data consistency.
- AP system: The availability of services is required. Even if a node fails, the service can still provide external services, but the data provided may be inconsistent.
- Typical components include Eureka.
- Usually some Internet systems accept eventual consistency, and choose the availability of services.
In a complete system, AP or CP should also be selected according to the usage scenario to see whether it is more concerned about consistency or usability.
2. Selection and classification of registration centers
Common CP registration centers are: Zookeeper\Consul\Nacos;
common AP registration centers are: Nacos\Eureka;
- Zookeeper: often the combination of Zookeeper + Doubbo;
- Consul: is a service mesh solution that provides a full-featured control plane with service discovery, configuration, and segmentation capabilities;
- Nacos: Compatible with both types of AP\CP, more agile and easy to build, deliver and manage microservice platforms;
- Eureka: Spring Cloud's default registration center, each node can be regarded as a copy of other nodes, thus providing high availability to the outside world;
Since Nacos has both AP version and CP version, let's learn about the registration center process from SpringCloud+Nacos.
3. Nacos Registration Center
Nacos mainly provides the following four functions:
- Service discovery and service health monitoring
- Dynamic configuration service
- Dynamic DNS service
- Services and their metadata management
Nacos has Server and Client:
-
The server server provides service registration and metadata storage.
- The service information will be stored according to the mapping relationship of Namespace -> Group -> Service -> Cluster -> Instance.
- The server will regularly check the heartbeat of the registered client to determine the health status of the service.
- Refreshes and broadcasts the service provider data that has been registered and changed.
-
Client Client is divided into Service Provider Client, Service Consumer Client
- The service provider registers its own access address to the registration center, sends a heartbeat for the scheduled task to renew the contract, and actively synchronizes with the registration center if there is any change in its own IP.
- There are two ways for service consumers to subscribe to services. One is to actively pull the service list from the registry, and the other is to submit subscription tasks to the registry to process messages periodically.
- Actively pull from the registration center: use openAPI or SDK to directly call the query of the specified instance list to obtain specific instance information
- Submit subscription tasks: handle different types of implementations through EventListener to dynamically adjust calls to services
Nacos enables subscription pull by default when performing service discovery through the client.
The default parameter subscribe is true, so the getServiceInfo method will be used to obtain the latest service instance.
If subscribe is false, use the getServiceInfoDirectlyFromServer method to request the server to obtain the latest service instance every time.
public List<Instance> selectInstances(String serviceName, String groupName, List<String> clusters, boolean healthy,
boolean subscribe) throws NacosException {
ServiceInfo serviceInfo;
String clusterString = StringUtils.join(clusters, ",");
// 是否为订阅模式
if (subscribe) {
// 先从本地缓存获取服务信息
serviceInfo = serviceInfoHolder.getServiceInfo(serviceName, groupName, clusterString);
// 如果本地缓存不存在服务信息，则进行订阅
if (null == serviceInfo) {
serviceInfo = clientProxy.subscribe(serviceName, groupName, clusterString);
}
} else {
// 如果未订阅服务信息，则直接从服务器进行查询
serviceInfo = clientProxy.queryInstancesOfService(serviceName, groupName, clusterString, 0, false);
}
// 从服务信息中获取实例列表
return selectInstances(serviceInfo, healthy);
}
There are introductions and examples on the official website for the deployment and basic use of Nacos. You can follow the official website for simple single-node deployment of the Nacos server. (Official documentation: https://nacos.io/zh-cn/docs/quick-start-spring-cloud.html )
Write the demo of SpringCloud+Nacos to register its own services, and simply query the service list to get a preliminary understanding of the functions of Nacos.
At present, Nacos is also popular and widely used in the domestic SpringCloud/SpringBoot microservice architecture.
- High availability of services
- Simple and lightweight deployment
- Simple configuration and low cost
- The community is open and active
- Support the development and use of cross-language services
Why don't you hurry up and give it a try?