Inter process communication
0 likes78 views
Microservices require inter-process communication (IPC) mechanisms to enable interaction between distributed components. Two primary IPC styles exist: asynchronous messaging, allowing non-blocking communication, and synchronous request/response, which involves direct requests and replies. Essential considerations when implementing IPC include interaction patterns, API design, and managing system failures.
Inter process communication
- 2. 1 Table of Contents Introduction...............................................................................................................................2 Interaction Styles.......................................................................................................................3 IPC Technologies........................................................................................................................4 1. Asynchronous, Message-Based Communication..........................................................4 PROS...................................................................................................................................5 CONS ..................................................................................................................................5 2. Synchronous, Request/Response IPC............................................................................5 REST ...................................................................................................................................5 PROS...................................................................................................................................6 CONS ..................................................................................................................................7 Summary....................................................................................................................................7
- 3. 2 Introduction In a monolithic application, components invoke one another via language-level method or function calls. A microservices-based application is a distributed system running on multiple machines. Each service instance is typically a process. Consequently, as the following diagram shows, services must interact using an inter-process communication (IPC) mechanism. Figure 1: Interprocess Communication Monoloth VS Micrososervices1 1 https://twitter.com/nginx
- 4. 3 Interaction Styles When selecting an IPC mechanism for a service, it is useful to think first about how services interact. There are a variety of client⇔service interaction styles. They can be categorized along two dimensions. The first dimension is whether the interaction is one-to-one or one- to-many, the second dimension is whether the interaction is synchronous or asynchronous. One-to-One One-to-Many Synchronous Request/response — Asynchronous Notification Publish/subscribe Request/async response Publish/async responses Table 1 : Interprocess communication styles 2 There are the following kinds of one-to-one interactions: Request/response: A client makes a request to a service and waits for a response. The client expects the response to arrive in a timely fashion. In a thread-based application, the thread that makes the request might even block while waiting. Notification: A client sends a request to a service but no reply is expected or sent. Request/async response: A client sends a request to a service, which replies asynchronously. The client does not block while waiting and is designed with the assumption that the response might not arrive for a while. There are the following kinds of one-to-many interactions: Publish/subscribe: A client publishes a notification message, which is consumed by zero or more interested services. Publish/Async responses: A client publishes a request message and then waits a certain amount of time for responses from interested services. 2 https://dzone.com/articles/building-microservices-inter-process-communication-2
- 5. 4 Figure 2: Interprocess Communication Monoloth VS Micrososervices3 Figure 2 displays TRIP management system in which services use a combination of notifications, request/response, and publish/subscribe. For example, the passenger’s smartphone sends a notification to the Trip Management service to request a pickup. The Trip Management service verifies that the passenger’s account is active by using request/response to invoke the Passenger Service. The Trip Management service then creates the trip and uses publish/subscribe to notify other services including the Dispatcher, which locates an available driver. IPC Technologies There are lots of different IPC technologies to choose from. Services can use synchronous request/response-based communication mechanisms such as HTTP-based REST or Thrift. Alternatively, they can use asynchronous, message-based communication mechanisms such as RABBITMQ 1. Asynchronous, Message-Based Communication When using messaging, processes communicate by asynchronously exchanging messages. A client makes a request to a service by sending it a message. If the service is expected to reply, it does so by sending a separate message back to the client. Since the communication is asynchronous, the client does not block waiting for a reply. Instead, the client is written assuming that the reply will not be received immediately. 3 https://dzone.com/articles/building-microservices-inter-process-communication-2
- 6. 5 Message consists of headers (metadata such as the sender) and a message body. Messages are exchanged over channels. Any number of producers can send messages to a channel. Similarly, any number of consumers can receive messages from a channel. There are two kinds of channels, point-to-point (ONE TO ONE) and publish-subscribe(ONE TO MANY). PROS Decouples the client from the service Message buffering Flexible client-service interactions CONS Additional operational complexity Complexity of implementing request/response-based interaction 2. Synchronous, Request/Response IPC When using a synchronous, request/response-based IPC mechanism, a client sends a request to a service. The service processes the request and sends back a response. There are numerous protocols to choose from. Two popular protocols are REST and Thrift. REST REST is an IPC mechanism that (almost always) uses HTTP. Roy Fielding, the creator of REST, defines REST as follows: REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems4. Leonard Richardson defines a very useful maturity model for REST that consists of the following levels. Level 0 – Clients of a level 0 API invoke the service by making HTTP POST requests to its sole URL endpoint. Each request specifies the action to perform, the target of the action (e.g. the business object), and any parameters. Level 1 – A level 1 API supports the idea of resources. To perform an action on a resource, a client makes a POST request that specifies the action to perform and any parameters. 4 Microservices Patterns, Chris Richardson
- 7. 6 Level 2 – A level 2 API uses HTTP verbs to perform actions: GET to retrieve, POST to create, and PUT to update. The request query parameters and body, if any, specify the action’s parameters. This enables services to leverage web infrastructure such as caching for GET requests. Level 3 – The design of a level 3 API is based on the terribly named HATEOAS. The basic idea is that the representation of a resource returned by a GET request contains links for performing the allowable actions on that resource. For example, a client can cancel an order using a link in the Order representation returned in response to the GET request sent to retrieve the order. Benefits of HATEOAS include no longer having to hardwire URLs into client code. Another benefit is that because the representation of a resource contains links to the allowable actions, the client doesn’t have to guess what actions can be performed on a resource in its current state. Figure 3: The levels of maturity according to Richardson’s model5 PROS HTTP is simple and familiar. You can test an HTTP API from within a browser using an extension such as Postman or from the command line using curl (assuming JSON or some other text format is used). It directly supports request/response-style communication. HTTP is, of course, firewall-friendly. It doesn’t require an intermediate broker, which simplifies the system’s architecture. 5 https://restfulapi.net/richardson-maturity-model/
- 8. 7 CONS It only directly supports the request/response style of interaction. You can use HTTP for notifications but the server must always send an HTTP response. Because the client and service communicate directly (without an intermediary to buffer messages), they must both be running for the duration of the exchange. The client must know the location (i.e., the URL) of each service instance. As described in the previous article about the API Gateway, this is a non-trivial problem in a modern application. Clients must use a service discovery mechanism to locate service instances. Summary Microservices must communicate using an inter-process communication mechanism. When designing how your services will communicate, you need to consider various issues: how services interact, how to specify the API for each service, how to evolve the APIs, and how to handle partial failure. There are two kinds of IPC mechanisms that microservices can use, asynchronous messaging and synchronous request/response.