How to carry out communication between Microservices (microservices)?

Question

Microservices is a type of architectural pattern where an application is divided into smaller, independent applications that communicate to accomplish the complete work of the system.

The common form of communication that is usually referred to is using HTTP.

However, HTTP does not seem appropriate if the data volume is large or if the communication model requires continuous data exchange in the same communication. On the other hand, the use of sockets seems not to be cost-effective, and is more prone to errors introduced by the complexity of a low-level approach.

Anyway, there are other methods, techniques, protocols or mature technologies that solve these problems, using or not HTTP? (Preferably technologies that have been successfully used for this purpose)

Answer 1

You will have to carry the data from one place to the other, and all these means involve one way or another, the use of sockets.

The strategies you can use depend heavily on each specific case. Among the techniques you can use (and can combine several of them), we have:

• Use of standard HTTP (POST, GET, PUT, DELETE and PATCH).
• Webdav.
• FTP.
• POST via HTTP with Multipart, for uploads.
• Ajax.
• Comet (also called reverse AJAX) to do server-side pushes.
• Websockets to enable more-or-less real-time communication via full-duplex TCP and with broad browser support.
• JMS.
• CORBA.
• Chunking - That is, you cut the data to be sent in pieces and send one at a time.
• Multicast.
• Anycast.
• Customized TCP sockets - The most standard form of sending information, with guaranteed delivery order, retransmission of packets that are not received or that have been damaged and control of flow and congestion automatically managed by the operating system.
• Custom UDP sockets, where packages are sent and if not corrupted are accepted. There is no concern about package losses, delays, duplication or congestion, which are entirely up to the developer. Ideal for sending data in real time, where old packages are no longer needed (and therefore should not be retransmitted) and the loss of some packages is not critical.
• Sockets SCTP, which is similar to UDP, but already has congestion control, relay assurance and package sequencing such as TCP.
• Sockets UDP-Lite, similar to UDP, but does not discard damaged packages in some cases (and therefore also accepts packages containing truncated information, for example).
• Sockets DCCP, similar to TCP, but no package ordering guarantee.
• [etc..]

Anyway, these are all "mature" alternatives, but some are more laborious than others. Some adapt to Microservices better than others. Some are more generic while others are more specific to certain niches and problems. The more specialized your service, the more hand work you will have to do. I don’t know what you want to do, but you need to evaluate your case according to the following criteria:

• Should messages between systems be delivered in real time? Or should they be stored and delivered when appropriate?
• It is preferable to send few large messages or many small messages?
• If a message is received damaged or partially, try to use it anyway?
• What is the impact of a data package that gets lost? It must be relayed, or it must touch the ball forward, go forward and leave the past in the past?
• What is the impact of data packets arriving out of order? They should be used only when correctly ordered or can be used even if they are out of order?
• What is the impact of a data package that is delayed to arrive? You must stop everything until the package is received, you must ignore packages that arrive already considered old, or you must proceed and correct the past when the package arrives?
• If the receiver of the message cannot be reached, what happens? Should we insist on Polling until it returns? Should you store the message until it comes back? When it comes back should it ask for the message? Or if it is not reachable, forget it and let it go?
• Is communication between a server and a web browser? Between a server and a client application? Or between a server and another server?
• Does information flow in one direction or does it flow in both directions? If it flows in both directions, it occurs only in one direction at a time or it can occur in both directions at the same time?
• Will the same information be transmitted only to a specific recipient or will several recipients be able to receive it? Or any recipient within a particular group may receive it?

Anyway, as you can see, there are many particularities to consider, and for that reason, there is no way to give an answer one-size-Fits-all. Each case is a case. The first thing I would look at is whether simple HTTP would solve it. If not, it’s worth looking at Ajax and websockets. If this also does not serve, then the problem in question must be studied in detail to find the most appropriate solution.