RPC接口测试（一）什么是 RPC 框架

转自：https://www.cnblogs.com/111testing/p/11296880.html

什么是 RPC 框架

RPC 框架----- 远程过程调用协议RPC（Remote Procedure Call Protocol)-----允许像调用本地服务一样调用远程服务。

RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。比如说，一个方法可能是这样定义的： 
Employee getEmployeeByName(String fullName)那么：

第一，首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接（socket），远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。

第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。

第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。

第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。

第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用

总的来说可以归纳为以下几步：

1，远程服务之间建立通讯协议

2，寻址：服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么

3，通过序列化和反序列化进行数据传递

4，将传递过来的数据通过java反射原理定位接口方法和参数

5，暴露服务：用map将寻址的信息暴露给远方服务（提供一个endpoint URI或者一个前端展示页面）

6，多线程并发请求业务

 

什么是RPC

提到RPC（Remote Procedure Call），就躲不开提到分布式，这个促使RPC诞生的领域。

假设你有一个Calculator，以及它的实现类CalculatorImpl，那么单体应用时，要调用Calculator的add方法来执行一个加运算，你可以方法中直接使用，因为在同一个地址空间，或者说在同一块内存，这个称为本地函数调用。

现在，将系统改造为分布式应用，接口调用和实现分别在两个子系统内，

服务A里头并没有CalculatorImpl这个类，那它要怎样调用服务B的CalculatorImpl的add方法呢？可以模仿B/S架构的调用方式，在B服务暴露一个Restful接口，然后A服务通过调用这个Restful接口来间接调用CalculatorImpl的add方法。

这样，已经很接近RPC了，不过，像这种每次调用时，是不是都需要写一串发起http请求的代码呢？比如httpClient.sendRequest...之类的，能不能简单一下，像本地方法调用一样，去发起远程调用，让使用者感知不到远程调用的过程。

屏蔽的工作，可以使用代理模式解决，生成一个代理对象，而这个代理对象的内部，就是通过httpClient来实现RPC远程过程调用的。

这就是很多RPC框架要解决的问题和解决的思路，比如阿里的Dubbo。

总结一下，RPC要解决的两个问题：

1. 解决分布式系统中，服务之间的调用问题。

2. 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。

RPC是一种技术的概念名词

RPC=Remote Produce Call 是一种技术的概念名词，HTTP是一种协议,RPC可以通过 HTTP 来实现,也可以通过Socket自己实现一套协议来实现.所以题目可以换一种理解,为何 RPC 还有除 HTTP 之外的实现法,有何必要，毕竟除了HTTP实现外,私有协议不具备通用性.

RPC框架好处

http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；

优点就是简单、直接、开发方便。

如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了：

首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；

其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。

最后是安全性。

rpc是一种概念，http也是rpc实现的一种方式。

论复杂度，dubbo/hessian用起来是超级简单的。

至于为什么用dubbo/hessian，有几点：

一是调用简单，真正提供了类似于调用本地方法一样调用接口的功能 。

二是参数返回值简单明了 参数和返回值都是直接定义在jar包里的，不需要二次解析。

三是 轻量，没有多余的信息。

四是便于管理，基于dubbo的注册中心。

RPC能解耦服务

RPC:远程过程调用。RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里。

通过RPC能解耦服务，这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已。简单的实现可以参考spring remoting，复杂的实现可以参考dubbo。

rpc=socket + 动态代理

服务器通讯原理就是一台socket服务器A,另一台socket客户端B,现在如果要通讯的话直接以流方式写入或读出。这样能实现通讯，但有个问题。如何知道更多信息？

比如需要发送流大小，编码，Ip等。这样就有了协议，协议就是规范，就是发送的流中携带了很多的内容。那回到刚刚的问题。发送的内容就是文本类型，客户端就得序列化，那么常用的就有json，xml之类，如果想把内容变得更小，那就有二进制了。把文本变成二进制传递。

说到 rpc 与http接口，不要太复杂了。rpc 协议更简单内容更小，那么来说效率是要高一点

rpc 是什么？就是socket 加动态代理。

总结

学技术应该是知其然知其所以然，我们得明白什么场景，或者什么业务需要它，它能解决其他技术不能解决或者不方便解决的问题。

RPC是一个软件结构概念，是构建分布式应用的理论基础。就好比为啥你家可以用到发电厂发出来的电？是因为电是可以传输的。至于用铜线还是用铁丝还是其他种类的导线，也就是用http还是用其他协议的问题了。这个要看什么场景，对性能要求怎么样。

在java中的最基本的就是RMI技术，它是java原生的应用层分布式技术。我们可以肯定的是在传输性能方面，RMI的性能是优于HTTP的。

那为啥很少用到这个技术？那是因为用这个有很多局限性，首先它要保证传输的两端都要要用java实现，且两边需要有相同的对象类型和代理接口，不需要容器，但是加大了编程的难度，在应用内部的各个子系统之间还是会看到他的身影，比如EJB就是基于rmi技术的。

这就与目前的bs架构的软件大相径庭。用http必须要服务端位于http容器里面，这样减少了网络传输方面的开发，只需要关注业务开发即可。所以在架构一个软件的时候，不能一定根据需求选定技术。