Nacos, the soul ferryman of microservices, has an overview of its principles

preface

Nacos is gaining momentum in the area of service registration and discovery in microservices. In microservice system, the registration and discovery of service is the existence of a soul. Without the existence of a registry, the complexity of calls between hundreds of services is unimaginable.

If you plan to use Nacos or are already using it, but only at the use level, this article is worth reading.

In this article, we will start with the service discovery mechanism, and then explain the basic introduction, implementation principle, architecture, etc., to truly understand Nacos in a simple way.

Service registration and discovery

Nacos profile

Nacos is commonly pronounced /nɑ:kəʊs/, derived from the name “Dynamic Naming and Configuration Service”. Na is named in the first two letters, CO is named in the first two letters of Configuration, and S is named in the first letter of Service.

Nacos’s features are described in one sentence: “A dynamic service discovery, configuration management, and service management platform that makes it easier to build cloud-native applications.” That is, Nacos provides not only service registration and discovery, but also configuration management, as well as a visual management platform.

The official documentation also mentions that “Service is a first-class citizen of the Nacos world.” That is, Nacos revolves around services.

If you look at the source code, you will find that the Nacos core API defines two interfaces, NamingService and ConfigService. Service registration and discovery revolves around NamingService, and configuration management revolves around ConfigService.

The official website lists four core features of Nacos: service discovery and service health monitoring, dynamic configuration services, dynamic DNS services, and service and its metadata management. We’ll focus on service discovery.

Nacos Server and Client

Interaction flow in Nacos registration

As a function of the registry, Nacos provides functions similar to other mainstream frameworks, which are basically implemented around the three cores of service instance registration, instance health check and service instance acquisition.

Taking the Java version of Nacos client as an example, the basic process of service registration is as follows:

• The service instance starts registering itself with the Nacos registry and then maintains a heartbeat with the registry;
• The heartbeat maintenance policy is to send a heartbeat to the Nacos Server every five seconds, carrying instance information (service name, instance IP address, port, etc.).
• Nacos Server also initiates health checks to clients and supports TCP/Http.
• If there is no heartbeat within 15 seconds and the health check fails, the instance is considered unhealthy. If the health check fails within 30 seconds, the instance is removed.
• The service consumer obtains the instance through the registry and initiates the invocation;

Service discovery supports two scenarios: first, a service consumer directly sends a request to the registry to obtain a service instance, and the registry returns all available instances, but this method is generally not recommended; Second, a service consumer subscribes to a service in the registry and submits a listener. When a service in the registry changes, the listener is notified and the consumer updates the list of local service instances to ensure that all services are available.

Nacos data model

/**
 * Map(namespace, Map(group::serviceName, Service)).
 */
private final Map<String, Map<String, Service>> serviceMap = new ConcurrentHashMap<>();
Copy the code

Nacos service domain model

In the above data schema, we can locate a Service. What is the model of the Service? The official website provides the following image:

From hierarchical storage model in this picture you can see, in the level of service, save the health check switch, metadata, the routing mechanism, and protection of the threshold Settings, save the health examination and cluster model, metadata, data synchronization mechanism, instance holds the IP, port, the weight of the instance, state of health examination, offline, metadata, the response time.

At this point, we ignore the one-to-many situation, and the relationship of data storage in the whole Nacos is shown as follows:

It can be seen that Namespace contains multiple groups, Group contains multiple services, Service contains multiple clusters, and Cluster contains Instance sets.

The corresponding source code is as follows:

/ / ServiceManager class, Map(namespace, Map(group::serviceName, Service)) private final Map<String, Map<String, Service>> serviceMap = new ConcurrentHashMap<>(); // Service class, Map(cluster, cluster) private Map<String, cluster > clusterMap = new HashMap<>(); // Cluster class private Set<Instance> persistentInstances = new HashSet<>(); private Set<Instance> ephemeralInstances = new HashSet<>(); // Instance class private String instanceId; private String ip; private int port; Private double weight = 1.0d; / /...Copy the code

Instances are divided into temporary instances and persistent instances. The key difference is the way the health check is done. Temporary instances use client-side reporting mode, while persistent instances use server-side reverse probing mode.

Temporary instances need to be able to automatically remove unhealthy instances without persisting the instance. Persistent instances use server-side health checks because clients do not report heartbeats and cannot automatically remove offline instances.

summary

Nacos series

Why is the String. Intern method used in Nacos source code? “The soul ferryman of micro services — Nacos, to a complete overview of the principle” \

Program new horizon

\

The public account “program new vision”, a platform for simultaneous improvement of soft power and hard technology, provides massive information

\