什么是 RPC?
RPC(Remote Procedure Call)—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。比如两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢?使用 HTTP请求 当然可以，但是可能会比较慢而且一些优化做的并不好。 RPC 的出现就是为了解决这个问题。
RPC原理是什么?
- 服务消费方(client)调用以本地调用方式调用服务;
- client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;
- client stub找到服务地址，并将消息发送到服务端;
- server stub收到消息后进行解码;
- server stub根据解码结果调用本地的服务;
- 本地服务执行并将结果返回给server stub;
- server stub将返回结果打包成消息并发送至消费方;
- client stub接收到消息，并进行解码;
- 服务消费方得到最终结果。
下面再贴一个网上的时序图：
RPC 解决了什么问题?
从上面对 RPC 介绍的内容中，概括来讲RPC 主要解决了：让分布式或者微服务系统中不同服务之间的调用像本地调用一样简单。
常见的 RPC 框架总结?
- RMI(JDK自带)： JDK自带的RPC，有很多局限性，不推荐使用。
- Dubbo: Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。目前 Dubbo 已经成为 Spring Cloud Alibaba 中的官方组件。
- gRPC ：gRPC是可以在任何环境中运行的现代开源高性能RPC框架。它可以通过可插拔的支持来有效地连接数据中心内和跨数据中心的服务，以实现负载平衡，跟踪，运行状况检查和身份验证。它也适用于分布式计算的最后一英里，以将设备，移动应用程序和浏览器连接到后端服务。
- Hessian： Hessian是一个轻量级的remotingonhttp工具，使用简单的方法提供了RMI的功能。 相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。
- Thrift： Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。
既有 HTTP ,为啥用 RPC 进行服务调用?
RPC 只是一种设计而已
RPC 只是一种概念、一种设计，就是为了解决 不同服务之间的调用问题, 它一般会包含有 传输协议 和 序列化协议 这两个。
实现 RPC 的可以传输协议可以直接建立在 TCP 之上，也可以建立在 HTTP 协议之上。大部分 RPC 框架都是使用的 TCP 连接(gRPC使用了HTTP2)。
HTTP 和 TCP
可能现在很多对计算机网络不太熟悉的朋友已经被搞蒙了，要想真正搞懂，还需要来简单复习一下计算机网络基础知识：
我们通常谈计算机网络的五层协议的体系结构是指：应用层、传输层、网络层、数据链路层、物理层。
应用层(application-layer)的任务是通过应用进程间的交互来完成特定网络应用。HTTP 属于应用层协议，它会基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过 URL 向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。HTTP协议建立在 TCP 协议之上。
运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。TCP是传输层协议，主要解决数据如何在网络中传输。相比于UDP,TCP 提供的是面向连接的，可靠的数据传输服务。
主要关键就在 HTTP 使用的 TCP 协议，和我们自定义的 TCP 协议在报文上的区别。
http1.1协议的 TCP 报文包含太多在传输过程中可能无用的信息：
- HTTP/1.0 200 OK
- Content-Type: text/plain
- Content-Length: 137582
- Expires: Thu, 05 Dec 1997 16:00:00 GMT
- Last-Modified: Wed, 5 August 1996 15:55:28 GMT
- Server: Apache 0.84
- <html>
- <body>Hello World</body>
- </html>
使用自定义 TCP 协议进行传输就会避免上面这个问题，极大地减轻了传输数据的开销。 这也就是为什么通常会采用自定义 TCP 协议的 RPC 来进行进行服务调用的真正原因。除此之外，成熟的 RPC 框架还提供好了“服务自动注册与发现”、"智能负载均衡"、“可视化的服务治理和运维”、“运行期流量调度”等等功能，这些也算是选择 RPC 进行服务注册和发现的一方面原因吧!
一个常见的错误观点
很多文章中还会提到说 HTTP 协议相较于自定义 TCP 报文协议，增加的开销在于连接的建立与断开，但是这个观点已经被否认，下面截取自某乎中一个回答：
首先要否认一点 HTTP 协议相较于自定义 TCP 报文协议，增加的开销在于连接的建立与断开。HTTP 协议是支持连接池复用的，也就是建立一定数量的连接不断开，并不会频繁的创建和销毁连接。二一要说的是 HTTP 也可以使用 Protobuf 这种二进制编码协议对内容进行编码，因此二者最大的区别还是在传输协议上。
题外话
除此之外，还需要注意的一点是 Spring Cloud Netflix 并没有使用 RPC 框架来进行不同服务之间的调用，而是使用 HTTP 协议进行调用的，速度虽然不比 RPC ,但是使用 HTTP 协议也会带来其他很多好处(这一点，可以自行查阅相关资料了解)。
