提到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 协议更简单内容更小，那么来说效率是要高一点