Kongyiji's first question: how much do you know about service communication?

Kong Yiji said , There are four ways to write the word fennel in fennel beans , Do you know how many ways of communication between services ？

Let's make a brief summary .（ Picture from the Internet ）

 

Catalog

Preface ：

1 IPC：

2 Based on the underlying SOCKET The original plan of

3 RPC The way

4 RESTfull The way

5 Message queue

6 database

7 MQTT

8 WebSocket

9 other .

---

Preface ：

In recent years, microservices have become more popular . Adopt the idea of divide and rule , Disassemble a large system into multiple micro Services , It can reduce the implementation complexity . But the entropy contained in the information itself will not be reduced , In plain English , The service itself is not isolated , Services need to interact with each other , In order to get the information that each other needs . Because a service cannot contain all the information and data it needs , otherwise , What's the point of dismantling ？

Not just between services , Between devices 、 Between processes 、 There may be the need for interaction between threads . Here are several service entities （ All such interactive entities , Can be classified into the following two cases ： Intra device processes or inter device processes . For threads , Because it's easier , No more discussion ） The method of communication between .

1 IPC：

Interprocess communication method of operating system . It is mainly applicable to processes in the equipment . Common ones are shared memory 、 The Conduit 、 Documents, etc. .

2 Based on the underlying SOCKET The original plan of

In particular , There are two kinds of , be based on unix domain socket The scheme and common socket programme .Unix domain socket Only for this machine , In the kernel, messages are forwarded directly through message queues , More efficient . Ordinary socket The scheme can be used between local processes and device processes .

Ordinary socket This program , OS native support , Cross platform , But flexibility 、 adaptive 、 Expandability of , You need to build your own upper layer packet processing , Long debugging time exists , Difficult to reuse , Big risks and so on , It is suitable for simple interaction .

Based on the original socket Generally, private protocols are used for communication .

3 RPC The way

RPC The mode is generally synchronous process , Most of them are platform or language related , However, some current open source components support cross platform , such as thrift, It's also a relatively mature scheme . Data organization supports multiple formats , Include XML、JSON、 Binary system （PROTOBUF） It's generally supportive .RPC This method is generally applicable to the communication between processes or hosts in the LAN , The experience of synchronization process is better , Therefore, it is mostly used in interface functional call mode . Because the server and client exist STUB, The implementation is relatively complex , Business models also tend to respond to requests . If two-way call , Both sides of service interaction need to adopt the same framework synchronously , This is the limitation .

4 RESTfull The way

The service room is based on HTTP A resource centric way of communication , Not affected by the above platforms 、 The limitation of language , But less efficient . in addition , There is a problem of repeatedly establishing and disconnecting connections . The above methods are synchronous or basically synchronous communication , More information 、 Large amount of data 、 High concurrency scenarios , Not suitable for , It is easy to become the bottleneck of the system . here , Asynchronous communication scheme is needed to break this knot

5 Message queue

A typical asynchronous communication scheme uses message queue , It can effectively cut the peak and fill the valley . But the design and implementation of the system is relatively complex , Need to be handled carefully . Fortunately, there are many mature frameworks available for the implementation of message queue , In general systems , Focus on asynchronous message design .

Message queuing supports common interaction models such as request response and publish subscribe .

We often talk about message queues . It refers to the basic components applied to Internet head enterprises （kafka、RocketMQ etc. ）, It is mostly used in big data scenarios . In addition to this , There are many other ways of communication , Apply to different scenarios , But in essence, it can be classified as one of the above .

6 database

Database mode , In essence, it belongs to message queue . But at this time, what is stored in the database is no longer ordinary data , It's news . such as , Commonly used for caching redis, It is also often used by many large companies to design message queues .

Domestic Taosi data , This is also the way of database .

7 MQTT

Specifically for IOT devices 、 Small equipment 、 Mobile device design , Suitable for narrow bandwidth , Lightweight protocol for low power scenarios . The content is in binary format , Based on subscription publishing model . The bottom layer is mostly based on TCP agreement . This protocol helps build a message queue model , There is an exception handling mechanism , And for ISO/IEC PRF 20922 Standard agreement , Cross-platform support . Because it's a standard agreement , So in the long run, it's more beneficial . The disadvantage is that you need to implement the protocol stack , The server-side components have some complexity , Migration test is required . in addition , Open source products （mosquitto）, Need to maintain , Solve problems in testing . The following figure shows the basic flow of the protocol （ Picture from the Internet ）：

 

8 WebSocket

It's essentially based on TCP Communication for . The server can actively push messages to the client , It is suitable for two-way business scenarios .

9 other .

Welcome to add .