RabbitMQ In Event-Driven Communication Between Microservices
Microservice
A microservice architecture now a days very import for businesses to scale and maintain their application. Development, testing, and updates of individual microservices can be done continuously and independently. Compared to more monolithic design structures, microservices offer more agile approach to software development and maintenance.
Microservices are decouple from each other but able to communicate with other services ,single microservice can not perform without getting support form other microservices. There are different services to use as a connection between microservices, such as:
- REST APIS
- Remote Procedure Calls (RPC)
- Brokers (eg: RabbitMQ , ActiveMQ , Kafka)
RabbitMQ VS Kafka
Apache Kafka and RabbitMQ are two open-source message broker and commercially-supported pub/sub asynchronous processing systems.
RabbitMQ
RabbitMQ is one of the most widely used open-source message brokers. It is lightweight , easy to used and support most of the technologies like Kubernetes ,Docker, languages such as .NET ,Java, Python or Go. It also offers plugins for monitoring, managing or authentication.
RabbitMQ Architecture
RabbitMQ was originally based on the Advanced Message Queuing Protocol (AMQP).In the RabbitMQ architecture main components are Producer application ,Exchange ,Queue and Consumer application.
In here we will take a use case example to understand better how RabbitMQ components are work each other.
Use Case: In this system when user create an doctor appointment ,system should be able to trigger an email to the relevant parties. In this cluster lets say we have couple of queues patient-notification(notify to the patient) , doctor-notification(notify to the doctor) , admin-notification(notify to the hospital administration).
Producer
Producing means nothing more than sending a messages .A producer pushes messages to exchanges.
Ex: Producer is a web base application, once user create an appointment ,producer send a message to queue ,In this message object include email details and other necessary details .
Exchange
Exchange is basically a routing rule for the messages. Messages are not published directly to a queue; instead, the producer sends messages to an exchange. An exchange is responsible for routing the messages to different queues with the help of bindings and routing keys. A binding is a link between a queue and an exchange. There are four types of Exchanges Direct ,Fanout ,Topic and Header exchange .
- Direct Exchange: The message is routed to the queues whose binding key exactly matches the routing key of the message. Ex: If the patient queue is bound to the exchange with the binding key patient-notification, A message published to that exchange with a routing key patient-notification will send the message to the patient queue. It will send email to patient.
- Fanout: A fanout exchange routes messages to all of the queues bound to it. Ex: When the user create an appointment ,It will route to all the queues ,that means send an email to patient ,doctor and hospital administration.
- Topic: The topic exchange does a wildcard match between the routing key and the routing pattern specified in the binding. Ex: If the user cancel the appointment ,system only needs to send an email to doctor and hospital administration.so message push to doctor-notification ,admin-notification.
- Headers: Headers exchanges use the message header attributes for routing.
Queue
A queue is a line of things waiting to be handled, starting at the beginning of the line and processing it in sequential order.
A message queue is a queue of messages sent between applications. It includes a sequence of work objects that are waiting to be processed. A message is the data transported between the sender and the receiver application; it’s essentially a byte array with some headers at the top.
The basic architecture of a message queue is simple; there are client applications called producers that create messages and deliver them to the message queue. Another application, called a consumer, connects to the queue and gets the messages to be processed. Messages placed onto the queue are stored until the consumer retrieves them. Once consumer consumed the message successfully ,consumer send ack(acknowledgment) to the queue ,then RabbitMQ will delete the message from the queue.
A message queue provides an asynchronous communications , which is a system that puts a message onto a message queue and does not require an immediate response to continuing processing. Message Queue contains FIFO (first in first out) if there is no priority queue.
Consumer
Consumer also known as a subscriber. It reads messages from the queues and send the ack to the RabbitMQ .
Ex: In our use case consumer is application , it will get the email message object from the queue and process the object check the validation of the email object ,send a email to the end user.
Conclusion
Using RabbitMQ, you can avoid direct HTTP calls between services and remove tight coupling of core microservices. This will help you in scaling your microservices at a higher level and add failover mechanisms between microservices.
Deploying RabbitMQ Cluster On Kubernetes -Part 1
Schedule Message Delivery using AWSMQ ActiveMQ and MassTransit- 3
Enjoy!!! stay safe
