Distributed Rabbitmq within a spring-cloud environment

Question

I am trying to setup a distributed system based on current spring-cloud release (meaning mostly Netflix OSS) using the following components

• 1 or more cloud config servers
• 1 or more Eureka servers
• 1 or more services using Eureka and Config Server clients

The setup above is easy enough to get going however once you start looking into setting up so that configuration changes in the cloud Config servers automatically trigger changes in the values of the actual clients, things start getting more complicated.

It is my understanding that for such a feature to work one should introduce spring-cloud-bus clients to the services which in turn will use, currently the only supported implementation, rabbitmq servers (the actual rabbitmq binaries and not some spring-boot app like eureka or Config servers) to allow change events in the Config server to be propagated to the clients automatically.

It sounds counterintuitive to setup such a system and have to hardcode addresses to rabbitmq servers in the clients (even if one will be keeping the amount of rabbitmq servers more or less static).

How is one supposed to register rabbitmq server instances in the Eureka service discovery server(s) to allow for clients to find them without having to have any knowledge about their location prior to startup?

I cannot seem to find any documentation on how this is done given that rabbitmq is not a spring-cloud component. In fact very little documentation seems to exist regarding on how the rabbitmq + eureka + spring-cloud-bus should be setup together.

Griner

You'd put the rabbitmq information in config server. The bus in Brixton also supports redis and kafka. – Obovoid

You mean hardcode the address of the rabbitmq server as a property in the config server? I don't see that to be much different than hardcoding it in the application and besides how would that even work? The config server itself needs that information to push events creating a chicken / egg problem. Yes Brixton supports others however it is under a Milestone release and technically not production ready at the moment. – Griner

It's very different from hardcoding rabbit in the application. There is no, chicken and egg problem. The configuration is retrieved from config server before connections to rabbitmq are made for the first time. This project uses the bus github.com/spring-cloud-samples/customers-stores. Configuration is done via boot docs.spring.io/spring-boot/docs/current/reference/html/… – Obovoid

By chicken and egg I mean that the configuration server itself needs to connect to the bus while providing that information to clients connecting to it. Yes it is possible but how does one get around adding new bus backend servers (aka rabbitmq) on the fly and getting them registered with services? – Griner

The config server can itself use the configuration it serves to clients. – Obovoid

It doesn't need to connect to rabbit before it gets configuration information. – Obovoid

Yes but what if the rabbitmq instances configured in the configuration server were to go down and completely new ones, not configured anywhere, we're brought up instead, for example. Since there is no service discovery for the rabbitmq instances, the configuration server and services would no longer be able to communicate through the bus since they would not know the address of the new backend instances which is my understanding one should solve in a distributed system. This is what I am confused about. – Griner

Because we are taking about a distributed system where instances can go up and down changing ip at will, should not the bus backend also register on Eureka rather than hardcoding addresses on the config server which may no longer be valid after a certain amount of time? – Griner

That is a shortcoming of Eureka. Consul has a better story for registering non-jvm, non-http applications. – Obovoid

Answer 1

I know that I am on a VERY old question, even though I think it worth a comment for people who read this in the future.

Most of the cloud services, lets take AWS as an example, have an Elastic IP solution - so you can configure IPs for RabbitMQ servers, and the IPs always belong to the RabbitMQ, no matter whether the instances change. You can re-attach the Elastic IP to different instances.

It works nearly the same with Elastic Load Balancer, which keeps its IP, so you could configure your microservices to a specific IP using Spring Cloud Config Server - and scale the RabbitMQ instances without a need to worry about configuration change.

Fuchsin