Proper choice of the communication protocol over Microservices makes the application more responsive and efficient. Various aspects need to be considered regarding communication before breaking down into services. There are 2.5 quintillion bytes of data generated every day. Software built using monolithic architecture may face problems like difficulties in scaling, longer time to ship, spaghetti code, etc. Microservice architecture has become the de facto choice for modern application development. As the name suggests, Microservice architecture is an approach to building a server application as a set of small services. With the wide adoption of trending architecture, there are lots of challenges to deal with small service as it doesn’t suggest common standards and patterns. The implementation depends on team maturity and business requirements. Architecture becomes more mature and independent as the team faces the problems over time. As the services get deployed independently, it requires an efficient protocol to communicate between the services. Improper use of the communication protocol may lead to poor performance in applications. Communication Protocol There are two styles of communication: synchronous and asynchronous. These are the foundations for the request-response and the event-driven patterns. Synchronous Protocol The client requests service and waits for the response. The synchronous protocol is blocking, i-e CPU waits for the response. HTTP is a type of synchronous communication. Modern web applications follow the RESTful architectural style to build APIs for inter-process communication. REST treats every object or entity as a service resource that is accessed by using the HTTP verbs. Generally, the data are exchanged between services in the JSON format. HTTP verbs are used to manipulate the resources in the server. A post request creates the new resource and a put request updates a resource. While accessing resources from the microservices, it assumes to get a response in a short period. A client that requires the real-time update on the user interface uses the synchronous protocol. The application developer uses the interface definition language to build services. There are few options such as Swagger, RAML which are widely used. Asynchronous Protocol Synchronous communication between the microservices lags in performance. Microservices may form a chain of requests between services to respond to a single client. Asynchronous communication is recommended over the synchronous to be a resilient microservices. The asynchronous protocol is non-blocking in nature. If services form the chain of request over microservices it increases the communication overhead which leads to poor performance. It follows the event-driven architecture, there may be one to one and one to many mapping between event producer and consumer. Single Receiver Each request has one sender and one receiver. In the case of multiple requests, they get queued because of the single receiver which can consume one at a time. Multiple Receiver Each request can be processed by zero to multiple receivers. This is based upon the event-bus interface or message broker while exchanging data between the microservices through events. Publish-subscriber Pattern When any events occur in the services it may need to communicate with other services to complete the job. Publisher and subscriber model is an asynchronous pattern which reduces the coupling in the distributed system. Publisher The publisher doesn’t need the subscriber to be up and available. It sends a message to the message queue. Nor does the publisher need to know about the subscriber application that needs to receive the message. Once the message is published in the specific topic the message gets broadcast in the channel to notify the subscribers. Subscribers consume the message in the queue. Subscriber The subscriber subscribes to a particular topic to get notified once the message is published in the respective topic. There may be many subscribers as client request grows. Input Channel Channel used by the publisher to send message to the subscriber. Output Channel Channel used by the subscriber to consume the message. Message Broker Message from the publisher is copied from the input channel to the output channel of interested subscribers, this mechanism is handled by the message broker. All these events occur asynchronously. There are many message broker and third-party services to facilitate the publish/subscribe protocol. Among them, , , , , , are used widely. RabbitMQ Amazon SQS Redis Apache Kafka Amazon SQS Google Cloud Pub/Sub Choosing Message Broker Choosing a message broker as per business requirements is the crucial portion of service communication. There are various parameters for choosing the right message broker. Broker Scale: The number of messages sent per second in the system Data Persistency: The ability to recover messages Consumer capability: The broker capability to deal with one to one and one to many Comparisons Between Message Broker RabbitMQ It provides the flexibility to send messages up-to 50k per second. Message brokers can be configurable to both transient and persistent. The subscriber can be both one or many as per need. It follows the Advanced message queuing protocols. RabbitMQ is best suited for complex routing. General programming languages are supported. Kafka Kafka is an open-source stream-processing software platform developed by LinkedIn. It has high-throughput, low latency for handling real-time data feeds. It provides the data persistency as well and supports one to many subscribers only. It is best to fit to play with large amounts of data. Redis Redis is an in-memory data structure project implementing a distributed, in-memory key-value database with optional durability. It can send up to a million messages per second. It is best suited for the use case of short message retention and where persistence doesn’t matter. It supports one to many subscribers and provides extremely fast service. Design Pattern Based upon Communication ORCHESTRATION In orchestration, there is a single orchestrator that acts as a coordinator to send responses for clients. Orchestrator synchronously manages all services to serve clients. In this pattern, services are tightly coupled to each other. Once the coordinator goes down there will be a single point of failure. As all services communicate synchronously, the time to send response grows as the interaction between services increases. CHOREOGRAPHY Central orchestrator creates the dependencies within the microservices. In microservice, each service should be able to stand on its own. Choreography solves some of the problems of orchestrators. It enables faster processing as it can execute parallel/asynchronously. Services can be plugged as the user grows because the publisher doesn’t have to be aware of the subscriber. Direct client to microservice communication approaches each microservice has a public endpoint. The client directly consumes the endpoint of services in the production environment. Most of the time these services have communication by means of Advanced messaging queue, gRPC,unlike HTTP protocol. Clients may not be able to have communication with services in that scenario. Clients also get coupled tightly with the services. Clients have to make too many requests to render a single user interface as all the services are broken into small manageable pieces. Clients will not be able to handle the cross-cutting concerns such as authorization, data transformations, and dynamic request dispatching. API Gateway API gateway is a hybrid approach to both orchestrator and choreography. While designing the large or complex microservice-based application having multiple client apps like Android, iOS, and Single Page Applications, etc, API Gateway is a better approach to deal with. It is similar to the Facade pattern from object-oriented design. It provides the abstraction of the internal communication of microservices as it is tailored to each client. It might have other responsibilities such as authentication, monitoring, load balancing, caching, request shaping, and static response handling. It provides a single entry point for a group of services. As it is the single entry point for every client app there will be a single point of failure. To deal with that problem API gateway can be segregated to handle clients as per business requirements. It also has many drawbacks like a possible single point of failure, tightly coupling between internal microservice. API gateway may become a bottleneck if it has not configured for scaling. Conclusion The synchronous communication protocol may form a chain of requests while sending a response to the client, which may lead to bad user experience and a single point of failure. Asynchronous communication is preferred over the synchronous which will be more responsive and fault-tolerant. While building applications, proper architecture plays an important role to make applications more robust, fault-tolerant, and scalable. Each architecture has its pros and cons. If the microservices have to serve multiple clients then API Gateway pattern can be best matched but to ome extent only. Proper architecture decisions as per business requirements and best communication protocol between the microservices may lead to better performance, scalability, and fault-tolerant projects. References https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern https://medium.com/capital-one-tech/microservices-when-to-react-vs-orchestrate-c6b18308a14c https://medium.com/capital-one-tech/microservices-when-to-react-vs-orchestrate-c6b18308a14c https://dzone.com/articles/patterns-for-microservices-sync-vs-async https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-microservice-architecture https://dzone.com/articles/design-patterns-for-microservice-communication https://martinfowler.com/articles/microservices.html http://www.rajeshbhojwani.co.in/2018/11/design-patterns-for-microservices.html https://dzone.com/articles/building-microservices-inter-process-communication-2 https://otonomo.io/blog/redis-kafka-or-rabbitmq-which-microservices-message-broker-to-choose/ https://www.youtube.com/watch?v=4KQoYVX9lNM https://www.youtube.com/watch?v=rXi5CLjIQ9k Previously published at h ttps://medium.com/@rajesh_khadka/communication-over-micro-services-49a8b1586969

Chain

Amazon

Apache

Google

Communication Over Microservices

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Common Design Patterns for Building Resilient Systems (Retries & Circuit Breakers)

Microservices Communication with the use of Apache Kafka

Microservices vs. Monolithic Architecture

The Cacophonies of Distributed Systems

The Twelve-Factor App: 12 Best Practices For Microservices

104 Stories To Learn About Go

Common Design Patterns for Building Resilient Systems (Retries & Circuit Breakers)

Microservices Communication with the use of Apache Kafka

Microservices vs. Monolithic Architecture

The Cacophonies of Distributed Systems

The Twelve-Factor App: 12 Best Practices For Microservices

104 Stories To Learn About Go

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps