实现一个迷你版的RPC

前言

在实际后台服务开发中，好比订单服务（开发者A负责）须要调用商品服务（开发者B负责），那么开发者B会和A约定调用API，以接口的形式提供给A。一般都是B把API上传到Maven私服，而后B开始写API的实现，A只须要引入API依赖进行开发便可。

动手实现RPC

商品服务工程

注意，我将商品服务的API以及实现分为Maven的2个模块来开发。这里，咱们想给定一个商品ID，查询获得商品对象信息。

商品对象

要注意的是，Product是能够被序列化的，Why?

很显然，订单系统调用商品系统的时候，须要商品系统返回一个商品，必然涉及到发生网络传输，这就涉及对象的序列化和反序列化了。

商品查询API接口

订单系统调用商品服务

在订单系统工程中须要引入商品服务API依赖。

在上图代码中，最重要的就是rpc方法了！

rpc实现方法

第一，咱们看到了Proxy.newProxyInstance，很显然在进行动态代理。也便是说，在订单服务调用商品服务的代码中，咱们先是经过动态代理返回一个代理的IProductService类型对象，这意味着当代理对象调用queryById方法的时候，会自动调用invoke方法！

第二，咱们看看invoke到底作了些什么？

它本质上就是进行Socket通讯，那么它须要传递什么信息给到商品服务呢？

咱们知道订单系统就是想调用商品服务的某个类的某个方法，而后把这个方法的返回结果传输给订单系统！

想想，如何调用某个类的某个方法呢？

只要咱们能肯定这个类的全限定类名、肯定方法名、肯定方法的参数类型，给定方法须要的具体参数，经过反射就能实现。

商品服务调用后获得的结果，咱们序列化写入Socket流中，在订单系统中反序列化获得对象便可。

第三，这里须要思考一个问题：在订单系统中咱们只知道商品服务的API，并不知道这背后的API究竟是如何实现的，因此咱们须要有一个映射，就是商品服务的API到商品服务的实现的一个映射关系，其实这就是所谓的服务的注册！

商品API的具体实现

商品服务

从这里，能够清晰的看到，商品服务读取了订单系统调用商品系统时发送的数据，利用反射机制，进行方法调用，并把调用结果写入Socket输出流。

运行结果

启动商品服务后，经过订单系统发起对商品服务的调用。

之前总认为RPC是高不可攀的，感受是个很神奇的东西，实际上它的底层实现不就是这样的么~