How to Use Spring Cloud Bus with RabbitMQ for Automatic Config Refresh

Background

When a configuration file is updated, each Spring Cloud client normally needs a manual /refresh call to obtain the new values. As the number of clients grows, this manual approach becomes impractical.

Spring Cloud Bus as a Message Bus

Spring Cloud Bus (often called a message bus) connects distributed nodes via a message broker such as RabbitMQ or Kafka. By publishing a refresh command to the broker, all nodes can receive the change and update their configuration automatically.

Interaction Flow

1. An external request calls client A’s /bus/refresh endpoint. Spring Cloud Bus forwards the refresh command to the MQ server.

2. The MQ server pushes the command to other clients via the Bus.

3. Clients B, C receive the message and invoke their own refresh service to pull the latest configuration.

Practical Implementation (RabbitMQ)

1. Add Dependency

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

2. Configure RabbitMQ

# RabbitMQ server address
spring.rabbitmq.host=127.0.0.1
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

3. Service Startup and Test

Start eureka-server, eureka-config-server and eureka-config-client-bus on different ports (e.g., 9022, 9023). Modify the remote configuration property blog.name=hahaha to blog.name=hahaha123456, then send a POST request to /bus/refresh. The client logs show:

Received remote refresh request. Keys refreshed [config.client.version, blog.name]

Access the client’s endpoint (e.g., http://localhost:9023/hello) and verify the updated value.

4. WebHook Automation

Configure a Git repository WebHook to POST to the client’s /bus/refresh URL after each push, eliminating the need for manual calls.

Upgrade Version (Bus on Config Server)

To reduce client-side changes, move the Bus logic to the configuration server. The steps are similar: add the same spring-cloud-starter-bus-amqp dependency to the config‑server project, configure RabbitMQ in application.properties, and start the server alongside the clients. The server now pushes refresh commands, decreasing operational overhead.

Alternative with Kafka

Replace the AMQP starter with the Kafka starter:

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

Then add the appropriate Kafka broker properties to the configuration files.

Conclusion

By leveraging Spring Cloud Bus with a message broker, configuration changes can be propagated automatically across all microservice instances, eliminating manual refresh operations. The approach works with both RabbitMQ and Kafka, and can be further streamlined by placing the Bus logic in the configuration server.