RPC框架（一） - Java自带的RMI

    接下来的文章中，我将会去分析Java语言中常用的RPC框架，包括但不限于RMI、dubbo、Hessian、Spring Remoting框架。这篇文章将简要介绍Java语言自带的RMI协议。

 

    RMI（Remote Method Invocation），远程方法调用，程序调用方无需关心跨机器跨进程的协议调用，更多的把精力放在业务上，而且这也隐藏了服务器实现的细节。

    Java RMI整体结构图如下：

    

    一般情况下，Register为注册中心，一般是和Server在同一个Java 虚拟机中。Server通过开启一个注册中心，将所需要发布的服务注册到Register中，Client通过Register和服务类名称，得到服务，然后通过服务进行调用，完成一个RPC过程。

    下面根据源码，和自己的归纳总结，给出下面的细节分析：

1、生成存根Stub和骨架Skeleton对象，实现类需要继承UnicastRemoteObject 类，并通过构造器调用UnicastRemoteObject 的默认构造器。

2、通过命名服务将存根Stub对象注册到注册中心Register

3、客户端Client通过lookup向注册中心Register请求服务的存根Stub

4、注册中心Register向客户端Client返回存根Stub，客户端将Stub强转为相关服务接口

5、客户端Client使用存根Stub对象，进行接口调用

6、存根Stub通过TCP协议socket发起接口调用，通过网络将相关数据传送到socket服务端即骨架Skeleton

7、骨架Skeleton拿到数据，解析并对具体的服务实现类ServerImpl进行调用

8、服务实现类ServerImpl完成在服务端java虚拟机的调用，将结果数据返回给骨架Skeleton

9、骨架Skeleton通过网络协议将结果数据返回存根Stub

10、存根Stub拿到结果返回上层Client，一个调用过程结束

 

即使RMI在一定程度上对于开发来说简便了很多的细节，开发也不需要关心其中的TCP调用过程，但是RMI也存在一定的劣势。主要表现在

1、RMI的Register一般情况下跟Server在同一个Server下，对于分布式的Server集群，Client并不能很智能的选择，无法做到负载均衡等

2、Register对于端口和ip有严重的依赖，一旦服务器更换了ip，那么Client中的注册中心Register就变成不存在的，对应用影响比较大。这同时也说明了RMI框架更加适用于单系统的简单内部项目中，无法在大型分布式系统上得到更多的发展。不过这里存在一个优化的空间，就是单独把注册中心Register从服务端Server中提出来实现。

3、RMI的发展依旧更多的停留在jdk1.1，后期更新比较少。

尽管如此，但是RMI作为早起的RPC框架，依旧给后来的RPC框架带来了很多的参考意义，例如注册中心、协议等等。

 

参考：

（1）https://blog.csdn.net/xinghun_4/article/details/45787549