Different Protocols for Microservice Communication
Understanding the different protocols available in microservices.
Modern-day applications often require zero downtimes during releases, and faster time to releases while maintaining very complex requirements.
Not only that, but most organizations don’t rely on one technological stack to develop their apps.
Therefore, many organizations tend to adopt microservice-based architectures to fulfil these requirements quickly, and reliably.
Since a microservice is a small single application on its own, it’s able to be developed and maintained in its own programming language as well.
Though this seems great, this further distributes your application architecture, and one big drawback of achieving such distribution is maintaining efficient and effective communication across these services.
Hence, this article will provide an in-depth understanding of the different techniques by which microservices can communicate in such distributed environments.
1. Synchronous and Asynchronous communication
Firstly, it’s important to understand that microservices can communicate using two main techniques:
- Synchronous communication
- Asynchronous communication
Synchronous Communication
Calls in synchronous communication establish a network of dependencies that extends to all downstream services.
For instance, a service that synchronously calls a shopping cart can also rely on related payment and warehousing services. It’s doubtful that the caller will receive a response if one or more of these downstream services are offline.
Even if a response is given, it can take too long for the user to continue, and the session will stop.
In the above diagram, the Caller service initiates a synchronous call to the Shopping Cart service. The Shopping Cart service, in turn, synchronously calls the Payment Service and the Warehousing Service to fulfil the request.
However, if one or more of the downstream services are offline, the caller may not receive a response. Even if a response is eventually returned, it may take too long for the user to continue, leading to a stalled session.
Asynchronous Communication
Asynchronous communication is a solution to this issue. The asynchronous technique manages each communication separately rather than creating a continuous chain of dependencies.
As a result, each microservice can respond to calls immediately without waiting for a response from the downstream services.
When the shopping cart receives a call from the service request, it may signal immediately that it has been updated and is ready for the consumer to view.
The shopping cart might contact downstream services like payment and warehousing. When the customer clicks through to complete the transaction, these responses may be saved and available for use.
Given these scenarios, an asynchronous technique could always be preferable.
However, that isn’t always the case.
For instance, real-time query calls could require synchronization, particularly if the returned answer changes how the calling services operate. The majority of query calls can still be made asynchronously.
For the communication of microservices, REST is a popular and frequently used protocol. Building scalable and effective microservices is possible thanks to their stateless simplicity and broad support.
Let’s discuss the use of REST Protocol in microservice communication.
REST Protocol
REST is a set of architectural principles describing how clients and servers can talk.
It stresses that the client is in charge of the flow of data and should have access to all the available resources without any issues. The key concept here is stateless communication.
Whenever a client needs something from another service, it sends a request to that service, and an entirely new session is created. The stateful server stores any changes made throughout this session.
With REST, you’re able to create a network of independent services. You can use various technologies and implement even more on top of existing ones. Your applications will be easier to scale and maintain since they have fewer dependencies.
HTTP Protocol is another key protocol in microservice communication. Its simple request-response model and caching support make it a good choice for building scalable and performant microservices. We will discuss more on the HTTP Protocol.
HTTP Protocol
HTTP is a widely utilized inter-microservice communication protocol most frequently used for synchronous communication.
All microservices can interact directly, thanks to its broker-less methodology. Although HTTP makes communication simple, it can easily lead to unintended dependence.
Therefore, only HTTP is recommended as the main protocol between a user interface and the highest level of services. Asynchronous approaches are recommended in addition to this.
However, adding REST to HTTP can provide asynchronous request/response communication.
Furthermore, there is a lot of uniformity between HTTP and REST. So if you must use HTTP, think about using it. The combined treatments’ speedier response times are their main advantage.
The use of a framework like Spring Boot, which offers a collection of tools for quickly constructing and deploying web services, is one of the popular ways to implement HTTP-based microservices.
Additionally, Spring Boot has built-in support for JSON and XML serialization, making it simple to transfer data across services.
Following are some of the disadvantages and limitations of HTTP protocol when it comes to microservice communication:
- For corporate users, latency is becoming more and more important. Therefore, loading rich media information more quickly is impossible using the current protocol.
- Due to excessive data transfer caused by headers, resource usage is suboptimal because connections are created for each request-response pair.
When synchronous communication and a straightforward request-response model are required, HTTP is a better fit.
But you need to have a method when asynchronous communication and message queues are needed. For that, we can use the Advance Message Queuing Protocol (AMQP).
AMQP — Advance Message Queuing Protocol
Let’s imagine you want to use asynchronous protocols. You can always consider the Advanced message queuing protocol (AMQP).
This widely used and mature protocol should be a top priority for those creating composite microservices apps. It offers a standardized approach to microservices communication.
Asynchronous protocols always use lightweight service similar to service-oriented architecture (SOA) since it is less complex. AMQP also behaves like that.
Instead of using a broker-less technique like HTTP, it offers a message broker that works as a middleman between the various microservices.
However, remember that a message broker will add extra stages that could raise latency.
Furthermore, each service still has its own functional and operational logic, which will take some time to process. The bus only assists in standardizing and capping such interactions.
The support for message queues provided by AMQP in microservice communication is one of its key advantages. Services can manage high-throughput circumstances and enable asynchronous communication by using queues to store messages that are not immediately consumed by subscribers.
In addition, AMQP features message persistence, which enables messages to be saved on disk and survive failures of the broker or service.
Major cloud platforms, such as Azure, offer their proprietary service bus for message brokering.
But there are also choices provided by outside parties, such as the open-source message broker RabbitMQ, written in the Erlang computer language.
As we discussed above, AMQP is well-suited for asynchronous communication and message queues are needed.
But if there is a need for a publish-subscribe messaging pattern in our microservice, you need to have another protocol to keep the communication.
For that purpose, message receiver protocols have been implemented. Let’s discuss more on that.
Single Receiver and Multiple Receivers
There are two major ways of responding to services connected and how to react to them.
- Single receiver model
- Multiple receiver model
A direct, one-to-one answer is made possible in a single-receiver paradigm by the calling service’s creation of a message-based request that interacts with a single responding service.
However, this improves response times and does not offer any protection from cascading failure. As a result, the asking microservice may receive numerous replies to its call without recognizing a failure. For example, if the responding microservice is built to self-recover and retry following a failure.
As an alternative, the publish-and-subscribe strategy is the foundation of the multiple-receiver paradigm. Any other services that might respond are contacted by the service making the request. These messages are handled in a first-come, first-served queue, and when the response is prepared, it is sent to the caller service.
As a result, services are much more readily available, response times are improved, and there are more options for boosting resources as needed. A new service instance, for instance, could be launched and added to the environment as a whole, causing the upstream services to connect on their own.
Developers of back-end systems should investigate asynchronous, message-brokered strategies that offer uniform communication. To improve the user experience, synchronous communication between a straightforward front- and back-end is acceptable. However, asynchronous communication performs best in complex procedures.
💡 Note: By using an open-source toolchain like Bit, you can further ensure reliability in a microservice architecture by making sure your components are made independent, then versioned, tested, and shared across different microservices, with automatic semver and a dependency graph for each. This reduces the risk of failures caused by inconsistent dependencies or code duplication. Find out more here, here and here.
Conclusion
Well-defined APIs are encouraged to be used for interoperability in a microservices architecture.
Depending on the preferences of the development teams and the technological stacks, these well-defined APIs can be offered across various protocols. JMS, WebSockets, and HTTP are a few examples.
Typically, most frameworks support HTTP as the primary communication protocol for developing microservices. The generally used protocol for communication between microservices is REST over HTTP.
From monolithic to composable software with Bit
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
