[Spring Cloud] In-depth exploration of the principles of Nacos registration center, service registration and discovery, service layering model, load balancing strategy, microservice weight setting, and environment isolation

---

Preface

In the microservice architecture, the service registration center is one of the key components in the entire system. It is responsible for the registration, discovery and management of services, and provides infrastructure for communication between microservices. In this regard, Nacos (Namespace Aware Clustered Object Storage), as a service discovery and configuration management system, provides rich functions designed to simplify service registration, configuration management, and service metadata processing in microservice architecture.

1. First introduction to Nacos registration center

1.1 What is Nacos

Nacos (Namespace Aware Clustered Object Storage) is an open source, easy to configure, multifunctional service discovery and configuration management system. Developed by Alibaba, it provides a solution that simplifies service discovery, dynamic configuration, and service metadata in microservice architecture.

Nacos has the following main features:

• Service discovery and health check: Nacos provides service registration and discovery functions, which can easily manage microservice instances. It also supports health checks on services to detect unavailable instances in a timely manner.

• Dynamic configuration management: Nacos allows configuration information to be stored on the server and supports dynamically updated configurations, achieving centralized management of configurations.

• Dynamic DNS service: Nacos provides a built-in DNS service, and service instance information registered on Nacos can be obtained through DNS query.

• Multiple environments and namespaces: Nacos supports the management of multiple environments (such as development, testing, production) and namespaces, allowing for more flexible organization and management of configuration information.

1.2 Installation, configuration, and startup of Nacos

1. Installation

1. Download the installation package

On the GitHub page of Nacos, a download link is provided to download the compiled Nacos server or source code:

GitHub homepage: https://github.com/alibaba/nacos

GitHub's Release download page: https://github.com/alibaba/nacos/releases

As shown in the picture:

2. Click the label on the right Tagsto select the historical version more intuitively. Here we take Nacos 1.4.1 as an example:

3. Select the Windows environment zip. If it is Linux, select tar.gzthe compressed package. Here we take the Windows environment as an example:

4. After the download is completed, unzip it to a path without Chinese characters. At this time, the installation is complete.

5. Directory structure of Nacos

Catalog description:

• bin: script file to start Nacos.
• conf: Nacos configuration file.

2. Configuration

The default port of Nacos is 8848. If other processes on the computer occupy port 8848, please try to close the process first.

If you cannot close the process occupying port 8848 , you can also enter the conf directory of Nacos and modify the port in the configuration file:
Modify the contents:

Modify port:

3. Start

Starting Nacos is very simple, enter the bin directory, the structure is as follows:

Then execute the command:

startup.cmd -m standalone

The effect after execution is as follows:

Visit the address provided in the startup log, or enter the address in the browser http://127.0.0.1:8848/nacosto access the Nacos console:

The default account and password are nacos. After entering:

2. Registration and discovery of services

Nacos's service registration is very simple. Spring Cloud provides a common interface specification, so using different registration centers only requires changing the configuration without modifying the code to complete the switching of the registration center. For example, switching Eureka to Nacos works as follows:

1. Add management dependencies in cloud-demothe parent project :spring-cloud-alilbaba

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

2. Comment out the original Eureka dependencies order-servicein and user-serviceand add Nacos client dependencies:

<!-- Nacos 客户端依赖 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

3. Modify application.ymlthe file, comment out the Eureka related configuration, and add the Nacos related configuration:

spring:
  cloud:
    nacos:
	  server-addr: localhost:8848 # Nacos 服务地址

4. According to the above modification steps, modify the configurations of the two microservices at the same time user-service, order-serviceand then start the two microservices respectively:

order-serviceAt this time, one service instance and three service instances are started user-service.

5. After starting, you can view all registered services in the service list of the Nacos console:

And you can view the details of the service:

Through the above steps, we successfully switched the service registration center from Eureka to Nacos, realizing service registration and discovery. Nacos provides powerful service management functions and is an excellent service center for cloud native applications.

3. Nacos service layering model

3.1 Nacos’ service hierarchical storage model

Nacos' service hierarchical storage model is an important part of its design architecture, which helps to better manage and organize service information. This model is divided into three levels, namely Service, Cluster and Instance.

For example, Nacos' service hierarchical storage model is shown in the figure below:

This model is divided into three levels:

1. Service : Service is the highest level in Nacos. It represents an abstract service entity, usually identified by the name of the service, such as userservice. A service can contain one or more clusters.

2. Cluster : Cluster is the next level of service and is used to represent the grouping of multiple instances of the same service. A service can be distributed across different clusters, and each cluster can contain one or more instances. Taking geographical location or deployment environment as an example, a service can have multiple clusters, such as Hangzhou cluster, Shanghai cluster, etc.

3. Instance : Instance is the lowest level of service. It represents a specific service instance and usually corresponds to a running service node. Each cluster can contain one or more instances, each instance has a unique IP address and port number, and provides the access address of the service.

The design of this model enables Nacos to better manage and organize service information, especially in scenarios deployed in multiple geographical locations and multiple environments. Services can be divided based on geographical location, deployment environment, etc. Each cluster contains multiple instances and has the characteristics of high availability and load balancing. This structure also helps to better understand and manage the service system in the microservice architecture, making service registration, discovery and management more intuitive and controllable.

3.2 Cross-cluster service calling issues

In a microservice architecture, services are usually distributed in different clusters, and calls between services may involve cross-cluster situations. In Nacos, there are some issues that need to be considered when calling services across clusters. One of the important issues is latency.

The general principle when calling services is to choose services in the local cluster as much as possible, because local calls usually have lower latency. Cross-cluster calls are only considered when the local cluster's services are inaccessible .

Let’s illustrate with an example:

Suppose there are two clusters, one is the Hangzhou cluster and the other is the Shanghai cluster. There is a service in the Hangzhou cluster order-service, and there is an identical user-serviceservice in the Shanghai cluster. If order-servicethis microservice needs to be called user-service, it will first try to call the service of the local cluster, that is, the Hangzhou cluster user-service. Only when the services of the Hangzhou cluster are inaccessible will cross-cluster calls be considered to access the Shanghai cluster user-service.

Such a design can effectively reduce the latency of service calls, because local calls are usually faster than cross-cluster calls. At the same time, it also improves the stability of the system and avoids the situation where the entire system cannot work properly when a certain cluster is unavailable.

3.3 Service cluster attribute settings

When we view the details of a specific service in the Nacos console, we will find the cluster in which the current service is located DEFAULT:

At this time, if we want to modify the cluster to which the service belongs, we can application.ymlconfigure it by modifying the file:

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos 服务地址
      discovery:
        cluster-name: name # 集群名称

For example, user-serviceset one instance of the service to the Hangzhou cluster, and set the other two instances to the Shanghai cluster. After restarting, check the Nacos console again:

At this point, the cluster properties of the service are successfully configured user-service. However, if you want to order-servicecall your nearest cluster, you also need to order-serviceconfigure the cluster attributes of the service.

For example, configure it to the Hangzhou cluster:

After the configuration is completed, now order-serviceand port 8081 user-serviceare in the same cluster, while ports 8082 and 8083 user-serviceare in the Shanghai cluster.

3.4 Modify the load balancing strategy to the cluster strategy

Restart order-servicethe service, and then perform multiple query order operations to observe user-servicethe situation of calling the service:

At this time, we discovered that it seemed that the policy of preferential access to the same cluster was not adopted, but a round-robin load balancing method was adopted. Of course, this approach should be adopted, because what is currently order-serviceset is a randomly selected load balancing strategy:

If you want to give priority to the policy of accessing the same cluster, you need to modify order-servicethe application.ymlfile and set the load balancing IRuleas com.alibaba.cloud.nacos.ribbon.NacosRule. This rule will first look for services in the same cluster as itself:

# 修改 Ribbon 负载均衡策略
userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 集群优先负载均衡规则

Restart order-servicethe service again, and then perform order query operations multiple times to observe user-servicethe calling situation:

At this time, you can find that all the instances accessing port 8081 user-serviceare not serving the other two instances. This is because user-servicethe service on port 8081 is order-servicein the same cluster.

If the 8081 user-serviceservice is stopped at this time, what will happen when you access it again? For example:

At this time, the service on port 8083 is accessed across the cluster user-service.

Moreover, order-servicea warning also appeared in the service log:

The meaning is that a cross-cluster call is made, that is, order-servicethe cluster you want to serve is the Hangzhou cluster, but the Shanghai cluster is actually accessed.

4. Load balancing based on service weights

In actual deployment, the performance of server devices may vary. Some instances are located on machines with better performance, while others have poorer performance. In order to make reasonable use of resources, we hope that machines with better performance can bear more user requests. Nacos provides a weight configuration function. By setting the weight, you can control the access frequency. The greater the weight, the higher the probability of being selected.

The following demonstrates how to set the weight of a service instance in the Nacos console:

1. In the Nacos console, select the corresponding instance and click the edit button to find the weight configuration item:
   

2. Set the weight of an instance, for example, set the weight of the service on port 8081 to 0.1:
   

After setting the weight, perform multiple visits to observe user-servicethe service invocation:

It can be seen that after multiple visits, user-servicethe number of visits corresponding to port 8081 is relatively small, indicating that the weight setting takes effect. This method can effectively utilize resources, allowing machines with better performance to bear more user requests and achieve load balancing.

Notice:

• If the weight is set to 0, then this service will not be served.
• In an actual production environment, when a service needs to be upgraded, its weight can be set to 0 to avoid directing traffic to the instance being upgraded and affecting the user experience. After the upgrade is completed, the weight can be restored to normal. value.
• At the same time, this setting is also suitable for fault handling. By setting the weight of the failed service instance to 0, the instance is temporarily blocked to ensure the availability of the overall service.

5. Nacos environment isolation

5.1 What is Nacos environment isolation (namespace)

From the above we know that Nacos is a registration center, but at the same time Nacos is also a data center. Therefore, in order to manage services and data, Nacos also provides support for environment isolation. The outermost layer of service storage and data storage in Nacos is a namespacething called , which is used for outermost isolation.

As shown below:

From the outside to the inside, the hierarchical relationship of Nacos is as follows:

1. Namespace: It is the outermost isolation unit. A Namespace corresponds to an isolated environment and contains independent services and configuration information. Each Namespace has a unique namespace ID and name.

2. Group: Under a Namespace, services and configurations can be divided according to Group. Different Groups can contain different versions of the same service name (Service) or configuration name (Data). The role of Group is to divide services and configurations in a Namespace in a more fine-grained manner.

3. Service/Data (Service/Configuration): It is the most basic unit in Namespace and Group. Service represents service and Data represents configuration. Service and configuration names are unique within a Namespace and Group.

This layered structure makes Nacos very flexible and isolated. Namespace provides the largest range of isolation, Group further refines isolation, and Service and Data are specific services and configuration units.

5.2 Why environmental isolation is needed

Environment isolation is an important practice in distributed systems and microservice architectures. For Nacos, the main reasons for introducing environment isolation include:

1. Multi-environment support: In the process of software development and operation and maintenance, there are usually multiple environments, such as development environment, test environment, production environment, etc. By using Namespace to isolate environments, services and configuration information in different environments can be managed independently without interfering with each other.

2. Team collaboration: In large projects, there may be multiple development teams developing and maintaining services at the same time. Each team can independently manage services and configurations under its own Namespace to ensure isolation from each other.

3. Version management: As the business develops, services and configurations may have multiple versions. By using the structure of Group and Namespace, version management can be better performed, and different versions of services and configurations can be distinguished through Group under the same Namespace.

4. Isolation risk: In a microservices architecture, services are independent of each other. Without environmental isolation, an error in one service may spread to other services, causing problems in the entire system. This risk can be minimized by using Namespaces to isolate environments.

In general, Nacos's environment isolation function provides a flexible solution for complex scenarios with multiple environments, multiple teams, and multiple versions, making the management of services and configurations clearer and more controllable.

5.3 Set up environment isolation for Nacos

Looking at the "Namespace" in the Nacos console, we can see that a default namespace is provided for us public:

At this time, all services are also in this namespace:

The setting of Nacos environment isolation can be completed by modifying the Nacos console and related configuration files. The specific steps are as follows:

1. Create a namespace in the "namespace" available in the Nacos console to isolate different environments:
   
   At this time, create a devnamespace for the development environment. There is also a namespace ID. This ID can be filled in or not filled in. If not filled in, a unique ID will be automatically generated using UUID.

2. After clicking Confirm, you will find that devthe namespace ID is automatically generated for:
   

And there is an additional devnamespace in the service list at this time, but no services have been registered in it:

3. Modify order-serviceand application.ymladd the newly created namespace:

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos 服务地址
      discovery:
        namespace: ID # 命名空间 ID

Note that this ID must be consistent with the namespace ID in Nacos.

For example, set to devthe ID of the namespace:

5.4 Restart the order-service service

After setting order-servicethe service namespace, restart and view the console service list:

At this point, you can find that the service devhas been successfully registered in the namespace order-service.

If you access the order information again at this time, will the access be successful?

It was found that the result was an error because there were no available user-serviceinstances, but now three instances were clearly started user-service.

It turns out that the three user-serviceinstances are located publicin the namespace, and order-serviceare located in devthe namespace. Since the namespace is isolated, services in other namespaces cannot be accessed user-service.

user-serviceAt this point, the service is also registered in devthe namespace in the same way :

Restart the service and view the Nacos console:

It is found that all services devare in the namespace. Once the order information is served again, it can be accessed normally:

6. Analysis of the principles of Nacos registration center

6.1 Execution process of Nacos registration center

Nacos (Naming and Configuration Service) is an open source service discovery and configuration management platform used to build and manage microservice architecture. In the microservice architecture, service registration and discovery are crucial, and Nacos, as a service registration center, undertakes this critical task. The following will provide an in-depth analysis of the execution process of the Nacos registration center and explain the principles behind it in detail.

Overview of Nacos registration center execution process:

Detailed description of the process in the above figure:

1. Service provider registration: When the service provider starts, it registers its service information to the Nacos registration center. This includes key information such as service name, IP address, port number, etc. The registered instance can be a temporary instance or a non-temporary instance. Select the registration type according to actual needs.

2. Health check:

   • For temporary instances, Nacos uses a heartbeat detection mechanism. The registered temporary instance will regularly send heartbeat packets to the Nacos registration center to prove that it is running normally. If the heartbeat packet does not arrive on time, Nacos will delete the instance to ensure that there are only healthy service instances in the registration center.
   • For non-temporary instances, Nacos will actively query the instance to check its health status. If an abnormality is found, Nacos will update the health status of the instance and restore its status after the instance returns to normal.

3. Service consumer pull: The service consumer regularly pulls the latest service list from the Nacos registration center. This service list contains available service instance information, allowing consumers to understand the currently available services.

4. Exception handling and service push: Nacos registration center has an exception handling mechanism. When the registration center encounters an exception or stops running, it will actively push updated service information to service consumers. In this way, consumers can promptly perceive the status changes of the registration center and make corresponding adjustments to ensure the stability of the system.

5. Load balancing: After the service consumer obtains the service list, it will perform load balancing on the cached service list. This ensures that requests can be evenly distributed to different service instances and avoids single points of failure.

6.2 Settings for temporary and non-temporary instances

Check the instance details in the Nacos console:

you can find that the previously registered instances are temporary instances by default.

If you want to modify it to a non-temporary instance, you can application.ymlset it by modifying the file:

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

For example, modify order-servicethe service to be a non-temporary instance:

Restart the service and view the Nacos console again:

At this point, the service is successfully order-serviceset to a non-temporary instance.

If you stop order-servicethe service at this time, you can find that the health status changes false, but it is not deleted from the service list:

Restart order-servicethe service again and you will find that the health status has changed to true:

Summary: The difference between Nacos and Eureka

Nacos and Eureka are two common service registration and discovery tools. They have some differences, mainly reflected in the following aspects:

1. Data storage method:

   • Nacos: Nacos is not only a service registration center, but also a platform that supports configuration management. It uses a database-like method to store service and configuration information, provides multi-level storage structures such as namespaces, groups, services, instances, etc., and supports more fine-grained management.
   • Eureka: Eureka is mainly a simple service registration and discovery system. Its service information is stored in a global registry, which is relatively simple and straightforward.

2. Multi-environment isolation:

   • Nacos: Nacos provides the concepts of Namespace and Group, supporting the isolation and management of multiple environments, multiple teams, and multiple versions.
   • Eureka: Eureka does not directly support the concept of multi-environment isolation and needs to be implemented through other means.

3. Configuration management:

   • Nacos: As a configuration center, Nacos supports functions such as dynamic configuration, configuration version management, and monitoring of configuration changes.
   • Eureka: Eureka mainly focuses on service registration and discovery, and has no explicit configuration management functions.

4. Service weight and flow control:

   • Nacos: Nacos supports flow control through weight configuration, and different weights can be set according to the performance of the service.
   • Eureka: Eureka does not provide functions similar to weight configuration in its native form, and needs to be implemented with the help of other components (such as Ribbon).

5. compatibility:

   • Nacos: Nacos provides native support for Spring Cloud and better integrates with Spring Cloud applications.
   • Eureka: Eureka was developed by Netflix and also has natural integration with Spring Cloud.

Overall, Nacos is more comprehensive than Eureka, supports more functions, and is especially more flexible in terms of configuration management and multi-environment isolation. Choosing which one to use depends on specific needs and scenarios.