The Config in the previous section solves the problem of complex configuration files, but it has a drawback that when we change the server code, that is, when things are changed on Gitee, we need to start the service again to make the changes take effect.

To solve this problem, SpringCloud introduced the Bus, which those of you who have studied networking will remember. Like a broadcast, this article is the final chapter of the SpringCloud starter series.

The introduction of Bus

Create an empty parent bus module, modify the parent module’s POM file, import the corresponding dependencies for the use of the child module.

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-bus-amqp</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-config</artifactId>
    </dependency>
</dependencies>
Copy the code

Spring-cloud-starter-bus-amqp will know you need RabbitMQ. In practice, I usually use WSL2 to use docker, download rabbitMQ image and enable it.

You only need to visit http://localhost:15672 to check whether the download is successful. If the following page is displayed, the download is successful

The user name and password are guest. After logging in, you can see the following screen

A bus-config-Client9601 submodule is established under the bus parent module.

The configuration file

To obtain the content from the server, you need to set the related content of the server, that is, spring.cloud.config. XXX. You also need to set the related content of bus, RabbitMQ, actuator, Eureka, etc. The final configuration file is as follows:

server.port: 9601
spring:
  application:
    name: bus-config-client
  cloud:
    config:
      profile: dev
      label: master
      uri: http://localhost:8101	# server address
    bus:				# open bus
      enabled: true
      trace:
        enabled: true
  rabbitmq:				Set rabbitMQ information
    host: localhost
    port: 5672
    username: guest
    password: guest
management:				# open physical
  endpoints:
    web:
      exposure:
        include: bus-refresh	Enable the automatic refresh API

eureka:					# General setup eureka
  client:
    fetch-registry: true
    register-with-eureka: true
    service-url:
      defaultZone: http://localhost:8001/eureka/
  instance:
    instance-id: bus-config-client9601
Copy the code

Other configuration files are obtained directly from the server through Conifg

But since we are another project, we need to create a bus-config-client-dev.properties file in the Gitee repository.

Again, the profile name: {spring.application.name}-{profile}

The main start class

The main startup class is still relatively simple

@SpringBootApplication
@EnableEurekaClient
@RestController
@RefreshScope			// Enable auto-refresh annotations
public class BusConfigClient9601 {
    @Value("${name}")
    private String name;

    public static void main(String[] args) {
        SpringApplication.run(BusConfigClient9601.class, args);
    }
	
    // Simulate the business class
    @GetMapping("/get")
    public String getName(a) {
        return "hello, "+ name; }}Copy the code

test

Start a simple test by enabling the EurekaServer8001 service, ConfigServer8101 service, and BusConfigClient9601[9602(by modifying the boot class configuration file)] service

Access localhost:9601/ GET, modify the configuration file in gitee, and then send the POST request

http://localhost:9601/actuator/bus-refresh, visit the get interface again.

The re-read file can also be clearly seen on the control panel interface of IDEA

In order to refresh

Update BusClient9701 (BusClient9701, BusClient9701, BusClient9701);

The main boot class and configuration file are nothing to say, they are basically copies of the BusConfigClient9601 module

server.port: 9701
spring:
  application:
    name: bus-client
  cloud:
    config:
      profile: dev
      label: master
      uri: http://localhost:8101
    bus:
      enabled: true
      trace:
        enabled: true
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
management:
  endpoints:
    web:
      exposure:
        include: bus-refresh

#eureka:
# client:
# fetch-registry: true
# register-with-eureka: true
# service-url:
# defaultZone: http://localhost:8001/eureka/
# instance:
# instance-id: bus-client9701
Copy the code

Note out the eureka-related comments here to indicate that the config refresh is not eureka related

@SpringBootApplication
@EnableEurekaClient
@RestController
@RefreshScope				// We need this one
public class BusClient9701 {
    @Value("${name}")
    private String name;

    public static void main(String[] args) {
        SpringApplication.run(BusClient9701.class, args);
    }

    @GetMapping("/get")
    public String getName(a) {
        return "hello, "+ name; }}Copy the code

You can use http://[IP address :port port number]/actuator/bus-refresh/[spring.application.nema microservice name] to refresh specified microservices

Any microservice on the bus can be refreshed, which means there is no limit to IP :port

Leave the microservice opened above and open a new BusClient9701 service. The final service opened is as follows

Because the GIF image of modifying the configuration file and then accessing the port to see the result is relatively large, here we can see the result of the IDEA console.

The output for BusClient9701 in the console may generate an error or warning because Eureka is not registered, but is introduced.

Refresh of all bus service, send a post request at http://localhost:9701/actuator/bus-refresh. You can see that all of the microservices are again fetching resources from the server side.

Refresh the bus of the specified name service, send a post request to refresh the name http://localhost:9701/actuator/bus-refresh/bus-config-client for bus – config – client services. You can see that only the bus-config-client microservice obtains resources from the server again.

Refresh a specific port on a microservice, Send a post request to http://localhost:9701/actuator/bus-refresh/bus-config-client:9602 to refresh the name for the bus – config – micro service of client service of port is 9602. You can see that only the bus-config-client with port 9602 can obtain resources from the server.

Again, the above updated urls can be refreshed as long as the microservices on the bus. There is no limit to IP :port

http://localhost:9701/actuator/bus-refresh/bus-config-client:9602 and http://localhost:9601/actuator/bus-refresh/bus-config-client:9602 The effect of (http://localhost:9602/actuator/bus-refresh/bus-config-client:9602) is the same.

This is the end of the SpringCloud Primer series. It is not easy to create. If it is helpful to you, please like it, bookmark it and share it!