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.
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).
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”