孔乙己第一问之服务通信知多少？

孔乙己说，茴香豆的茴字有四种写法，你知道服务之间的通信方式有多少种吗？

来我们简单总结总结。（图片来自网络）

 

目录

前言：

1 IPC：

2 基于底层SOCKET的原始方案

3 RPC方式

4 RESTfull方式

5 消息队列

6 数据库

7 MQTT

8 WebSocket

9 其他。

---

前言：

这几年微服务较为流行。采用分而治之的思想，将一个大系统拆解为多个微小服务，可以降低实现复杂度。但是信息本身所包含的熵并不会因此减少，用白话说就是，服务本身并不是孤立的，服务之间需要交互，以便获取彼此需要的信息。因为一个服务不可能包含其所需的所有信息数据，否则，拆解还有何意义呢？

不单是服务之间，设备之间、进程之间、线程之间都可能存在交互的需求。下面整理几种服务实体（所有的这种交互实体，都可以归类到如下两种情况：设备内进程或者设备间进程。对于线程，因为比较简单，不再讨论）之间通信的方法。

1 IPC：

操作系统自带的进程间通信方法。主要适用于设备内进程间。常见的有共享内存、管道、文件等。

2 基于底层SOCKET的原始方案

具体来讲，有两种，基于unix domain socket的方案和普通socket方案。Unix domain socket只适用于本机，在内核中是通过消息队列直接转发消息的，效率较高。普通socket方案则可以用于本机进程间和设备进程间。

普通socket这种方案，操作系统原生支持，跨平台，但是灵活性、适应性、扩展性差，需要自己构建上层数据包处理，存在调试时间长，难以复用，风险大等问题，比较适用于简单的交互。

基于原始socket的通信一般采用私有协议方式较多。

3 RPC方式

RPC方式一般为同步过程，多为平台或语言相关，不过目前的一些开源组件支持跨平台，比如thrift，也是比较成熟的方案。数据组织方式支持多种格式，包括XML、JSON、二进制（PROTOBUF）一般都是支持的。RPC方式一般比较适用于进程间或者局域网内主机之间的通信，同步过程体验相对好一些，因此多用于接口函数式调用模式。因为服务端和客户端存在STUB，实现相对复杂一些，业务模型也倾向于请求响应方式。如果双向调用，服务交互双方都需要同步采用相同框架，这是局限所在。

4 RESTfull方式

服务间基于HTTP的以资源为中心的通信方式，不受上述平台、语言的限制，但效率稍低。另外，存在反复建立断开连接问题。上述方式均为同步或基本按同步方式通信，在信息多、数据量大、高并发场景下，不适合，容易成为系统的瓶颈。此时，需要采用异步通信方案来破这个结

5 消息队列

典型的异步通信方案是采用消息队列方式，可以有效的起到削峰填谷的作用。但是系统的设计实现相对复杂，需要仔细处理。好在消息队列的实现有许多成熟的框架可用，一般系统中，精力放在异步消息设计上即可。

消息队列支持常见的请求响应和发布订阅等交互模型。

我们常说的消息队列。多指应用于互联网头部企业的基础组件（kafka、RocketMQ等），多用于大数据场景中。除此，还有其他许多通信方式，应用于不同场景，但是本质上可以归类为上面某一种。

6 数据库

数据库方式，本质上也是属于消息队列。只不过此时存储在数据库中的不再是普通数据，而是消息。比如，常用于做缓存的redis，也经常被很多大公司用来设计消息队列。

国内的涛思数据，也是数据库的这种方式。

7 MQTT

专门为物联网设备、小型设备、移动设备设计的，适用于窄带宽，低功耗场景的轻量级协议。内容为二进制格式，基于订阅发布模型。底层多基于TCP协议。该协议协助构建一个消息队列模型，有异常情况处理机制，且为ISO/IEC PRF 20922标准协议，支持跨平台。因为是标准协议，所以长远看比较有利。缺点是需要实现协议栈，服务端组件有一些复杂度，需要移植测试。另外，开源产品（mosquitto），需要自己维护，解决测试中的问题。下图是该协议的基本流程（图片来自网络）：

 

8 WebSocket

本质上是基于TCP的通信。服务端可以主动推送消息到客户端，适合双向业务场景。

9 其他。

欢迎补充。