孔乙己说,茴香豆的茴字有四种写法,你知道服务之间的通信方式有多少种吗?
来我们简单总结总结。(图片来自网络)
目录
前言:
这几年微服务较为流行。采用分而治之的思想,将一个大系统拆解为多个微小服务,可以降低实现复杂度。但是信息本身所包含的熵并不会因此减少,用白话说就是,服务本身并不是孤立的,服务之间需要交互,以便获取彼此需要的信息。因为一个服务不可能包含其所需的所有信息数据,否则,拆解还有何意义呢?
不单是服务之间,设备之间、进程之间、线程之间都可能存在交互的需求。下面整理几种服务实体(所有的这种交互实体,都可以归类到如下两种情况:设备内进程或者设备间进程。对于线程,因为比较简单,不再讨论)之间通信的方法。
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 其他。
欢迎补充。