Which RPC and Message Bus implementations should be considered for a microservice architecture?

Question

Python

There is a large project in the field of trading that has a SOA similar architecture. At the moment, all this looks like a number of microservices, the contents of which are encapsulated from each other: for example, one microservice does not have direct access to the database of another. Most of the services are written in python, services are also meant in go. All this is running on a docker swarm cluster.
The service interaction interface is RabbitMQ, through which both remote procedure calls and data exchange are implemented at once.
Next, I will describe the main cases of using such interaction:
1. Data request:
Service A sends a message to service B, proceeds to execute its logic, and upon completion, blocks the runtime, waiting for a response in the callback queue.
Example: requesting current stock prices to calculate the value of assets
2. One-way remote procedure call:
Service A sends a message to service B and proceeds to execute its logic.
Example: request to send an email notification
3. Event initialization for multiple services:
Service A sends a message to a queue listened on by services B, C, D. The message is removed from the queue after all services have reported reading it.
Example: the event of registration of a new user in the system, according to which various records are created for him in different services.
This is now implemented using our own library based on pika .
Available problems:
1. Speed: often you have to drive quite large data through this bus (for example, annual drain charts).
2. Resources: RabbitMQ stores everything in RAM, it becomes especially painful when failures occur in the processes of callback queue subscribers and the data hangs for some time in RabbitMQ memory. There was a case when, due to a bug in such a process, a memory overflow occurred under load and the node hung.
3. The need for their own high-level library, primarily for the implementation of an event-driven model (a long search did not give suitable libraries).
Obvious solutions:
1. Direct requests to data from other services:
Not suitable, as there is a desire to encapsulate services, plus many data involve processing before sending
2. Using the HTTP API for data exchange:
Not suitable, since in this case asynchrony will have to be implemented in the business logic of the service and hold the connection. If a failure occurs on the recipient side, the data will be lost
. The final interaction architecture seems to be event-oriented, most of the calculations, data downloads from external services occur in the background according to some events or schedules, data is given to the client mainly from caches.
While the JSON REST API is used as a client-server interface, there are thoughts on migrating to websocket with GraphQL inside, since realtime and reactivity are needed.
Returning to the question in the title, I’ll clarify that I’m looking for libraries / frameworks for AMQP suitable for the case, as well as other stacks. I also enjoy reading comments and advice on the whole architecture in general and its possible alternatives. In the end, there is not much information on the net and it may be useful to someone.

Answer 1

In my opinion, RabbitMQ is the bottleneck for you, not only is it slow in itself, but it is also excessively overloaded. You need to get rid of it as much as possible.
To perform remote procedures , RPC or its more advanced analogue GRPC has long been invented, which drives data in a binary format, which reduces the size of requests and increases the transmission speed, which can also be useful for you to implement a request for data . It seems that if you remove the first two points, it will become much easier for the rabbit and perhaps it will be possible to stop at this, if not, then it might be worth abandoning it in favor of Nats, look, it can greatly please you with its performance. Well, or you can look towards Redis, it also surpasses the rabbit in the implementation of queues and, in my opinion, is great for implementing an event-oriented architecture.

Answer 2

As an option, do not drive the entire requested and sent amount of data through RabbitMQ, but send only the identifier. The data itself is stored in the database.