Configuration Center Introduction
Spring Cloud Config provides server-side and client-side support solutions for the external configuration of distributed systems. On the server side of configuration is the central place where you can manage external properties for your application in all environments. The Spring Environment and PropertySource abstractions on the client and server are kept in sync, and they are well suited for Spring applications, but can be used with applications running in any language. As applications move through the deployment pipeline from development to testing to production, you can manage configuration between these environments and ensure applications have everything they need to run as they migrate. The default implementation of the server's storage backend uses git, so it easily supports tagged versioned configuration environments and is accessible by various tools for managing content. It's easy to add alternative implementations and plug them in with Spring configuration. Spring Cloud Config consists of two parts, Client and Server. The server provides the storage of the configuration file and provides the content of the configuration file in the form of an interface. The client obtains data through the interface and initializes its own application based on this data. Spring cloud uses git or svn to store configuration files, and git is used by default.
Nacos replaces Config
Nacos can be integrated with Spring, Spring Boot, Spring Cloud, and can replace Spring Cloud Eureka, Spring Cloud Config. Dynamic configuration changes are realized through Nacos Server and spring-cloud-starter-alibaba-nacos-config.
Application Scenario
During the system development process, developers usually separate and manage some parameters and variables that need to be changed from the code, and exist in the form of independent configuration files. The purpose is to make static system artifacts or deliverables (such as WAR, JAR packages, etc.) better adapt to the actual physical operating environment. Configuration management is generally included in the process of system deployment and is completed by system administrators or operation and maintenance personnel. Configuration changes are an effective means of adjusting the behavior of a system at runtime. If the unified configuration center is not used in the microservice architecture, the existing problems: - Configuration files are scattered in various projects, which is inconvenient to maintain - Configuration content security and permissions - After updating the configuration, the project needs to restart the nacos configuration center: system configuration Centralized management (editing, storage, distribution), dynamic update without restart, rollback configuration (change management, historical version management, change audit) and other configuration-related activities.
nacos use
First prepare a microservice project here to prepare a practice project
naocs-dependency
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>Configure in the configuration file:
Start nacos first, here is the window version of nacos
Startup project
Check whether the port number after project startup is consistent with the port configured above
Enter the Nacos access address http://localhost:8848/nacos on the browser , and enter the default account password (both are nacos)
Log in, and in the service list, you can see that the service name configured in the configuration file just now is displayed in the list, indicating that the registration is successful
Now create the configuration file in nacos
Comment out all the contents of the configuration file in the local project
Add dependencies to the service's pom file
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>Supplement: springboot configuration file loading order
In fact, yml and properties files are the same principle, and there is either yml or properties on a project, and one of the two exists. It is recommended to use yml, which is more concise. org.springframework.cloud spring-cloud-starter-alibaba-nacos-config #Configuration center address spring.cloud.nacos.config.server-addr=127.0.0.1:8848 #spring.profiles.active=dev #This configuration affects unity dataId in the configuration center spring.application.name=service-statistics 1 2 3 4 1 2 3 4 5 6 7 bootstrap and application (
1) Loading order This mainly explains the loading order of application and bootstrap. bootstrap.yml (bootstrap.properties) first loads application.yml (application.properties) and then loads bootstrap.yml for the bootstrap phase of the application context. bootstrap.yml is loaded by the parent Spring ApplicationContext. The parent ApplicationContext is loaded before using application.yml.
(2) Configuration difference Both bootstrap.yml and application.yml can be used to configure parameters. bootstrap.yml can be understood as some parameter configurations at the system level, and these parameters generally do not change. application.yml can be used to define application level.
Create the bootstrap.properties file
restart project
It can be seen that the port number of the project reads the port 8777 configured in nacos, indicating that the project reads the configuration file of nacos successfully
Open in the bootstrap configuration file
spring.profiles.active=dev
Create a spring.profiles.active=dev configuration file in nacos
publish configuration file restart project
You can see that 8666 is read at this time, which is our newly created configuration file
Namespace switching development configuration environment
In actual development, there are usually multiple sets of different environments (the default is only public), so at this time you can create different namespce according to the specified environment, for example, three different environments for development, testing, and production, then use a set of nacos The cluster can build the following three different namespaces respectively. In order to achieve the isolation of multiple environments
Create three namespaces dev test prod in nacos
Clone configuration files in the configuration list
In order to facilitate the distinction, we changed the port number of the dev configuration file just cloned to 8555
Add read dev configuration in bootstrap configuration file
spring.cloud.nacos.config.namespace=795de664-a841-4a11-bf25-3b6acdf90ee6
restart project
It can be seen that the port number of the project at this time reads the port 8555 of dev
Load multiple configuration files
Sometimes it is necessary to read multiple configuration files in a project, and each configuration file is put into a specific configuration
In the dev namespace of nacos, create a new configuration file port.properties that only stores the port number, and comment out the port number of the original dev configuration file just now.
Add the reading of the port configuration file in the bootstrap configuration file
spring.cloud.nacos.config.ext-config[0].data-id=port.properties spring.cloud.nacos.config.ext-config[0].refresh=true
restart project
You can see that the port number becomes 8444 in the port configuration file at this time