[Course] RabbitMQ by Example

RabbitMQ is used to produce synchronous and asynchronous systems.

Introducing RabbitMQ

Compared with other Messaging Systems:

• RabbitMQ is a distributed system, others are centralized.
• RabbitMQ plays into a Clustered environment for high availability.
• RabbitMQ is multiplatform, and MSMQ is Windows only.
• RabbitMQ is a standard-based but MSMQ not.

Also RabbitMQ is multiplatform and there are MQ clients for several programming languages.

Introducing RabbitMQ Exchanges

What is AMQP Protocol

It is Advanced Messaging Queueing Protocol. It is a standard. Rabbit supports 0.9.1. It also supports AMQP 1.0.

Also,

What about AMQP 2.0

Here.

Understanding Queueing Architecture

Compared with other Messaging Systems:

Desired Properties

• Durability: inmemory o database
• Security Policies: access control
• Messaging Purging: time to live
• Messages filtering:
• Deliver Policies: guaranteed to deliver
• Routing Policies: which receives messages
• Batching Policies: to deliver one inmmediately or many messages at time
• Queueing Criteria: which could get requeue
• Receipt Notification: notify if consumers have received the message

Common Use Cases for Messaging

1. Decoupling. To allow integration between applications implementing a layer and allowing the applications to grow in a separate way independiently.
2. Redundancy. For the cases when processes failed, the solution is to have persisted data in the middle to allow reprocessing.
3. Scalability. Messaging systems decouple the processes. Adding more processes to a backend solution (to the full chain).
4. Resiliency. The messages are processed later when the processes are up. No lost of information.
5. Delivery guarantees. Guarantee the message is always processed.
6. Ordering guarantees. The data is processed in specific order.
7. Buffering. Upload image, buffering layer.
8. Asynchronous Communication.

Microservice Architecture

1. Single responsability principle. Do one thing and do it well.
2. Service autonomy. Each service deploys independently.
   1. Identical Server Deployments
   2. Each service has its own server
   3. Platform as a Service
   4. Containers (Docker), runs in isolated container
3. Benefits:
   1. Technology diversity
   2. System resilience. MS can handle total failure of services and degrade functionality accordingly.
      1. The capability to recover quickly from difficulties
      2. The ability of a system to cope with change
   3. System scaling
      1. X Axis scaling (Horizontal Duplication Scaling by Cloning - Behind a load balancer there are multiple copies). It does not handle or manage the functionality complexity and changes.
      2. Y Axis scaling (Functional Decomposition - Scale by splitting different services). One action / operation / noun implemented by a service. Atomically.
      3. Z Axis scaling (Data Partitioning - Scaling by Splitting Data). Each service attending a subset of data. Divide by customer type.
   4. Easy of deployment
      1. Commit changes
      2. Compile code
      3. Static code analysis
      4. Execute test
      5. Packaging
      6. Deploy to environment

Asynchronous Microservices

• Synchronous
• Asynchronous
• Request / Response
• Event Based

Implementing Microservices and Message Queueing

Technical Requirements

Asynchronous payments for direct customers

Synchronous payments for call center

Queue persistence, for resilience

Scale Out consumers

High Level Design

API and Processors, in the middle a Queue.

Development

• Implement Web API
• Implement Customers
• Topic based Publisher and Suscriber
• RPC

This is the Topic Architecture:

For RPC architecture:

References

https://www.amazon.com/Art-Scalability-Architecture-Organizations-Enterprise/dp/0134032802

http://theartofscalability.com/

https://github.com/spring-cloud/spring-cloud-stream-app-starters/tree/master/rabbit/spring-cloud-starter-stream-source-rabbit