Asynchronous Communication Between Microservices Using AMQP and Vert.x

Asynchronous Communication Between Microservices Using AMQP and Vert.x

Microservices are the go-to architecture in most new, modern software solutions. They are (mostly) designed to do one thing, and they must talk to each other to accomplish a business use-case. All communication between the microservices is via network calls; this pattern avoids tight coupling between services and provides better separation between them.

There are basically two styles of communication: synchronous and asynchronous. These two styles applied properly are the foundation for request-reply and event-driven patterns. In the case of the request-reply pattern, a client initiates a request and typically waits synchronously for the reply. However, there are cases where the client could decide not to wait and register a callback with the other party, which is an example of the request-reply pattern in an asynchronous fashion.

In this article, I am showcasing the approach of asynchronous request-reply by having two services communicate with each other over Advanced Message Queuing Protocol (AMQP). AMQP is an open standard for passing business messages between applications or organizations. Although this article focuses on the request-reply pattern, the same code can be used to develop additional scenarios like event storming. Communicating using an asynchronous model can be very beneficial for implementing the aggregator pattern.

I will be using Apache QPid Proton (or Red Hat AMQ Interconnect) as the message router and the Vert.x AMQP bridge for communication between the two services.

Solution Components

This demo has three components:

1. frontend: This is a service written in Java and provides an HTTP endpoint to receive calls from clients. Upon receiving a request, the frontend service sends the call to the QPid router and registers a reply handler. The reply handler will be invoked by the Vert.x AMQP bridge when the response is available. The frontend folder in the codebase hosts this project.
2. QPid router: The frontend process takes the call and posts a message to the QPid queue. Vert.x automatically takes care of adding a correlationId as the message property to identify a response to the original request.
3. backend: The backend component listens for the message in the call from the QPid router, process it (e.g. doing a calculation or persisting in a database), and sends the response back to the QPid router. The QPid router will then notify the frontend component with the response. The backend folder in the codebase hosts this project.

Message Flow

The basic flow of the messages across different components is as follows. The full details of this flow along with the relative headers can be found here.

1. The frontend service will send a message to a QPid server and provides a reply handler. Vert.x automatically populates the required headers needed for request-reply communication.
2. The receiving application, the backend service, consumes the message and sends a reply back to the QPid server. Vert.x populates the required headers needed for request-reply communication.
3. The QPid server dispatches the reply message to the frontend service's reply handler. Vert.x bridge handles the invocation of the reply handler automatically.

Clone this GitHub repo to get the example code.

How to Run the Example: Quickstart

You can use the Docker Compose file to run all three components of this example, by issuing the following command:

docker-compose up

How to Run the Example: The Hard Way

This section summarizes how to run each component individually. You need the following software to run them on your laptop.

1. Docker (for executing the Apache Qpid router)
2. Open JDK 8 (to compile the frontend and the backend service components)
3. Maven 3.2 (both services use Maven)
4. Vegeta as an HTPP client (or you can use your favorite tool for this)

Execution

docker run -it -p 5672:5672 ceposta/qdr

cd frontend 
mvn clean install
java -jar target/frontend-service-full.jar

cd backend 
mvn clean install
java -jar target/backend-service-full.jar

Testing

Vegeta, an open-source tool for HTTP load testing, can be used to post requests to the frontend component.

echo "GET http://localhost:8080/" | ./vegeta attack -duration=60s -rate=50 | tee results.bin | ./vegeta report

Verifying the Number of Messages and Latency

QPid provides an ultra-fast backbone as an asynchronous hub for communication between services. Once you finish testing your application, you can log into the QPid router's Docker container using its IMAGE ID and run qdstat to see various metrics.

docker exec <container-name> qdstat -c
docker exec <container-name> qdstat -l
docker exec <container-name> qdstat -a

Conclusion

Apache QPid provides an ultra-fast backbone for communication between microservices. Since AMQP is a wire-level protocol, services written in other stacks (like .NET) can also use the same communication channel. Java developers can easily adapt to the AMQP-based asynchronous inter-services communication pattern using the Vert.x AMQP bridge.