You should know the Nacos access and pit avoidance guide

This article shares a powerful Nacos which is a must-use component in a microservices environment. With Nacos you no longer have to worry about service registration and discovery, as well as configuration management confusion.

background

Nacos is committed to helping developers discover, configure, and manage microservices, and Nacos provides an easy-to-use set of features for rapid dynamic service discovery, service configuration, service metadata, and traffic management.

At present, the mainstream Internet services are based on microservices architecture, that service and service interaction is essential, and each service is independent of each other, and the configuration information of the service will be dynamically adjusted, which requires our services to be more flexible. The advent of Nacos us implement these tedious features.

Detailed Nacos and deployments can be found on the official Nacos.io Here's just a look at how to quickly access the SpringBoot project and the pits you might encounter during access and use.

access

Join dependencies

1. The first step is to include the following dependencies in the pom profile to implement the service registration discovery and configuration center functionality.

<!-- nacos 配置中心 -->
<dependency>
  <groupId>com.alibaba.cloud</groupId>
  <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId></dependency>
  <!-- nacos 注册发现 -->
<dependency>
  <groupId>com.alibaba.cloud</groupId>
  <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>

Increase the configuration

1. The second step is to add the following annotations to the SpringBoot project's startup @EnableDiscoveryClient used to start the service registration discovery feature.

1. Add profiles, the corresponding configuration information needs to be modified to suit their own, in order to facilitate management, the application of grouping names, namespaces and related configurations need reasonable settings. W hen multiple businesses use the same nacos cluster, they need to set their own namespaces for each business. All configuration files need to be set under the corresponding namespace to avoid multiple business mixing, and the business needs to set up separate profiles based on the components or configurations used, such as database configuration, Redis configuration, etc. need to be set separately, so that other services can be used for the same application, and then when there is an address change can only modify a file, will not forget.

# 应用服务名称
spring.application.name=application-name
# 应用分组名称
spring.cloud.nacos.config.group=GROUP-NAME
# 配置文件的后缀名
spring.cloud.nacos.config.file-extension=properties
# nacos 对应的命名空间，在后台创建好命名空间后会自动生成
spring.cloud.nacos.config.namespace=xxxxxxxxxxxxxxxxxxxxxxxxx
# 对应的配置文件
# MySQL 相关配置
spring.cloud.nacos.config.ext-config[0].data-id=mysql.properties
spring.cloud.nacos.config.ext-config[0].group=GROUP-NAME
# Redis 相关配置
spring.cloud.nacos.config.ext-config[1].data-id=redis.properties
spring.cloud.nacos.config.ext-config[1].group=GROUP-NAME
# 其他配置等
spring.cloud.nacos.config.ext-config[2].data-id=other.properties
spring.cloud.nacos.config.ext-config[2].group=GROUP-NAME
# 配置中心地址，多个逗号分隔
spring.cloud.nacos.config.server-addr=xxx.xx.xx.xx:xxxx
# 服务注册发现地址，多个逗号分隔
spring.cloud.nacos.discovery.server-addr=xxx.xx.xx.xx:xxxx
# 集群名称
spring.cloud.nacos.discovery.cluster-name=CLUSTER-NAME

1. You can use the annotation @Value() to read the property parameters in the Nacos configuration directly, or you can read the bulk @ConfigurationProperties(prefix = "spring.datasource")

1. spring.cloud.nacos.config.ext-config[0].refresh=true This parameter indicates whether automatic updates are turned on, whether or not they are configured, depending on whether automatic updates are required, if automatic updates are required, plus this configuration requires the addition @RefreshScop comments on the beans that need to be automatically updated. T he properties inside the corresponding bean can then be automatically updated. After adding spring.cloud.nacos.config.ext-config[0].refresh=true configuration, the following information appears in the log after the configuration in Nacos has been modified, the configuration is reloaded, and the key information for the change is output.

The service call

Once all the services are connected to Nacos, we can see each service in the background of Nacos, as shown below, and we can see the service status.

Then when we want to call Service B in Service A, we can configure the name of Service B directly in FeginClient without having to fill in the URL. T his way we don't have to think about whether service B has an address and port changes. "Whether the instances of service B increase or decrease, whether the port has changed, does not care about service A, as long as there is a service name."

Avoid pits

Namespace

Nacos has a default namespace called public which cannot be deleted, and all configurations that do not specify DEFAULT_GROUP a namespace are placed under that namespace;

For our application, since in many cases a Nacos cluster is used by multiple teams, for ease of management, we need to set up our own namespace based on our own business for the configuration files of our business. Profiles under this namespace, depending on the modules, determine whether they need to be regrouped.

It's hard to know that modifying the contents of a configuration without a clear namespace division can be a hard thing to do. O nline configuration adjustment, a careless is an accident. If the configuration is updated automatically, there is no chance of regret.

Fine configuration

Profiles should be single-minded, with one profile setting up a single configuration, such as a separate configuration of MySQL data source, a separate configuration of Redis data sources, and if multiple Redis are configured separately according to feature recommendations, because not all services require a link configuration for each Redis The respective services can refer to the corresponding profile separately as needed.

Make all configurations stand-alone into a profile for subsequent configuration modifications, as long as you modify one profile, don't worry about other unmodified places.

Reasonable planning of the contents of the profile, often many times can do more with less, greatly saving time and reduce the probability of error.

Refreshes automatically

How to set up a configuration automatic refresh is described earlier, but whether the service needs to automatically update the configuration is up to its own business.

I generally do not recommend setting up automatic updates here, because now are microservices deployment, sometimes we go online when a new feature is grayscale release, if the configuration is automatically updated, and then adjust the configuration, all instances will take effect, which will be risky. Without setting up automatic updates, we can restart individual instances individually, observe the situation online, and so on stable and then release all services, which will be much safer.

Of course, for not so many services, do not need grayscale, the impact of the scene, configuration automatic updates will be much more convenient, and then modify the configuration does not need to restart the service.

(Recommended tutorial: Spring Boot those things.) )

summary

Nacos unified management of registration discovery and configuration as a service is truly excellent, with fast access to frameworks other than SpringBoot project and more reference to the official website.

Source: Public Number - Java Geek Technology

Here's a look at W3Cschool编程狮 guide to Nacos access and pit avoidance that you should know about.