不同系统应用间的通信方式

1.基本概念

既然涉及到通信方式,我们不得不提到如下几个概念:同步、异步、单工、半双工、全双工、UDP、TCP、HTTP。
同步和异步:
同步:提交请求->等待服务器处理->处理完毕返回
异步: 请求通过事件触发->服务器处理(这是浏览器仍然可以作其他事情)->处理完毕
also:
同步是指:发送方发出数据后,等接收方发回响应以后,才发下一个数据包的通讯方式。
异步是指:发送方发出数据后,不等接收方发回响应,接着发送下个数据包的通讯方式。

单工,全双工和半双工:
单工:是指消息只能单方向传输的工作方式
半双工:是指数据可以沿两个方向传送,但同一时刻一个信道只允许单方向传送,因此又被称为双向交替通信
全双工:是指在通信的任意时刻,线路上可以同时存在A到B和B到A的双向信号传输。

UDP、TCP、HTTP:
TCP:面向连接、流模式、保证数据有序、可靠性高、传输慢,占用资源多,传输层协议
UDP:无连接、数据报模式、数据无序、不可靠、但传输快,占用资源少,传输层协议
HTTP:基于TCP,无连接(实际上是短连接),无状态,应用层协议

上面说到了这么多,下面我们就分析一下构建在这些基本概念之上的一些技术协议和通信框架。

2. 传统MVC

这个实际上和上面的没有关系,这里只是为了说明不同系统间通信的必要性。
传统MVC方式是将前后端的所有程序都在服务端完成,由服务端生成数据并渲染成View返回给用户。此时的系统完全是一个孤立的系统,并没有和其他系统进行交互。
那我们考虑如下一个场景,后端业务系统A不光是web系统需要,Android,IOS或者一些其他的业务系统也要用到这些业务怎么办?
当然不可能再开发新的框架使其重复实现A,而是应该将A设计成一个公共核心服务,暴露api给其他系统进行调用,所以后面的技术——(发布使用远程服务(api))就相当有用了。

3.RPC

RPC又叫做远程过程调用,是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。所以这个协议实际上是跨越了应用层和传输层。要让网络通信细节对使用者透明,我们自然需要对通信细节进行封装,我们先看下一个RPC调用的流程:

  1. 服务消费方(client)调用以本地调用方式调用服务;
  2. client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;
  3. client stub找到服务地址,并将消息发送到服务端;
  4. server stub收到消息后进行解码;
  5. server stub根据解码结果调用本地的服务;
  6. 本地服务执行并将结果返回给server stub;
  7. server stub将返回结果打包成消息并发送至消费方;
  8. client stub接收到消息,并进行解码;
  9. 服务消费方得到最终结果。
    RPC的目标就是要2~8这些步骤都封装起来,让用户对这些细节透明。
    通过上面的方式,我们可以知道实际上RPC就是将本地数据序列化成为可以进行网络通信的消息实体(比如Json、XML等),并负责网络通信的具体实现(比如实现Socket(TCP),包括NIO和BIO两种IO模型,一般使用现有的通信IO框架如netty(基于NIO)),虽然网络通信可以通过各种方式实现,比如HTTP、TCP、WebSocket等等,但一般来说,RPC的网络通信都是基于TCP连接的。

4.Restful

REST即表述性状态传递(Representational State Transfer,简称REST),是一种软件架构风格。所以这个算是构建在应用层上的协议(或者说风格)。Rest和RPC是完全不同的两种概念,Rest是面向资源的,基于通用的Http协议;而RPC是面向服务的,基于TCP协议。相当于Rest和RPC只是应用程序间通信的两种方式而已。
而且从上面我们可以看出Rest可能更通用一点,适合暴露给外部调用访问;而RPC直接基于TCP可能更快一点,适合内部调用访问。
Restful特点:

  1. 网络上的所有事物都被抽象为资源

  2. 每个资源都有一个唯一的资源标识符

  3. 同一个资源具有多种表现形式(xml,json等)

  4. 对资源的各种操作不会改变资源标识符

  5. 所有的操作都是无状态的
    不同系统应用间的通信方式_第1张图片

5.WebSocket

在某种程度上来说,WebSocket和RPC、Rest不在一个比较层面,因为RPC和Rest并不是通信协议,WebSocket实际上是一种在单个TCP连接上进行全双工通信的协议,他应该是和HTTP作比较。

  1. HTTP是基于TCP的,但HTTP是无连接、无状态的。
  2. 为了弥补HTTP无法实现长连接即时通信的不足,才有了WebSocket
  3. WebSocket依赖于HTTP连接(在获得HTTP连接的时候,如果服务端和客户端实现了WebSocket协议,将会自动将HTTP升级为WebSocket协议)

但是由于很多时候,无论是RPC亦或是Rest,他们采用的通信方式都是半双工通信方式,比如说Rest所基于的HTTP就是这种,而且大多数RPC在基于TCP实现通信方式的时候也是半双工。又比如现今大多数消息中间件kafka、RocketMQ等,他们默认的通信方式都是采用:NIO+半双工+TCP 方式。
虽然大部分情况下,他们是满足系统要求的,但是如果系统某些功能要求高频率和低延迟即时交换事件,比如在金融,游戏,合作等方面的应用,这种应用对时间延迟非常敏感,并且还需要以高频率交换各种各样的消息,服务器上数据有任何变动,会实时推送到终端,便于高频操作。这时半双工通信方式已无法满足系统的要求,于是WebSocket就派上用场了。

6.总结

上面仔细说了这些概念之间的区别,这里有篇博文写得比较详细:https://blog.csdn.net/u011474078/article/details/81427579
另外,上面谈到的都是未区分同步还是异步,实际上面几种同步自然是实现最简单的,默认也是这种方式。但是很多情况下,尤其是现今面临海量数据和超高并发,异步才是我们需要考虑的。当然他们都可以通过编写服务端代码实现异步操作(比如任务完成后如何回调响应、如何分配任务,如何设计负载均衡策略等),但无疑这种方式会给服务端带来极大的编程困难,而且加重了服务端的耦合程度。
实际上,现在对于异步操作,更推崇的是MQ(消息队列)这种中间件,现今有很多成熟的MQ中间件可以使用,比如Kafka、RabbitMQ、RocketMQ等。主要是这种方式简化了服务端的编程困难,降低了系统的耦合程度。比如上面说的任务分配、回调响应、负载均衡等都可以通过MQ实现,从而降低了服务端和客户端的耦合程度以及代码编写困难。

你可能感兴趣的:(系统通信和MQ)