Let me talk about the flow of the client to get the configuration file of config !, this is not understood, it is easy to enter the pit!
1. If the configuration file of the config client is application.properties
When the client starts the project, it directly finds its own properties. If there are properties in the project that refer to the properties at this time, the project starts directly with an error, because he will not go to the config server to find it, so he cannot find it and cannot start project! ! And showing fetch
config as localhost: 8888 means that he didn't go to config to get the configuration file. So we must rename application.properties to bootstarp.properties
2. When the configuration file of the config client is bootstrap.properties
At this time, the client first sees whether his properties have the registered address of the eureka server
1. If there is, register to the eureka server from the defaultZone defined in his own properties, and find the config server registered in the eureka server, so from the config Take the configuration file in the server and start the project after getting it.
2. If not, visit the default eureka server address: http: // localhost: 8761 / eureka. If the eureka server is on it, then it is found, if it is not, then the config server is also not found.
3. When there are multiple versions of properties on a branch of git, such as: client.properties,
client-dev.properties, client-test.properties
At this time, if the client specifies to take dev. However, on the config server side,
the two configuration files client.properties and client-dev.properties are put together and then given to the client. Therefore, if the two files client.properties and client-dev.properties have the same part, if you change one of them, it will not take effect, because they are for the client. Change both
So: rename application.properties to bootstrap.properties, and it is best not to change the port of eureka server to something else. Git a branch of multiple versions of the file, the original version and the extended version, do not appear the same content.
Now introduce the construction of config server and client side. The last section introduces automatic refresh
config Server：
1. Check when creating the springboot project, Eureka client + config Server
2. Create a repository on github, write a yml configuration file, or properties file
3. Add a comment to the startup class of the config server project:
4. Write its configuration file:
spring:
application:
name: config
cloud:
config:
server:
git:
uri: https://github.com/vanNo1/config-repo
username: xxxx
password: xxxx
# basedir: 存放从git上拉取下来的配置文件地址，也就是本地git
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
management:
endpoints:
web:
exposure:
include: "*"
This is to open the / bus-fresh interface for automatic refresh:
verification:
access in the browser after startup: localhost: 8080 / client-dev.yml
rule: /{label}/{name}…{profiles}.yml
name: service name (client)
profiles: environment (dev)
label (branch) defaults to master
yml: here can also be replaced by properties, the content displayed by json will be replaced by different formats
config client：
1. Join the dependency:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
2. Write the configuration file:
cloud:
config:
discovery:
enabled: true
service-id: CONFIG
profile: dev
spring:
application:
name: client
All others can be deleted, just keep these two, here is the application name of the config server project registered on eureka
Then change applicationProperties to:
Otherwise, start or read your own configuration file, instead of going to the config server to get the configuration center file
3. Start the client project, in fact, already got the configuration file from the config server, if you want to verify, you can Type the configuration file on the controller.
pit:
1. If the port number of the Eureka server is not the default of 8761, I changed it to: 8762.
Then the config client will report an error, because it first registers itself with the eureka server, and then goes to the config server to get the configuration file. Now its own configuration file does not write the address registered by eureka, so it can only access the default eureka server port is 8761. But I changed the port to 8762 again, so of course it will report an error. The correct way: directly write the registration configuration: defaultZone in its configuration, not in the configuration center.
2. If there is something like: client.yml, client-test.yml, client-dev.yml on git. That is, there are many client versions of yml at the same time. If my client uses the dev version in the configuration center, but I changed the dev yml, there will be no change. Because, in the configuration center, it loads client.yml and client-dev.yml together for client projects, so if you change client-dev.yml, you have to change client.yml. Generally put the main configuration in client.yml. Put the extended configuration in other versions
。。。。。。。。。。。。。。。。。。。。。。。
The following automatic refresh
What I have done above is still unable to achieve automatic refresh, which means that once I change the configuration file, the client still has to restart the project to refresh the configuration.
The principle of automatic refresh:
the top picture has already been said. When the client starts, go to get the file in the config server,
but the config server changes the file, but it will not notify the config server that the information has changed, let him retrieve it again. So the client project must be restarted.
Now: Let the config server implement the spring cloud bus, which will expose an interface, / bus-refresh interface. As long as the post is used to access this interface, the config server will send a message to MQ and then MQ to the client to let the client get a configuration file again. And this / bus-refresh is issued by git
. . . . . . . . . . . . . . . . .
achieve:
1. Add dependency in config server:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
After ok, visit localhost: 15672 in the browser to see rabbitMQ start.
This dependency is also introduced in the client. At this time, you will find that rabbitMQ has another queue
to open the bus-refresh interface in the config server. :
If the file is of the properties type: write this way:
management.endpoints.web.exposure.include=*
Restarting the config server will appear, "Endpoint ID bus-refresh contains invalid characters please migrate to a valid format", I thought at the beginning that there was no opening success. Port, and then checked a lot of information to find out what conflict is the spring version. but! ! ! ! ! I tried it, it does not affect my access to this interface
The following is an annotation in the client's controller:
After that, as long as the configuration file on git is changed, and then use the post to access the bus-refresh interface, the client project can automatically update the configuration without restarting:
Visit localhost: 8080 / actuator / bus-refresh
new version to add actuator
About the config server cluster: just create a few more instances directly, and the client will access different instances of the config server on its own
In fact, configuring webhooks on git has been unsuccessful. Checking various methods is useless, even forwarding it in the controller, and then using restTemplate to post request bus-refresh is not successful. . . Let ’s do it in the future, and hope that a great god can provide some methods
