java进程通信方式

亦凉 2024-04-17 06:22 54阅读 0赞

由于内存管理的一些机制，导致两个进程间并不能直接的进行通信(在独立的用户空间),因此我们需要利用一些介质来完成两个进程之间的通信。以下是常用的进程间通信方式。

> 1.  管道（Pipe）：管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系进程间的通信，允许一个进程和另一个与它有共同祖先的进程之间进行通信。（*半双工：数据传输指数据可以在一个信号载体的两个方向上传输，但是不能同时传输。*）
> 2.  有名管道（named pipe）： 有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。命名管道在文件系统中有对应的文件名。命名管道通过命令 mkfifo 或系统调用 mkfifo 来创建。
> 3.  信号（Signal）：信号是比较复杂的通信方式，用于通知接受进程有某种事件发生。
> 4.  消息（Message）队列：消息队列是消息的链接表。有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。
> 5.  共享内存：使得多个进程可以访问同一块内存空间，是最快的可用IPC形式。是针对其他通信机制运行效率较低而设计的。往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥。
> 6.  内存映射（mapped memory）：内存映射允许任何多个进程间通信，每一个使用该机制的进程通过把一个共享的文件映射到自己的进程地址空间来实现它。
> 7.  信号量（semaphore）：信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
> 8.  套接口（Socket）：更为一般的进程间通信机制，与其他通信机制不同的是，它可用于不同及其间的进程通信。可用于不同机器之间的进程间通信。

继续阅读之前请先区分进程和线程区别！！！，如有任何混杂，请参考：[传送门][Link 1]

可以把java进程理解为jvm进程，至于通讯方式处理Socket以外 我们还可以用 RPC，Webservice，RMI，JMS 等，当然，JAVA进程间通信的最基本手段大都也是Socket。

# RPC #

远程过程调用（Remote Procedure Call，缩写为RPC），是一种用于构建基于C/S（客户端/服务器）的分布式应用程序技术。调用者与被调用者可能在同一台服务器上，也可能在由网络连接的不同服务器上，对于他们来说，网络通信是透明的，就是像调用本地方法一样调用远程方法。

RPC框架要做到的最基本的三件事：

> 1、服务端如何确定客户端要调用的函数？
> 
> 在远程调用中，客户端和服务端分别维护一个【ID->函数】的对应表， ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，附上这个ID，服务端通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
> 
> 2、如何进行序列化和反序列化？
> 
> 客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化，序列化和反序列化的速度也会影响远程调用的效率。
> 
> 3、如何进行网络传输？（选择何种网络协议？）
> 
> 多数RPC框架选择TCP作为传输协议，也有部分选择HTTP。如gRPC使用HTTP2。不同的协议各有利弊。TCP更加高效，而HTTP在实际应用中更加的灵活。

RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

请注意，RPC只是一种编程模型而非一种规范或协议，并没有规定你具体要怎样实现，你甚至都可以在你的RPC框架里面使用RMI来实现数据的传输！！！

成熟RPC框架：

[dubbo][]：阿里开源的一款高性能RPC框架，在国内应用广泛，期间停止维护过一段时间，如今又开始了更新，并且捐献给Apache基金会。

[gRPC][]：Google开源，具有平台无关性，基于http/2协议，支持服务追踪、负载均衡、健康检查等功能；RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。

[Thrift][]：可伸缩的跨语言服务的RPC软件框架，最早由Facebook开发，2007年捐献给了Apache基金会管理，现在是Apache的顶级项目；

[Finagle][]：Twitter基于Netty开发的支持容错的、协议无关的RPC框架，支撑了Twitter的核心服务。

# Web Service #

WebService是一种跨编程语言和跨操作系统平台的远程调用技术。Web Service提供的服务是基于web容器的，底层使用http协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。就是通过一个servlet，提供服务给其他应用请求。

WebService采用HTTP协议传输数据，采用XML格式封装数据（即XML中说明调用远程服务对象的哪个方法，传递的参数是什么，以及服务对象的返回结果是什么）。XML是WebService平台中表示数据的格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。但是XML虽然解决了数据表达问题，却留下了数据格式类型问题，XSD(XML Schema)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。

## Web Service的标准 ##

> 1.  Web Service 通过标准的Web 协议向Web 用户提供有用的功能。多数情况下使用SOAP协议。
> 2.  Web Service 可以非常详细地说明其接口，这使用户能够创建客户端应用程序与它们进行通信。这种说明通常包含在称为Web服务说明语言(WSDL)文档的XML 文档中。
> 3.  Web Service 已经过注册，以便潜在用户能够轻易地找到这些服务，这是通过通用发现、说明和集成(UDDI)来完成的。
> 4.  Web Service 体系结构的主要优点之一是:允许在不同平台上、以不同语言编写的各种程序以基于标准的方式相互通信。
> 5.  我们将Web Service 定义为: 通过SOAP 在Web 上提供的软件服务，使用WSDL 文件进行说明，并通过UDDI 进行注册。

## **SOAP**： ##

WebService通过HTTP协议发送请求和接收结果时，发送的请求内容和结果内容都采用XML格式封装，并增加了一些特定的HTTP消息头，以说明HTTP消息的内容格式，这些特定的HTTP消息头和XML内容格式就是SOAP协议。SOAP提供了标准RPC方法来调用Web Service。

> SOAP协议 = HTTP协议 + XML数据格式
> 
>  *  Soap 是XML Web Service 的通信协议。
>  *  SOAP 是一种规范，用来定义消息的XML 格式 。包含在一对SOAP 元素中的、结构正确的XML 段就是SOAP 消息。

## **WSDL**： ##

好比我们去商店买东西，首先要知道商店里有什么东西可买，然后再来购买，商家的做法就是张贴广告海报。 WebService也一样，WebService客户端要调用一个WebService服务，首先要知道这个服务的地址在哪，以及这个服务里有什么方法可以调用，所以，WebService务器端首先要通过一个WSDL文件来说明自己家里有啥服务可以对外调用，服务是什么（服务中有哪些方法，方法接受的参数是什么，返回值是什么），服务的网络地址用哪个url地址表示，服务通过什么方式来调用。

WSDL(Web Services Description Language)就是这样一个基于XML的语言，用于描述Web Service及其函数、参数和返回值。它是WebService客户端和服务器端都能理解的标准格式。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应WebService的代理类代码。

WSDL文件保存在Web服务器上，通过一个url地址就可以访问到它。客户端要调用一个WebService服务之前，要知道该服务的WSDL文件的地址。WebService服务提供商可以通过两种方式来暴露它的WSDL文件地址：

1.  注册到UDDI服务器，以便被人查找；
2.  直接告诉给客户端调用者。

## **UDDI：** ##

UDDI 目录条目是介绍所提供的业务和服务的XML 文件。UDDI 目录条目包括三个部分。

“白页”介绍提供服务的公司:名称、地址、联系方式等等;

“黄页”包括基于标准分类法的行业类别;

“绿页”详细介绍了访问服务的接口，以便用户能够编写应用程序以使用 Web 服务。

服务的定义是通过一个称为类型模型(或 tModel)的 UDDI文档来完成的。多数情况下，tModel包含一个WSDL 文件，用于说明访问 XMLWeb Service 的SOAP 接口，但是tModel非常灵活，可以说明几乎所有类型的服务。

# RMI  #

**Java RMI**，即 远程方法调用(**Remote Method Invocation**)，一种用于实现远程过程调用(**RPC**)的Java API， 能直接传输序列化后的Java对象和分布式垃圾收集。它的实现依赖于Java虚拟机(**JVM**)，因此它仅支持从一个JVM到另一个JVM的调用。甚至，它可以直接看成**RPC的java版本**。

RMI 采用**stubs（占位程序）**和 **skeletons** 来进行远程对象(**remote object**)的通讯。

stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的，通过该机制RMI就好比它是本地工作，采用tcp/ip协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于JAVA语言，客户机与服务器紧耦合，**缺点是只能使用java**。

总结起来，RMI的工作原理大致可以理解为：

> 服务器端提供服务，服务中要暴露可以调用的远程方法，以接口的形式表现，这样在客户端可以通过服务接口来调用远程方法，实现复杂的业务逻辑。在服务器端，首先要对接口中提供的方法实现，以便客户端调用能够完成一定的业务逻辑；接着需要生成Skeleton，在Skeleton中真正地实现了对商业方法的调用，完成了客户请求的调用的过程，将获取到的调用方法的结果通过序列化机制返回给客户端，进行应答。
> 
> 在客户端，通过Stub来接收服务器返回的数据（对象），即在这里进行了反序列化，也就是读取网络传输的字节流，进而进行重构。在Skeleton和Stub中，都对网络通信进行了处理，例如建立套接字，建立网络连接，为实际的业务需要做好准备。

## JMS ##

JMS是Java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。JMS支持两种消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即点对点和发布订阅模型。

[Link 1]: https://blog.csdn.net/ljy950914/article/details/100079754
[dubbo]: http://dubbo.apache.org/zh-cn/
[gRPC]: https://grpc.io
[Thrift]: http://thrift.apache.org/
[Finagle]: https://twitter.github.io/finagle/