Spring Cloud Bus: Centralizing Message Broker (RabbitMQ or Kafka) connection properties with Spring Cloud Config Server

 

The Problem

In previous article, we have discussed how to use Spring Cloud Bus to broadcast the  configuration property changes (occurred in the Spring Cloud Config Server) across distributed services.

Spring Cloud Bus links or connects the distributed services through a lightweight message broker such as Kafka or RabbitMQ.  whenever the refresh event is triggered in one service, Spring Cloud Bus will broadcast the refresh event across multiple services (known as Config Clients).

Therefore every Config Client should connect to the underlying message broker (that can be either RabbitMQ or Kafka) of the Spring Cloud Bus to listen for the refresh events published/broadcasted. This will lead every Config Client to keep a connection with message broker implemented in the Spring Cloud Bus.

Untitled Diagram (6).png

 

As you can see that we have three distributed application services and those are listening to the RabbitMQ Message Broker through Spring Cloud Bus.  The connection properties related to the RabbitMQ is declared in the application service themselves.

If the connection properties are changed, then all the applications have to be changed, rebuild and redeployed. This is not practical in a complex environment  due to large number of distributed services.

 

The Solution

The better solution is to make use of the Spring Cloud Config Server to maintain the Message Broker related properties. This can be done with placing all the connection properties related to the Message Broker in the application.properties (.yml).

 

Why it is put in the application.properties (.yml)? 

Any property that is added in to the application.properties (or .yml)  will be shared among all services.  Therefore if you want some properties to be shared among all or few services, add them into a file called application.properties (or application.yml) and commit the file. Then the Spring Cloud Config Server will enable those properties available for all services (as shared properties).

 

Untitled Diagram (7).png

 

If the any of the connection property is changed, then it can be reflected in all connected services by invoking /actuator/bus-refresh endpoint of any of the avaialble services.

 

 

Why this approach is considered to be good?

 

maintaining in application.properties (.yml)

In the best case scenario, the property changes will get reflected once the changed are pushed and invoking the /actuator/bus-refresh in any of the services.  In the worst case scenario, all the services need to be restarted. that is all !.

 

maintaining in application service itself

But if you maintain the connection details in the application service itself, whenever the property is changed, the application need to be changed, rebuild and re-deployed. This will add few additional steps and additional efforts to the worst case scenario of maintaining in application.properties (.yml)

 

 

 

One thought on “Spring Cloud Bus: Centralizing Message Broker (RabbitMQ or Kafka) connection properties with Spring Cloud Config Server

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s