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

This article mainly introduces "what is Nacos". In daily operation, I believe many people have doubts about what is Nacos. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts about "what is Nacos?" Next, please follow the editor to study!

Preface

The rapid momentum of Nacos in the field of service registration and discovery of micro-service systems is visible to the naked eye. In the micro-service system, the registration and discovery of services is the existence of a soul. Without a registry, the invocation complexity between hundreds of services is unimaginable.

If you are planning or already using Nacos, but only at the usage level, this article is worth reading.

In this paper, we start with the service discovery mechanism, and then explain the basic introduction, implementation principle, architecture and so on of Nacos, in order to really understand Nacos.

Service registration and discovery

When it comes to Nacos, we have to talk about service discovery in the microservice architecture. About service discovery is actually "want to learn about micro-service discovery?" First of all, let's learn some popular science knowledge. "this article gives a comprehensive explanation." Let's sort it out briefly here.

In traditional applications, when one service An accesses another service B, we only need to configure the service address and port of service B in the static configuration file of service A.

However, in the architecture of microservices, this situation has changed, as shown in the following figure:

In the figure above, the IP of the service instance is dynamically allocated. At the same time, it is also faced with changes in the increase or decrease of services, failures, upgrades and so on. In this case, for client programs, a more precise service discovery mechanism is required.

In order to solve this problem, service registration middleware such as etcd, Consul, Apache Zookeeper, Nacos and so on emerge as the times require.

Introduction to Nacos

"Nacos" is generally pronounced as "/ n steps: Knowles." the name comes from "Dynamic Naming and Configuration Service". Na is taken from the first two letters of "Naming", co from the first two letters of "Configuration", and s from the first letter of "Service".

The functions of Nacos are officially explained in one sentence: "A dynamic service discovery, configuration management and service management platform that is easier to build cloud native applications." In other words, Nacos not only provides service registration and discovery functions, but also provides configuration management functions, but also provides a visual management platform.

The official document also mentions that "Service is a first-class citizen of the Nacos world." That is to say, the Nacos revolves around Service.

If you look at the source code, you will see that there are two interfaces NamingService and ConfigService defined in the core API of Nacos. Service registration and discovery revolve around NamingService, while configuration management revolves around ConfigService.

The official website gives four core features of Nacos: service discovery and service health monitoring, dynamic configuration service, dynamic DNS service, service and its metadata management. We mainly talk about the service discovery function.

Server and Client of Nacos

Nacos registry is divided into Server and Client,Nacos to provide SDK and openApi. If there is no SDK, you can manually write the logic of service registration and discovery and configuration pull according to openApi.

Server is written in Java, based on Spring Boot framework, and provides registration discovery service and configuration service for Client.

Client support includes currently known Nacos multilingual clients and related clients of the Spring ecosystem. Client is nested with microservices.

The DNS implementation of Nacos relies on CoreDNS, and its project is nacos-coredns-plugin. The plug-in provides a CoreDNS-based DNS-F client and the development language is go.

Interactive flow in Nacos Registration

As for the functions of the registry, the functions provided by Nacos are very similar to other mainstream frameworks, which are basically implemented around the three core of service instance registration, instance health check and service instance acquisition.

Take the Java version of the Nacos client as an example, the basic process of service registration:

The service instance starts to register itself with the Nacos registry and then maintains a heartbeat with the registry

Heartbeat maintenance policy is to send a heartbeat to Nacos Server every 5 seconds with instance information (service name, instance IP, port, etc.)

Nacos Server will also initiate a health check to Client to support 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 deleted.

The service consumer obtains the instance through the registry and initiates the call

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

Nacos data model

With regard to the data model, the official website describes that the Key of the Nacos data model is uniquely determined by the triple. Namespace defaults to empty strings, common namespaces (public), and grouping defaults to DEFAULT_GROUP.

The figure above is the one provided by the government. We can further refine the split to take a look at:

If you don't understand, you can look directly at how Namespace, Group, and Service are stored at the code level:

/ * Map (namespace, Map (group::serviceName, Service)) * / private final Map serviceMap = new ConcurrentHashMap ()

That is to say, the Nacos service registry structure is: Map

Nacos is designed based on namespace for multi-environment and multi-tenant data (configuration and service) isolation. If you have multiple environments (development, test, production, etc.), you can build three different namespace, such as dev-namespace and prod-namespace in the figure above.

Nacos service domain model

In the above data schema, we can locate a Service, so what is the model of the service? The following picture is available on the official website:

As can be seen from the hierarchical storage model in the figure, at the service level, health check switches, metadata, routing mechanism, protection threshold and other settings are saved, while the cluster stores health check mode, metadata, synchronization mechanism and other data, and the instance saves the instance's ip, port, weight, health check status, offline status, metadata, response time.

At this point, we ignore the one-to-many situation, and the relationship between the data stores in the entire Nacos is shown below:

As you can see, the inclusion relationship of the whole level is that Namespace contains multiple Group, Group can contain multiple Service, Service can contain multiple Cluster, and Cluster contains Instance collection.

The corresponding part of the source code is as follows:

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

Among them, the instance is divided into temporary instance and persistent instance. The key to the difference is the way you get a health check. Temporary instances use client-side escalation mode, while persistent instances use server-side reverse probe mode.

Temporary instances need to be able to automatically remove unhealthy instances without the need for persistent storage instances. Persistent instances use the health check method of server detection, because the client does not report a heartbeat, so it is not possible to automatically remove offline instances.

At this point, the study of "what is Nacos" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.