RPC（remote procedure call）远程过程调用；Http:超文本传输协议。RPC是一种方法，http是一种协议。RPC服务主体要工作在tcp协议上，而http服务工作在http协议上，由于http协议基于tcp协议，所以rpc服务比http更轻量，效率更高
RPC远程过程调用
RPC效率优势明显，在实际开发中，客户端和服务端在技术方案中约定客户端的调用参数和服务端的返回参数之后就可以各自开发，任何客户端只要按照接口定义的规范发送入参都可以调用该RPC服务，服务端也能按接口定义的规范出参返回计算结果。这样既实现了客户端和服务端之间的解耦，也使得RPC接口可以在多个项目中重复利用
流行rpc框架
dubbo：阿里开源的rpc框架，协议和序列化都可以插拔
gRPC：是google开源项目，基于http2.0协议，gRPC底层使用netty框架
Thrift：是facebook开源项目
客户端（Client），服务的调用方。
服务端（Server），真正的服务提供者。
客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。
Http服务
通过http url调用的服务。
HTTP服务开发即开发ERESTful风格的服务接口。在接口不多、系统之间交互较少的情况下，是一种信息传递的常用通信手段。HTTP接口的优点是简单、直接、开发方便，利用现成的HTTP协议进行传输。在服务开发的时候，约定一个接口文档，严格定义输入和输出，明确每一个接口的请求方法和需要的请求参数及其格式。
在内部子系统较多、接口较多的情况下，RPC框架的好处就凸显出现了，首先是长连接，不必每次通信都要像HTTP那样三次握手，减少了网络开销；其次是RPC框架一般都有注册中心，有丰富的监控发布方法；RPC接口的发布、下线、动态扩展等对调用方是无感知的、统一化的操作。
RPC接口和HTTP接口的区别与联系
RPC接口即相当于调用本地接口一样调用远程服务的接口；HTTP接口是基于http协议的post接口和get接口（等等，2.0版本协议子支持更多）。
传输协议
RPC：可以基于TCP协议，也可以基于HTTP协议。
HTTP：基于HTTP协议。
传输效率
RPC：使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2.0协议，也可以很好地减少报文体积，提高传输效率。
HTTP：如果时基于HTTP1.1的协议，请求中会包含很多无用的内容；如果是基于HTTP2.0，那么简单地封装一下还是可以作为一个RPC使用的，这时标准RPC框架更多是服务治理。
性能消耗
RPC：可以基于thrift实现高效的二进制传输
HTTP：大部分是通过json实现的，字节大小和序列化耗时都比thrift要更消耗性能
负载均衡
RPC：基本都自带了负载均衡策略
HTTP：需要配置Nginx，HAProxy实现
服务治理（下游服务新增，重启，下线时如何不影响上游调用者）
RPC：能做到自动通知，不影响上游
HTTP：需要事先通知，修改Nginx/HAProxy配置
RPC主要用于公司内部服务调用，性能消耗低，传输效率高，服务治理方便。HTTP主要用于对外的异构环境，浏览器调用，APP接口调用，第三方接口调用等等。
RPC和HTTP都可以用于实现远程过程调用，如何选择
从速度上看，RPC比HTTP更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿，不过可以采用gzip压缩
从难度上看，RPC实现较为复杂，http相对简单
从灵活性上看，HTTP更胜一筹，因为它不关心实现细节，跨平台，跨语言
两者有不同的使用场景：
如果对效率要求更高，并且开发过程使用统一的技术栈，那么RPC还是不错的
如果需要更加灵活，跨语言、跨平台，显然HTTP更合适
