I have been working on a project that is being built around a microservices architecture. We are thinking on using a message broker, such as RabbitMQ, for both synchronous (via RPC) and asynchronous communication between services.
The team is constituted of Java developers, and all of the services are Spring Boot.
Suppose the following scenario:
- ServiceA needs to know the address to connect to the RabbitMQ server, and its credentials. ServiceA posts a message to an exchange in the message broker. This payload is built of
ClassAserialized as JSON.
- ServiceB also needs to know the address to connect to the same RabbitMQ server, and its credentials. ServiceB is subscribed to the same exchange as ServiceA a consumer. ServiceB also needs to have
ClassAwithin the project so that it can deserialize the payload sent by ServiceA.
We dont want to couple or duplicate data/functionality so that we can reuse things as much as possible.
With the current approach we are duplicating the classes between services, so that they can serialize/deserialize it. Also, we are duplicating the information necessary to connect to the RabbitMQ server, and publish/consume messages.
What is the standard approach to this? I feel that this is a common problem of microservice projects but could not find a pragmatic answer yet.
- Should we externalize this classes used for serialization/deserialization to a common library? Do microservices architecture have a standard name for such library?
- Should we also create a library to share the RabbitMQ server connection info, and credentials, between the services?
- Where should the pub/sub logic be? Should we leave each microservice to import the RabbitMQ client dependency, or should we create a library that "teaches" the microservices how to pub/sub certain messages?