RPC是远程过程调用
什么意思呢？
你以前调用的都是本地的服务，如：
val you = ("007");
这个很简单，你也很熟悉，PersonManager是本地内存的一个静态对象嘛，调用它的getById方法嘛
但是假设这个服务提供方是另外一台机器呢？
这个时候你可能会基于HTTP设计一个“上层的”协议，然后以上简单的一句调用会被分解成以下步骤：
（1）你的程序作为客户端，连接到http://host，提交POST请求到服务器的某个servlet：
http://host/PersonManager
为了告诉服务器你要做什么调用，你需要把调用信息封装（序列化）到request消息体里面，例如设计成
{
method: 'getById'
parameters:[
'007'
]
}
（2）servlet解析（反序列化）request消息体，映射成方法名及其参数
（3）根据以上签名，servlet调用本地真正的服务，获取到you对象
（4）servlet将you对象的信息包装（序列化）到response消息中
（5）客户端取到response消息体，解析（反序列化）成Person对象
这个时候，返回值才真正变成本地的对象（其实是一个代理对象），接下来就是消费咯！
从这个例子里，你就看到了，HTTP只管底层的传输，它不关心RPC本身对消息格式的约定，你可以将方法名放在queryString里，也可以全部放到request消息体里。消息体可以用JSon，也可以xml，以及二进制。同样的，返回值及异常信息也需要设计约定，如此如此，就是RPC框架干的事了。
有一些RPC框架就是基于HTTP的，如N年前流行的hessian。基于HTTP，利用一些成熟的序列化器（serde，serializer+deserializer），如Avro，你甚至可以在一个晚起的上午就封装出一个可用的RPC框架。当然了，成熟的RPC除了序列化之外，还要考虑更多的内容，如：异步处理，对象复用啊，什么的。
主要是基于TCP/IP协议，而HTTP服务主要是基于HTTP协议
(摘自百度百科: OSI模型有7层结构，每层都可以有几个子层。 OSI的7层从上到下分别是 7 应用层 6 表示层 5 会话层 4 传输层 3 网络层 2 数据链路层 1 物理层 ；其中高层（即7、6、5、4层）定义了应用程序的功能，下面3层（即3、2、1层）主要面向通过网络的端到端的数据流)
http协议是应用层协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。
在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加轻易。
2. 同步和异步的区别。
3. HTTP与RPC存在重大不同的是：请求是使用具有标准语义的通用的接口定向到资源的，这些语义能够被中间组件和提供服务的来源机器进行解释。结果是使得一个应用支持分层的转换（layers of transformation）和间接层（indirection），并且独立于消息的来源，这对于一个Internet规模、多个组织、无法控制的可伸缩性的信息系统来说，是非常有用的。与之相比较，RPC的机制是根据语言的API（language API）来定义的，而不是根据基于网络的应用来定义的。
http比较好
RPC服务和HTTP服务还是存在很多的不同点的，一般来说，RPC服务主要是针对大型企业的，而HTTP服务主要是针对小企业的，因为RPC效率更高，而HTTP服务开发迭代会更快。总之，选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估 。
HTTP协议比较常用，会好些。
RPC主要是用在大型企业里面，因为大型企业里面系统繁多，业务线复杂，而且效率优势非常重要的一块，这个时候RPC的优势就比较明显了。RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统 一化的操作。
HTTP服务主要是针对中小型企业的，http服务是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。
其中RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已。
至于选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估，从而在仔细比较两种开发框架对于整个项目的影响，最后再决定什么才是最适合这个项目的。一定不要为了使用RPC而每个项目都用RPC，而是要因地制宜，具体情况具体分析。
