接下来的文章中，我将会去分析Java语言中常用的RPC框架，包括但不限于RMI、dubbo、Hessian框架。这篇文章将简要介绍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