Question:
Microservices is a type of architectural pattern where an application is divided into smaller independent applications that communicate to do the complete work of the system.
The common form of communication that is often referred to is using HTTP.
However, HTTP does not seem suitable 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, in addition to being more prone to errors introduced by the complexity of a low-level approach.
Anyway, are there other methods, techniques, protocols or mature technologies that solve these problems, using or not HTTP? (Preferably technologies that have been used successfully for this purpose)
Answer:
You will necessarily have to take the data from one place to another, and all these means involve, in one way or another, the use of sockets.
The strategies you can use are highly case-specific. Among the techniques you can use (and you can combine several of them), we have:
- Standard HTTP usage (POST, GET, PUT, DELETE and PATCH).
- WebDAV .
- FTP .
- POST via HTTP with multipart , for uploads.
- Ajax
- Comet (also called reverse AJAX) for server-side pushes .
- Websockets to allow 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 them one at a time.
- Multicast .
- Anycast .
- Customized TCP sockets – The most standard way of sending information, with delivery order guarantee, retransmission of packets that are not received or that have been damaged, and flow and congestion control automatically managed by the operating system.
- Custom UDP sockets, where packets are sent and if not corrupted are accepted. There is no worry about packet loss, delay, duplication or congestion, which is entirely up to the developer. Ideal for real-time data sending, where old packets are no longer needed (and therefore should not be retransmitted) and the loss of some packets is not critical.
- SCTP sockets, which is similar to UDP, but already has congestion control, retransmission guarantee, and packet sequencing just like TCP.
- UDP-Lite sockets, similar to UDP, but does not discard damaged packets in some cases (and therefore also accepts packets that contain truncated information, for example).
- DCCP sockets, similar to TCP, but with no guarantee of packet ordering.
- [etc.]
Anyway, all of these are "mature" alternatives, but some are more labor intensive than others. Some adapt to microservices better than others. Some are more generic while others are more specific to certain niches and certain issues. The more specialized your service, the more handwork you will have to do. I don't know what you want to do, but you need to assess your case against the following criteria:
- Should messages between systems be delivered in real time? Or should you save them and deliver them when the time comes?
- Is it preferable to send few large messages or many small messages?
- If a message is received damaged or partially, should I try to use it anyway?
- What is the impact of a lost data packet? Should it be relayed, or should the ball go forward, go on and leave the past in the past?
- What is the impact of data packets arriving out of order? Should they only be used when correctly ordered or can they be used even if they are out of order?
- What is the impact of a data packet that is late in arriving? Should you stop everything until the packet is received, should you ignore incoming packets that are considered old, or should you go ahead and correct the past when the packet arrives?
- If the recipient of the message cannot be reached, what happens? Should you insist on polling until he comes back? Should I store the message until it comes back? When he comes back should he ask for the message? Or if it's not reachable, just forget about it and let it go?
- Is communication between a server and a web browser? Between a server and a client application? Or between one server and another server?
- Does information flow one way or does it flow both ways? If it flows both ways, is it only one way at a time, or can it go both ways 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 can any recipient within a given group receive it?
Anyway, as you can see, there are many particulars to be considered, and for that reason, there is no way to give a one-size-fits-all answer. Each case is different. The first thing I would look at is whether simple HTTP would do the trick. If not, Ajax and websockets are worth a look. If that doesn't work either, then the problem at hand should be studied in detail to find the most suitable solution.