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

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

Background

Nacos is dedicated to helping developers discover, configure and manage micro services. Nacos provides an easy-to-use set of features to quickly implement dynamic service discovery, service configuration, service metadata and traffic management.

Access join dependency

The first step is to add the following dependencies to the pom configuration file to implement the service registration discovery and configuration center functions.

Com.alibaba.cloud spring-cloud-starter-alibaba-nacos-config com.alibaba.cloud spring-cloud-starter-alibaba-nacos-discovery add configuration

The second step is to add the following annotation @ EnableDiscoveryClient to the startup class of the SpringBoot project to start the service registration discovery function.

Add the configuration file, and the corresponding configuration information needs to be modified to suit you. In order to facilitate management, the grouping name, namespace and related configuration of the application need to be set reasonably. When multiple businesses use the same nacos cluster, you need to set their own namespaces according to each business. All configuration files need to be set under the corresponding namespace to avoid mixing of multiple businesses. In addition, businesses need to set independent configuration files according to the components or configurations used, such as database configuration and Redis configuration, so that other services of the same application can also be used, and only one file can be modified when the address is changed, and will not be forgotten.

# Application Service name spring.application.name=application-name# Application Group name spring.cloud.nacos.config.group=GROUP-NAME# profile suffix name spring.cloud.nacos.config.file-extension=properties# nacos Namespace After the namespace is created in the background, the configuration file corresponding to spring.cloud.nacos.config.namespace=xxxxxxxxxxxxxxxxxxxxxxxxx# is automatically generated # MySQL related configuration spring.cloud.nacos.config.ext-config [0] .data-id=mysql.propertiesspring.cloud.nacos.config.ext-config [0] .group=GROUP-NAME# Redis related configuration spring.cloud.nacos.config.ext-config [1] .data-id=redis.propertiesspring.cloud.nacos.config.ext-config [1] .group=GROUP-NAME # other configurations, such as spring.cloud.nacos.config.ext-config [2] .data-id=other.propertiesspring.cloud.nacos.config.ext-config [2] .group = GROUP-NAME# configuration center address Multiple commas separate spring.cloud.nacos.config.server-addr=xxx.xx.xx.xx:xxxx# service registration discovery addresses, and multiple commas separate spring.cloud.nacos.discovery.server-addr=xxx.xx.xx.xx:xxxx# cluster name spring.cloud.nacos.discovery.cluster-name=CLUSTER-NAME

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

Spring.cloud.nacos.config.ext-config [0] .refresh = true this parameter indicates whether automatic update is enabled, whether it is configured according to the need for automatic update, and if automatic update is required, you also need to add @ RefreshScop annotation to the Bean that needs to update the configuration automatically. Then the properties within the corresponding Bean can be updated automatically. After adding the spring.cloud.nacos.config.ext-config [0] .refresh = true configuration, the following information appears in the log after the configuration in Nacos is modified, the configuration is reloaded, and the changed key information is output.

Service invocation

After all the services are connected to the Nacos, we can see the status of each service in the Nacos backend. As shown in the figure below, you can see the service status.

Then if we want to invoke service B in service A, we can directly configure the name of service B in FeginClient without filling in URL. In this way, we do not have to consider whether the address and port of Service B will change. It doesn't matter whether the number of instances of service B increases or decreases, and whether the port has changed, as long as there is a service name.

Avoid pit namespace

Nacos has a default namespace named public, which cannot be deleted, and all configurations that do not specify a namespace will be placed under this namespace; the same Nacos has a default grouping named DEFAULT_GROUP, under which the default configuration is when no grouping name is specified.

For our application, in many cases, a Nacos cluster is used by multiple teams, so in order to facilitate management, we need to set our own namespace according to our business to store the configuration files of our business. The configuration files under this namespace decide whether or not to regroup according to each module.

You know, it's hard to change the contents of a configuration in the absence of a clear namespace division. The online configuration adjustment, one carelessness is the accident. If the configuration is updated automatically, there is no chance to regret it.

Fine configuration

The configuration file should be specific, and a configuration file should set one content. For example, the data source of MySQL is configured separately, and the data source of Redis is configured separately. If multiple Redis services are configured separately, they should be configured separately according to functional recommendations, because not all services require link configuration for each Redis. The respective services can refer to the corresponding configuration files separately as needed.

Separate all configurations into a configuration file to facilitate subsequent configuration changes, as long as modify a configuration file, do not have to worry about other unmodified places.

Reasonable planning of the content of the configuration file, often can get twice the result with half the effort, greatly save time and reduce the probability of error.

Automatic refresh

I described how to set the configuration to refresh automatically, but whether the service needs to update the configuration automatically depends on its own business.

I generally do not recommend setting automatic updates here, because now they are all deployed for micro-services. Sometimes, when we launch a new feature, it will be released in grayscale. If the configuration is automatically updated, and after the configuration is adjusted, all instances will take effect. It's risky. If we do not set automatic updates, we can restart individual instances individually, observe the online situation, and release all services when they are stable, which will be much safer.

Of course, for scenarios where there are not so many services, no grayscale and little impact, it is much more convenient to configure automatic updates, and there is no need to restart the service after modifying the configuration.

At this point, the study on "the pit of Nacos access and how to avoid it" 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.