Java分布式应用简介及远程通讯可选技术及原理

（一）Java分布式应用简介

       大型应用通常会拆分为多个子系统，对于java来说，这些子系统可能部署在同一台机器上的多个不同的JVM中，也可能部署在不同的 电脑上，但这些子系统有不是完全独立的，要相互通信来实现业务功能，对于此类java应用，我们称为java分布式应用。 

对于分布式java应用，通常有两种典型的方式来实现：

1.基于消息方式实现系统间的通信 

当系统之间要通信时，就向外发送消息，消息可以是字节流、字节数组，甚至是java对象。 
消息方式的系统间通信，通常基于网络协议来实现，常用的实现系统间通信的协议是:TCP/IP和UDP/IP 

TCP/IP是一种可靠的网络数据传输协议，TCP/IP要求通信双方首先建立连接，然后进行通信。TCP/IP负责保证数据传输的可靠性， 
包括数据的可到达、数据到达的顺序等，但由于TCP/IP要保证连接和数据的可靠性，因此可能会牺牲一些性能。 

UDP/IP是一种不保证一定数据一定到达的网络数据传输协议。UDP/IP并不直接给通信的双方建立连接，而是发送到网络上进行传递。 
由于UDP/IP不建立连接，并且不能保证数据传输的可靠性，因此性能上表现比较好，但可能出现数据丢失以及数据乱序的现象。 

TCP/IP和UDP/IP可用于完成数据的传输，但要完成系统间的通信，还需要对数据进行处理。读取和写入，按照POSIX(可移植操作系统接口) 分为同步IO和异步IO，其中同步IO中最常用的是BIO(Blocking IO)和NIO(Non-Blocking IO) 

BIO:当发起IO的读和写操作时，均为阻塞方式 
NIO:是基于事件驱动的，发起IO的读和写操作时，均为非阻塞方式 

AIO:为异步IO方式，同样基于事件驱动思想，和NIO不同，当进行读写操作时，只需直接调用API的read和write方法即可。这两种方法均为 异步的，对于读操作而言，当有流可读取时，操作系统会将可读的流传入read方法的缓冲区，并通知应用程序；对于写操作而言，当操作系统将write方法传递的流写入完毕时，操作系统主动通知应用程序。 

较之NIO而言，AIO一方面简化了程序的编写，流的读取和写入都由操作系统来代替完成；另一方面省去了NIO中程序要遍历事件通知 队列(Selector)的代价。

windows基于IOCP实现了AIO，Linux目前基于epoll模拟实现了AIO

java对TCP/IP和UDP/IP都支持，在网络IO的操作上，java 7以前的版本只支持BIO和NIO，java 7以后的版本才支持AIO 

实现的4种方式：TCP/IP+BIO,TCP/IP+NIO,UDP/IP+BIO,UDP/IP+NIO
TCP/IP+BIO
基于socket和serverSocket来实现
通常要面对客户端同时要发送多个请求到服务器端，服务器端同时要接受多个连接发送的请求
a.为了满足客户端同时发送多个请求到服务器端，最简单的方式就是产生多个socket。但是这样会产生两个问题：
一是生成太多的Socket会消耗过多的本地资源，并且客户端生成过多的Socket会导致服务器需要支撑非常高的连接数；
二是生成Socket通常是比较慢的，因此频繁的创建导致系统性能不足
鉴于这两个问题，通常采用连接池的方式来维护Socket，一方面限制了能创建Socket的个数；另一方面由于将socket放入池中，避免了重复创建socket带来的性能下降问题.

另一问题连接池中的socket个数是有限的，但同时要用socket的请求会很多，这时候就会造成激烈的竞争和等待，这时就要合理控制等待响应的超时时间(setSocketTimeOut)

b.为了满足服务器能同时接受多个连接发送的请求，通常采用的方式是在accept获取Socket之后，将此socket放入一个线程中处理，通常将此方式称为一连接一线程。这样服务器就可以接受多个连接发送请求了。
缺点：无论连接上是否有真实的请求，都要耗费一个线程。为避免创建过多的线程导致服务器端资源耗尽，须限制创建线程的数量。
这就造成了在采用BIO的情况下服务器端所能支撑的连接数是有限的。

TCP/IP+NIO
a.对于客户端发送多个请求的需求，NIO方式可以做到不阻塞，因此如果服务器返回的响应能带上请求标示，那客户端可以采用连接复用的方式，即每个SocketChannel在发送消息后，不用等响应即可继续发送其他消息，这种方式可降低连接池带来的资源争抢问题，从而提升系统性能;对于连接不复用的情况，可基于Socket.setSoTimeout的方式来控制同步请求的超时。

b.对于服务器端接受多个连接请求的需求，通常采用一个线程监听连接的事件，另一个或多个线程来监听网络流读写的事件
开源框架Mina，JBoss Netty提供了对TCP/IP+NIO通信的支持

UDP/IP+BIO
在java中可基于DatagramSocket和DatagramPacket来实现UDP/IP+BIO，DatagramSocket负责监听端口及读取数据。DatagramPacket作为数据流对象进行传输。

UDP/IP+NIO
在java中可基于DatagramChannel和ByteBuff来实现UDP/IP+NIO，DatagramChannel负责监听端口及读取数据。ByteBuff用于数据流传输。

2.基于远程调用方式实现系统间的通信 

可通过调用一个本地的java接口的方法，透明的调用远程的java实现。具体细节则由java或框架来完成，这种方法主要用来实现基于RMI 和webservice的应用。
RMI的开源框架Spring RMI，webservice开源框架CXF，Axis等

（二）  Java远程通讯可选技术及原理

        在分布式服务框架中，一个最基础的问题就是远程服务是怎么通讯的，在Java领域中有很多可实现远程通讯的技术，例如：RMI、MINA、ESB、 Burlap、Hessian、SOAP、EJB和JMS 等，这些名词之间到底是些什么关系呢，它们背后到底是基于什么原理实现的呢，了解这些是实现分布式服务框架的基础知识，而如果在性能上有高的要求的话，那深入了解这些技术背后的机制就是必须的了，在这篇文章中我们将来一探究竟。

1、   基本原理

要实现网络机器间的通讯，首先得来看看计算机系统网络通信的基本原理，在底层层面去看，网络通信需要做的就是将流从一台计算机传输到另外一台计算机，基于传输协议和网络IO来实现，其中传输协议比较出名的有http、tcp、udp等等，http、tcp、udp都是在基于Socket概念上为某类应用场景而扩展出的传输协议，网络IO，主要有bio、nio、aio三种方式，所有的分布式应用通讯都基于这个原理而实现，只是为了应用的易用，各种语言通常都会提供一些更为贴近应用易用的应用层协议。

2、   应用级协议

远程服务通讯，需要达到的目标是在一台计算机发起请求，另外一台机器在接收到请求后进行相应的处理并将结果返回给请求端，这其中又会有诸如one way request、同步请求、异步请求等等请求方式，按照网络通信原理，需要实现这个需要做的就是将请求转换成流，通过传输协议传输至远端，远端计算机在接收到请求的流后进行处理，处理完毕后将结果转化为流，并通过传输协议返回给调用端。

原理是这样的，但为了应用的方便，业界推出了很多基于此原理之上的应用级的协议，使得大家可以不用去直接操作这么底层的东西，通常应用级的远程通信协议会提供：

为了避免直接做流操作这么麻烦，提供一种更加易用或贴合语言的标准传输格式;

网络通信机制的实现，就是替你完成了将传输格式转化为流，通过某种传输协议传输至远端计算机，远端计算机在接收到流后转化为传输格式，并进行存储或以某种方式通知远端计算机。

所以在学习应用级的远程通信协议时，我们可以带着这几个问题进行学习：

◆ 传输的标准格式是什么?

◆ 怎么样将请求转化为传输的流?

◆ 怎么接收和处理流?

◆ 传输协议是?

不过应用级的远程通信协议并不会在传输协议上做什么多大的改进，主要是在流操作方面，让应用层生成流和处理流的这个过程更加的贴合所使用的语言或标准，至于传输协议则通常都是可选的，在java领域中知名的有：RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS，来具体的看看这些远程通信的应用级协议：

3、   RMI

RMI是个典型的为java定制的远程通信协议，我们都知道，在single vm中，我们可以通过直接调用java object instance来实现通信，那么在远程通信时，如果也能按照这种方式当然是最好了，这种远程通信的机制成为RPC(Remote Procedure Call)，RMI正是朝着这个目标而诞生的。

来看下基于RMI的一次完整的远程通信过程的原理：

◆ 客户端发起请求，请求转交至RMI客户端的stub类;

◆ stub类将请求的接口、方法、参数等信息进行序列化;

◆ 基于socket将序列化后的流传输至服务器端;

◆ 服务器端接收到流后转发至相应的skelton类;

◆ skelton类将请求的信息反序列化后调用实际的处理类;

◆ 处理类处理完毕后将结果返回给skelton类;

◆ Skelton类将结果序列化，通过socket将流传送给客户端的stub;

◆ stub在接收到流后反序列化，将反序列化后的Java Object返回给调用者。

根据原理来回答下之前学习应用级协议带着的几个问题：

◆ 传输的标准格式是什么?

是Java ObjectStream。

◆ 怎么样将请求转化为传输的流?

基于Java串行化机制将请求的java object信息转化为流。

◆ 怎么接收和处理流?

根据采用的协议启动相应的监听端口，当有流进入后基于Java串行化机制将流进行反序列化，并根据RMI协议获取到相应的处理对象信息，进行调用并处理，处理完毕后的结果同样基于java串行化机制进行返回。

◆ 传输协议是?

Socket。

4、   XML-RPC

XML-RPC也是一种和RMI类似的远程调用的协议，它和RMI的不同之处在于它以标准的xml格式来定义请求的信息(请求的对象、方法、参数等)，这样的好处是什么呢，就是在跨语言通讯的时候也可以使用。

来看下XML-RPC协议的一次远程通信过程：

◆ 客户端发起请求，按照XML-RPC协议将请求信息进行填充;

◆ 填充完毕后将xml转化为流，通过传输协议进行传输;

◆ 接收到在接收到流后转换为xml，按照XML-RPC协议获取请求的信息并进行处理;

◆ 处理完毕后将结果按照XML-RPC协议写入xml中并返回。

同样来回答问题：

◆ 传输的标准格式是?

标准格式的XML。

◆ 怎么样将请求转化为传输的流?

将XML转化为流。

◆ 怎么接收和处理流?

通过监听的端口获取到请求的流，转化为XML，并根据协议获取请求的信息，进行处理并将结果写入XML中返回。

◆ 传输协议是?

Http。

5、   Binary-RPC

Binary-RPC看名字就知道和XML-RPC是差不多的了，不同之处仅在于传输的标准格式由XML转为了二进制的格式。

同样来回答问题：

◆ 传输的标准格式是?

标准格式的二进制文件。

◆ 怎么样将请求转化为传输的流?

将二进制格式文件转化为流。

◆ 怎么接收和处理流?

通过监听的端口获取到请求的流，转化为二进制文件，根据协议获取请求的信息，进行处理并将结果写入XML中返回。

◆ 传输协议是?

Http。

6、   SOAP

SOAP原意为SimpleObject Access Protocol，是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议，可以认为SOAP是XML RPC的高级版，两者的原理完全相同，都是http+XML，不同的仅在于两者定义的XML规范不同，SOAP也是Webservice采用的服务调用协议标准，因此在此就不多加阐述了。

7、   CORBA

Common Object Request BrokerArchitecture(公用对象请求代理[调度]程序体系结构)，是一组用来定义“分布式对象系统”的标准，由OMG(Object Menagement Group)作为发起和标准制定单位。CORBA的目的是定义一套协议，符合这个协议的对象可以互相交互，不论它们是用什么样的语言写的，不论它们运行于什么样的机器和操作系统。

CORBA在我看来是个类似于SOA的体系架构，涵盖可选的远程通信协议，但其本身不能列入通信协议这里来讲，而且CORBA基本淘汰，再加上对CORBA也不怎么懂，在此就不进行阐述了。

8、   JMS

JMS呢，是实现java领域远程通信的一种手段和方法，基于JMS实现远程通信时和RPC是不同的，虽然可以做到RPC的效果，但因为不是从协议级别定义的，因此我们不认为JMS是个RPC协议，但它确实是个远程通信协议，在其他的语言体系中也存在着类似JMS的东西，可以统一的将这类机制称为消息机制，而消息机制呢，通常是高并发、分布式领域推荐的一种通信机制，这里的主要一个问题是容错(详细见ErLang论文)。

来看JMS中的一次远程通信的过程：

◆ 客户端将请求转化为符合JMS规定的Message;

◆ 通过JMS API将Message放入JMS Queue或Topic中;

◆ 如为JMS Queue，则发送中相应的目标Queue中，如为Topic，则发送给订阅了此Topic的JMS Queue。

处理端则通过轮训JMS Queue，来获取消息，接收到消息后根据JMS协议来解析Message并处理。

回答问题：

◆ 传输的标准格式是?

JMS规定的Message。

◆ 怎么样将请求转化为传输的流?

将参数信息放入Message中即可。

◆ 怎么接收和处理流?

轮训JMS Queue来接收Message，接收到后进行处理，处理完毕后仍然是以Message的方式放入Queue中发送或Multicast。

◆ 传输协议是?

不限。

基于JMS也是常用的实现远程异步调用的方法之一。

当然，在上面的原理中并没有介绍到所有的java领域可选的远程通信协议了，例如还有EJB采用的ORMI、Spring自己定义的一个简单的Http Invoker等等。

看完原理后我们再来看看目前java领域可用于实现远程通讯的框架或library，知名的有：JBoss-Remoting、Spring- Remoting、Hessian、Burlap、XFire(Axis)、ActiveMQ、Mina、Mule、EJB3等等，来对每种做个简单的介绍和评价，其实呢，要做分布式服务框架，这些东西都是要有非常深刻的了解的，因为分布式服务框架其实是包含了解决分布式领域以及应用层面领域两方面问题的。

当然，你也可以自己根据远程网络通信原理(transportprotocol+Net IO)去实现自己的通讯框架或library。

那么在了解这些远程通讯的框架或library时，会带着什么问题去学习呢?

◆ 是基于什么协议实现的?

◆ 怎么发起请求?

◆ 怎么将请求转化为符合协议的格式的?

◆ 使用什么传输协议传输?

◆ 响应端基于什么机制来接收请求?

◆ 怎么将流还原为传输格式的?

◆ 处理完毕后怎么回应?

 

9、   JBoss-Remoting

Jboss-remoting是由jboss编写的一个java领域的远程通讯框架，基于此框架，可以很简单的实现基于多种传输协议的java对象的RPC。

直接来回答问题：

◆ 是基于什么协议实现的?

JBoss-Remoting是个通讯框架，因此它支持多种协议方式的通信，例如纯粹的socket+io方式、rmi方式、http+io方式等。

◆ 怎么发起请求?

在JBoss-Remoting中，只需将需要发起的请求参数对象传入jboss-remoting的InvocationRequest对象即可，也可根据协议基于InvocationRequest封装符合需求的InvocationRequest对象。

◆ 怎么将请求转化为符合协议的格式的?

JBoss-Remoting基于Java串行化机制或JBoss自己的串行化实现来将请求转化为对象字节流。

◆ 使用什么传输协议传输?

支持多种传输协议，例如socket、http等。

◆ 响应端基于什么机制来接收请求?

响应端只需将自己的处理对象注册到JBoss-Remoting提供的server端的Connector对象中即可。

◆ 怎么将流还原为传输格式的?

JBoss-Remoting基于java串行化机制或jboss自己的串行化实现来将请求信息还原为java对象。

◆ 处理完毕后怎么回应?

处理完毕后将结果对象直接返回即可，jboss-remoting会将此对象按照协议进行序列化，返回至调用端。

另外，jboss-remoting支持多种通信方式，例如同步/异步/单向通信等。

10、   Spring-Remoting

Spring-remoting是Spring提供java领域的远程通讯框架，基于此框架，同样也可以很简单的将普通的spring bean以某种远程协议的方式来发布，同样也可以配置spring bean为远程调用的bean。

◆ 是基于什么协议实现的?

和JBoss-Remoting一样，作为一个远程通讯的框架，Spring通过集成多种远程通讯的library，从而实现了对多种协议的支持，例如rmi、http+io、xml-rpc、binary-rpc等。

◆ 怎么发起请求?

在Spring中，由于其对于远程调用的bean采用的是proxy实现，发起请求完全是通过服务接口调用的方式。

◆ 怎么将请求转化为符合协议的格式的?

Spring按照协议方式将请求的对象信息转化为流，例如SpringHttp Invoker是基于Spring自己定义的一个协议来实现的，传输协议上采用的为http，请求信息是基于java串行化机制转化为流进行传输。

◆ 使用什么传输协议传输?

支持多种传输协议，例如rmi、http等等。

◆ 响应端基于什么机制来接收请求?

响应端遵循协议方式来接收请求，对于使用者而言，则只需通过spring的配置方式将普通的spring bean配置为响应端或者说提供服务端。

◆ 怎么将流还原为传输格式的?

按照协议方式来进行还原。

◆ 处理完毕后怎么回应?

处理完毕后直接返回即可，spring-remoting将根据协议方式来做相应的序列化。

11、   Hessian

Hessian是由caucho提供的一个基于binary-RPC实现的远程通讯library。

◆ 是基于什么协议实现的?

基于Binary-RPC协议实现。

◆ 怎么发起请求?

需通过Hessian本身提供的API来发起请求。

◆ 怎么将请求转化为符合协议的格式的?

Hessian通过其自定义的串行化机制将请求信息进行序列化，产生二进制流。

◆ 使用什么传输协议传输?

Hessian基于Http协议进行传输。

◆ 响应端基于什么机制来接收请求?

响应端根据Hessian提供的API来接收请求。

◆ 怎么将流还原为传输格式的?

Hessian根据其私有的串行化机制来将请求信息进行反序列化，传递给使用者时已是相应的请求信息对象了。

◆ 处理完毕后怎么回应?

处理完毕后直接返回，hessian将结果对象进行序列化，传输至调用端。

12、   Burlap

Burlap也是有caucho提供，它和hessian的不同在于，它是基于XML-RPC协议的。

◆ 是基于什么协议实现的?

基于XML-RPC协议实现。

◆ 怎么发起请求?

根据Burlap提供的API。

◆ 怎么将请求转化为符合协议的格式的?

将请求信息转化为符合协议的XML格式，转化为流进行传输。

◆ 使用什么传输协议传输?

Http协议。

◆ 响应端基于什么机制来接收请求?

监听Http请求。

◆ 怎么将流还原为传输格式的?

根据XML-RPC协议进行还原。

◆ 处理完毕后怎么回应?

返回结果写入XML中，由Burlap返回至调用端。

13、   XFire、Axis

XFire、Axis是Webservice的实现框架，WebService可算是一个完整的SOA架构实现标准了，因此采用XFire、Axis这些也就意味着是采用webservice方式了。

◆ 是基于什么协议实现的?

基于SOAP协议。

◆ 怎么发起请求?

获取到远端service的proxy后直接调用。

◆ 怎么将请求转化为符合协议的格式的?

将请求信息转化为遵循SOAP协议的XML格式，由框架转化为流进行传输。

◆ 使用什么传输协议传输?

Http协议。

◆ 响应端基于什么机制来接收请求?

监听Http请求。

◆ 怎么将流还原为传输格式的?

根据SOAP协议进行还原。

◆ 处理完毕后怎么回应?

返回结果写入XML中，由框架返回至调用端。

14、   ActiveMQ

ActiveMQ是JMS的实现，基于JMS这类消息机制实现远程通讯是一种不错的选择，毕竟消息机制本身的功能使得基于它可以很容易的去实现同步/异步/单向调用等，而且消息机制从容错角度上来说也是个不错的选择，这是Erlang能够做到容错的重要基础。

◆ 是基于什么协议实现的?

基于JMS协议。

◆ 怎么发起请求?

遵循JMS API发起请求。

◆ 怎么将请求转化为符合协议的格式的?

不太清楚，猜想应该是二进制流。

◆ 使用什么传输协议传输?

支持多种传输协议，例如socket、http等等。

◆ 响应端基于什么机制来接收请求?

监听符合协议的端口。

◆ 怎么将流还原为传输格式的?

同问题3。

◆ 处理完毕后怎么回应?

遵循JMS API生成消息，并写入JMS Queue中。

基于JMS此类机制实现远程通讯的例子有Spring-Intergration、Mule、Lingo等等。

15、   Mina

Mina是Apache提供的通讯框架，在之前一直没有提到网络IO这块，之前提及的框架或library基本都是基于BIO的，而Mina是采用 NIO的，NIO在并发量增长时对比BIO而言会有明显的性能提升，而java性能的提升，与其NIO这块与OS的紧密结合是有不小的关系的。

◆ 是基于什么协议实现的?

基于纯粹的Socket+NIO。

◆ 怎么发起请求?

通过Mina提供的Client API。

◆ 怎么将请求转化为符合协议的格式的?

Mina遵循java串行化机制对请求对象进行序列化。

◆ 使用什么传输协议传输?

支持多种传输协议，例如socket、http等等。

◆ 响应端基于什么机制来接收请求?

以NIO的方式监听协议端口。

◆ 怎么将流还原为传输格式的?

遵循java串行化机制对请求对象进行反序列化。

◆ 处理完毕后怎么回应?

遵循Mina API进行返回。

MINA是NIO方式的，因此支持异步调用是毫无悬念的。

16、   EJB

EJB最突出的在于其分布式，EJB采用的是ORMI协议，和RMI协议是差不多的，但EJB在分布式通讯的安全控制、transport pool、smart proxy等方面的突出使得其在分布式领域是不可忽视的力量。

◆ 是基于什么协议实现的?

基于ORMI协议。

◆ 怎么发起请求?

EJB调用。

◆ 怎么将请求转化为符合协议的格式的?

遵循java串行化机制对请求对象进行序列化。

◆ 使用什么传输协议传输?

Socket。

◆ 响应端基于什么机制来接收请求?

监听协议端口。

◆ 怎么将流还原为传输格式的?

遵循java串行化机制对请求对象进行反序列化。

◆ 处理完毕后怎么回应?

直接返回处理对象即可。

在之前的分布式服务框架系列的文章中对于jndi有误导的嫌疑，在这篇blog中也顺带的提下jndi的机制，由于JNDI取决于具体的实现，在这里只能是讲解下jboss的jndi的实现了。

在将对象实例绑定到jboss jnp server后，当远程端采用context.lookup()方式获取远程对象实例并开始调用时，jboss jndi的实现方法是从jnp server上获取对象实例，将其序列化回本地，然后在本地进行反序列化，之后在本地进行类调用。

通过这个机制，就可以知道了，本地其实是必须有绑定到jboss上的对象实例的class的，否则反序列化的时候肯定就失败了，而远程通讯需要做到的是在远程执行某动作，并获取到相应的结果，可见纯粹基于JNDI是无法实现远程通讯的。

但JNDI也是实现分布式服务框架一个很关键的技术点，因为可以通过它来实现透明化的远端和本地调用，就像ejb，另外它也是个很好的隐藏实际部署机制(就像datasource)等的方案。

17、   总结

由上一系列的分析可知，在远程通讯领域中，涉及的知识点还是相当的多的，例如有：通信协议(Socket/tcp/http/udp/rmi /xml-rpc etc.)、消息机制、网络IO(BIO/NIO/AIO)、MultiThread、本地调用与远程调用的透明化方案(涉及java classloader、DynamicProxy、Unit Test etc.)、异步与同步调用、网络通信处理机制(自动重连、广播、异常、池处理等等)、JavaSerialization (各种协议的私有序列化机制等)、各种框架的实现原理(传输格式、如何将传输格式转化为流的、如何将请求信息转化为传输格式的、如何接收流的、如何将流还原为传输格式的等等)，要精通其中的哪些东西，得根据实际需求来决定了，只有在了解了原理的情况下才能很容易的做出选择，甚至可以根据需求做私有的远程通讯协议，对于从事分布式服务平台或开发较大型的分布式应用的人而言，我觉得至少上面提及的知识点是需要比较了解的。

参考：http://my.oschina.net/ksfzhaohui/blog/109216

                   http://blog.csdn.net/zhaozheng7758/article/details/7820011