Java实现RPC框架 - 2 最根本的RPC实现（动态署理）

前言

做RPC的思绪，是从最根本的渐渐升级成一个方便可用的RPC框架。
以是我以为一股脑把优化过程中用到的技能都倒出来并倒霉于学习。照旧渐渐升级，用了什么技能再去相识。在迭代过程中把每次迭代须要的技能点写在前面，方便学习。
本次思量最根本的最容易想到的情况，即长途发消息调用一个固定的方法。就雷同于做算法题要先思量暴力算法，再去举行优化。
须要的技能

• netty/nio/socket网络编程
  
• 动态署理
  

最简朴的RPC

我们服务端有一个UserService接口，有一方法getUserById（Integer id）。
实现类UserServiceImpl实现了接口方法。
我们目标是客户端哀求服务端调用该方法并把结果返回给客户端。
这里我们本身已经知道要调什么方法，以是我们可以吸收到客户端传来的ID后直接调用该方法（固然，后续升级要调用什么方法应该由客户端决定，然后服务端调用对应方法。而不是我们在代码写死调用一个固定方法）。
我们很容易实现这个需求。
使用Socket,NIO大概Netty，实现一个客户端和一个服务端。通过IP创建客户端服务端毗连，客户端发送要查的ID，服务端吸收后去调用对应方法查出结果User对象并发送给客户端。客户端通过readObject()吸收到object对象，强转为User`。
只要你学过网络编程信任不是很难写。
那么如许根本的RPC，很显着是权宜之计。有哪些可以优化的地方呢？
优化点

我们捋一下思绪，整个过程是，客户端发起哀求request，服务端吸收哀求并处置惩罚，封装结果返回给客户端，客户端吸收并处置惩罚。
既然是哀求-相应的网络传输，我们须要界说符合的哀求与相应。我们思量上面的哀求和相应，非常大抵，来看看须要优化的点：

• 这种实现只能调用一个我们写死的方法，由于我们只带了实验的参数，没有指定方法。若服务端有多个方法，我们该实验哪个？（request不但须要参数，还须要指定接口，方法）
  
• 返回值也写死了，须要强转为User。而且response不包罗状态码（无法像http那样返回一个值来表现本次实验是否乐成）
  

除了request和response不敷完备的标题，尚有一个标题
我们的目标是想本地调用一样举行长途调用。但是上面那种写法不符合这个要求
我们上面那种写法，大量的服务端客户端代码袒露在外，但实在通讯过程可以封装到内部。我们须要雷同于本地调用的情势：
注入接口实现，直接调用方法。

1. public class Myclient {  
2.   
3.     @Autowired  
4.     private MyService myService;  
5.   
6.     public void doSomething() {  
7.         myService.performAction();  
8.     }  
9. }

复制代码

但是这是RPC，我们只有这一个接口，是没有它的实现的，以是我们通过发起长途调用的方式来举行方法的调用。也就意味着再RPC中我们用网络通讯发起哀求并得到结果这一过程更换了本地调用中的直接调用。简言之，就是通过网络举行长途调用更换了本地调用。以是我们的目标就明白了。由于本地没有实现类，以是我们给出一个实现类，在实现类中做长途调用中的一系列通讯流程不就好了吗。以是目标是生产该接口的动态署理类（这个署理类实现方法实验后应该与本地方法调用结果同等，但是过程却从本地变为长途调用），署理类中做好长途调用并获取结果这件事。如许我们在举行长途调用时不就雷同本地调用了吗。
总结一下优化点：

• 哀求与相应封装好对象
  
• 使用动态署理完成透明的RPC
  

封装好哀求相应，做好动态署理后有哪些地方还可以优化

结语

本文代码还没整理完，整理完了会贴上来。
不必基于一口气知道终极的RPC实现的功能。在开发过程中去寻求优化渐渐发掘须要的功能。