RPC：Remote Procedure Call，中文意思就是远程过程调用。
01. 既然有 HTTP ，为什么还要用 RPC ？
HTTP 和 RPC 并不是两个并行的概念，虽然很多书或文章，都介绍 HTTP 和 RPC 是在“应用层”，但实际上可以把应用层细分成多层，RPC 的所处的位置是高于 HTTP 的；HTTP 是网络协议，而RPC 可以看做是一种编程模式或实现方案；
RPC 通常包含传输协议和序列化协议，单说传输协议，RPC 可以建立在 TCP 协议之上（比如 Dubbo），也可以建立在 HTTP 协议之上（比如 gRPC）；如果是基于数据形式分类，RPC 又可以分成基于二进制、XML 和 JSON 三种；
而现在非常流行的开源 RPC 框架，比如上文中提到的Dubbo 和 gRPC 分别出身于阿里和谷歌，它们更多地是封装了服务注册发现、负载均衡、链路跟踪等功能，也可以这么理解，RPC 框架是对服务更高级的封装。
02. RPC VS Restful 风格的 API
如果非要比较的话，可以比较 RPC 和 Restful 风格的 API。
- RPC：面向过程，也就是要做一件什么事情，只发送 GET 和 POST 请求；GET 用来查询信息，其他情况下一律用 POST；请求参数是动词。
- RESTful：面向资源，这里的资源可以是一段文字、一个文件、一张图片，总之是一个具体的存在，可以使用 GET、POST、DELETE、PUT 请求，对应了增删查改的操作；请求参数是名词。
比如按照id 查找用户：
- 如果是 RPC 风格的 url 应该是这样的：GET /queryUser?userid=xxx；
- 而 RESTful 风格通常是这样的：GET /user/{userid}
03. 究竟选择哪一个？
RPC 特别适用于是分布式环境；它让客户端进行远程调用时，可以像调用本地方法一样方便；RPC 框架屏蔽了很多底层的细节，开发人员不需要关注这些细节，比如序列化和反序列化、网络传输协议；一些功能强大的 RPC 框架还提供了连接池管理、负载均衡、故障转移、超时管理、上下文管理器、异步回调、收发包队列、工作线程等功能。
RPC 和 Restful 风格的 API，如果非要争出来个第一第二，那么也要结合具体的使用场景，选择更适合的那个。
如果是偏向内部的 API，提供的 API 很难进行资源的抽象，没有规范的 API 的设计，性能要求更高，这些情况下更适合使用 RPC ；如果偏向外部 API，需要有更为规范的 API 设计，并且 API 天生是以资源为维度展开的，这时候可以选择 Restful 风格的 API。
