Messaging Pattern In Micro Service Integration

The goal of this article is to provide information to developers who are considering microservice integration using Event Driven Architecture and Messaging.

Context

In a monolithic application, software components invoke one another using language-level methods or function calls, and the objects are typically running within the same process on the same server.

In a microservices architecture, components are distributed and can be run on multiple processes across multiple servers. They communicate with one another across a network using an inter-service communications protocol. There are several factors to consider when selecting an inter-service protocol. Messaging is one that can provide many advantages, but it's not always appropriate for every App.

Inter-Service Communication Types

The selection of an inter-service communication protocol should be made with consideration of the service's goals and use cases. They are classified as either synchronous or asynchronous and by the number of receivers (single or multiple).

Synchronous or Asynchronous

The first distinction between inter-service communication protocol types is whether they are synchronous or asynchronous.

Synchronous

In synchronous communication, the client sends a request and waits for a response from the service. The client code can only continue its task after it receives the server response. The protocol (HTTP/HTTPS) is synchronous.

If possible, avoid depending on synchronous communication (request/response) between multiple microservices, including for queries. Having HTTP dependencies between microservices not only makes your microservices not autonomous but also their performance is impacted if one of the services in the chain is impaired.

It's considered an anti-pattern when a "chain" of HTTP requests is created between microservices while serving a client request. This causes the client response to be delayed and dependent on the performance of all microservices in the chain. A better implementation would be to use asynchronous communication using Messaging in which the client request is served right away.

Asynchronous

In asynchronous message communication, the client or message sender usually doesn't wait for a response. It just sends the message to a message queue or message broker. This enforces a microservice's autonomy.

• AMQP - The Advanced Message Queuing Protocol has been developed to provide a platform-agnostic method to ensure messages can be easily exchanged between services. Most of the major messaging systems have adopted this standard.

Number of Receivers

The second distinction between inter-service communication protocol types is if they are communicating to a single receiver or multiple.

Single Receivers

In a Single Receiver design each request must be processed by exactly one receiver or service. An example of this communication is the Command pattern.

Multiple Receivers

In a Multiple Receiver design, each request can be processed by zero to multiple receivers. This type of communication must be asynchronous. An example is the publish/subscribe mechanism used in patterns like Event-driven architecture. This is based on an event-bus interface or message broker when propagating data updates between multiple microservices through events; it's usually implemented through a service bus or message broker by using topics and subscriptions.

Combining Communication Methods

A microservice-based application will often use a combination of these communication methods. The most common type is single-receiver communication with a synchronous protocol like HTTP/HTTPS when invoking a regular Web API HTTP service. Microservices however, typically use messaging protocols for asynchronous communication between microservices.

Event-Driven Microservice Architecture

Events are records of something that has happened, a change in state. They are immutable (they cannot be changed or deleted), and they are ordered in the sequence of their creation.

Event-driven architecture refers to a system of loosely coupled microservices that exchange information between each other through the production and consumption of events. Interested systems can be notified of these state changes by subscribing to published events and then acting on the information using their business logic. This is referred to as the Pub Sub Pattern.

The main benefits of event-driven systems are asynchronous behavior and loosely coupled structures.

Benefits of the Event-Driven Microservice Architecture:

• Loosely coupled structure
• Asynchronous event-driven functionality
• Isolation of the microservices
• No synchronous REST calls
• Performance

Events and Domain-Driven Design

In the Domain-driven design (DDD) approach to software development, the business domain is carefully modeled in software and evolved over time, independently of the infrastructure that makes the system work. DDD is used to define the different bounded contexts that represent the various business processes that the application needs to perform.

These contexts are then joined together with events, creating a unidirectional dependency graph that decouples each bounded context from those that arise downstream, to create rich event-streaming business applications.

Messaging Systems

Enterprise Application Integration (EAI) is the implementation of technologies that facilitate communication between enterprise applications and microservices. EAI establishes a middleware framework that helps data flow freely between services without significant changes to the applications themselves.

Enterprise Messaging Systems (EMS) are the Middleware that facilitates the exchange of messages between microservices. Referred to as Message-Oriented Middleware (MOM), it's the infrastructure supporting sending and receiving messages between distributed services.

Messaging Architectures

EAI architecture is made up of the following components.

• Producer - Entity which creates the event (also known as the Publisher).
• Consumer - Entity which consumes the event (also known as the Subscriber).
• Topic - Category name to which messages are published and stored.
• Endpoint - The network point at which consuming entity is connected to the MOM.
• Broker - Single central controller which contains the MOM logic.
• Bus - Architecture where the endpoints contain the logic rather than a single entity.
• Routing - Sending the message to the interested parties.
• Transformation - Modifying the message so that it can be understood by a subscriber.

Message Broker vs Message Bus

Messaging systems have two primary architecture designs, Message Broker and Message Bus. The Message Bus architecture is an advanced way of implementing EAI.

Message Broker Architecture

The first inter-service communications solutions incorporated all the functionality required for integration into a central hub called the "broker". A key point in this model is the broker contains the logic.

In a broker approach, a central piece of software (the "message broker") resides in the middle of the network, and provides all message transformation, routing, and any other inter-application functionality. All communication between applications must flow through the hub, allowing the hub to maintain data concurrency for the entire network. It's referred to as a hub-and-spoke architecture.

Broker Advantages

• Direct Communication - creates a direct information pipeline between the event generator and the interested parties. Communications involve only the sender, broker, and the designated receivers. As a state change occurs, those parties can almost immediately know that it happened.

• Complex functions - can be achieved with chained Event Brokers. For example, by using a log-based Event Broker, events can be "replayed" as part of a historical log.

  
  

Broker Disadvantages

• No Single Source of Truth - Because the logic is part of the broker, the endpoints do not have a way to resolve conflicting events.
• Scaling - Does not scale well for complex functions.
• Reliability - The broker can become a single point of failure for the network because it's responsible for all concurrency between the application's data sets and states, all messages between applicants must pass through it. Under heavy load, the broker can become a bottleneck for messages. A single central destination for all messages also makes it difficult to use the broker model successfully across large geographical distances.

Message Bus Architecture

Bus architecture represents an evolution of the broker hub-and-spoke model. It uses a defined set of standards to govern the flow of data between applications and implies a common protocol spoken and understood by all participants.

A Message Bus architecture is where the endpoints contain the logic instead of the Broker (or Bus in this case). The Apps use a shared (common) set of interfaces and are responsible for preparing the message, so it complies with the type of messages the rest of the apps connected to the bus expect.

Enterprise Service Bus

The term Enterprise Service Bus (ESB) refers to a communication bus between different applications. Each application is enabled to talk to the bus, which in turn allows the sharing of data and communications between the connected applications.

Bus Advantages

• Allows more ubiquitous access to events and data.
• Producers and consumers don’t need to have knowledge of one another.
• New services can start consuming messages immediately without producer changes.
• Service discovery is easily achieved by sending messages to the right topics.

Thanks & Happy Reading!