interprocess communication (IPC) for microservices architectures

Throw a few questions first:

1. What are the interaction modes of the microservices architecture?
2. What are the commonly used interprocess communication technologies for microservices?
3. How do I handle a partial request failure?
4. What you need to be aware of in the API definition
5. The relationship and difference between the communication mechanism of microservices and the communication mechanism of SOA

is the interaction mode of the MicroServices architecture one-to-many?

1. Single-to-one: each client requests a service instance to respond to
2. One-to-many: Each client request has multiple service instances to respond to

Synchronous or asynchronous?

1. Synchronous mode: Client requests require immediate response from the server and may even be blocked by waiting
2. Asynchronous mode: Client requests do not block processes, and server-side responses can be non-instantaneous

There are several ways to interact with one-to-two modes:

1. Request/Response: A client initiates a request to the server, waits for a response, and the client expects this response to arrive immediately. In a thread-based application, the wait process can cause a thread to block.
2. Notification (that is, a one-way request): A client request is sent to the server but does not expect the server to respond.
3. Request/Asynchronous Response: The client sends the request to the server side, and the server asynchronously responds to the request. The client does not block, and the default response is designed to not arrive immediately.

One-to-many interaction modes are available in the following ways:

1. Publish/Subscribe mode: Client posts notification message, consumed by 0 or more services of interest.
2. Publish/Async Response mode: The client publishes the request message, and then waits for a response from the service that is interested in sending it back.

Inter-process communication technology commonly used in micro-services

1. Rest:rest is the representational state transfer (English: representational, Transfer, or rest) is a software architecture style proposed by Dr. Roy Fielding in his doctoral dissertation in 2000. It is a design and development method for network application, which can reduce the complexity of development and increase the scalability of the system.
2. Thrift:thrift is a software framework for the development of extensible, cross-language services. It combines a powerful software stack and code generation engine to build in C + +, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Cocoa, JavaScript, node. js, Smalltalk, And OCaml a seamless, efficient service between these programming languages

What to look for in the API definition

• The choice of the IPC communication mode: The API definition depends on the IPC communication method chosen, if it is a message mechanism (such as AMQP or STOMP), the API is the message channel and the message type, and if the HTTP mechanism is used, it is based on the request/response (the URL that invokes HTTP).
• API version Upgrades: Service APIs tend to evolve over time. In a single application, the API's consumers are often directly modified. However, in microservices, it is not always possible for all API consumers to keep up with the API updates, and the new version and the older API may run concurrently.
• Choice of message Format: Determining the most appropriate message format for microservices is another key element. Traditional monomer software uses complex binary formats, and Soa/web services applications use text messages based on complex message format (SOAP) and schema (XSD). In most microservices, they use simple text-based message formats, such as Json/xml based on HTTP resource API styles. In some cases when they need a binary format (text messages appear verbose in some scenarios), binary protocols such as binary Thrift, protobuf, and Arvo can be used. (Excerpt from "Micro-service Combat: From architecture to Deployment")

Failed to process partial request

for distributed microservices, one of the major problems that must be faced is the processing of partial request failures.

Netfilix provides a better solution, including (excerpt from "Chris Richardson microservices series"):

• Network timeout: When waiting for a response, do not set an indefinite block, but instead adopt a time-out policy. Use a time-out policy to ensure that resources are not occupied indefinitely.
• Limit the number of requests: You can set an access limit for a client's request to a particular service. If the request is capped, the request service will be terminated immediately.
• Circuit Breaker Mode (Circuitbreakerpattern): Records the number of successful and failed requests. If the loss of efficiency exceeds a threshold, triggering a circuit breaker causes subsequent requests to fail immediately. If a large number of requests fail, it may be that the service is unavailable, and the request is meaningless. After an expiration period, the client can retry and, if successful, close the circuit breaker.
• Provides rollback: Rollback logic can be made when a request fails. For example, a cached data or a system default value is returned.

The relationship and difference between the communication mechanism of microservices and the communication mechanism of SOA

Within a single application, the business functions of different components are implemented through function calls or language-level method calls. In SOA, this translates to a more loosely coupled Web service-level message, primarily soap based on different protocols such as HTTP, JMS, and so on. Webservice contains dozens of operations and complex messaging mechanisms that are an important factor in blocking the popularity of Web services. For microservices architectures, there must be a simple and lightweight message mechanism.

Reference article:

• Micro-service combat: from architecture to deployment

interprocess communication (IPC) for microservices architecture