非原创，仅做针对性总结：参考文章链接附于底部
名词解释
- RPC(Remote Procedure Call，远程过程调用)
- HTTP(HyperText Transfer Protocol 超文本传输协议)
RPC 主要是基于 TCP/IP 协议的，而 HTTP 服务主要是基于 HTTP 协议的，我们都知道 HTTP 协议是在传输层协议 TCP 之上的。
RPC 服务
RPC 架构里的四个核心的组件:
- 客户端（Client），服务的调用方。
- 服务端（Server），真正的服务提供者。
- 客户端存根(Client Stub)，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
- 服务端存根(Server Stub)，接收客户端发送过来的消息，将消息解包，并调用本地的方法。
支持同步调用和异步调用
HTTP 服务
即：RESTful 风格的服务接口。优点就是简单、直接、开发方便。利用现成的 http 协议进行传输。
接口可能返回一个 JSON 字符串或者是 XML 文档。然后客户端再去处理这个返回的信息，从而可以比较快速地进行开发。
RPC VS HTTP
对于大型企业来说，内部子系统较多、接口非常多的情况下，RPC 框架的好处就显示出来了，首先就是长链接，不必每次通信都要像 http 一样去 3 次握手什么的，减少了网络开销；其次就是 RPC 框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
1. 传输协议
RPC，可以基于TCP协议，也可以基于HTTP协议
HTTP，基于HTTP协议
2. 传输效率
RPC，使用自定义的 TCP 协议，可以让请求报文体积更小，或者使用 HTTP2 协议，也可以很好的减少报文的体积，
提高传输效率
HTTP，如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装以下是可以作为一个 RPC 来使用的，这时标准 RPC 框架更多的是服务治理
3. 性能消耗
主要在于序列化和反序列化的耗时
RPC，可以基于thrift实现高效的二进制传输 HTTP，大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能
4. 负载均衡
RPC，基本都自带了负载均衡策略 HTTP，需要配置Nginx，HAProxy来实现
5.服务治理（下游服务新增，重启，下线时如何不影响上游调用者）
RPC，能做到自动通知，不影响上游 HTTP，需要事先通知，修改Nginx/HAProxy配置
上文来自于：
