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

RPC接⼝测试（⼀）什么是RPC框架
什么是 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容器⾥⾯，这样减少了⽹络传输⽅⾯的开发，只需要关注业务开发即可。

所以在架构⼀个软件的时候，不能⼀定根据需求选定技术。