RPC和HTTP的理解

首先，HTTP其是一个超文本传输协议，它基于 TCP/IP 来传输文本、图片、视频、音频等，HTTP 并不提供数据包的传输功能，而仅仅是客户端和服务端约定好的一种通信格式。因此HTTP 和 RPC 其实是两个维度的东西，HTTP是一种通信协议，而RPC是一种远程过程调用，调用方和接收方也需要约定一个通信格式，可以用 HTTP 协议，也可以是TCP、UDP以及自定义协议（一般选用TCP）。

另一方面，RPC和HTTP都是都是跨应用调用方法的解决方案，准确来说，RPC和Rest才是一种对立关系，RPC，所谓的远程过程调用 ，是面向方法的 ，REST：所谓的 Representational state transfer ，是面向资源的：

• HTTP协议，以其中的Restful规范为代表，其优势很大。它可读性好，跨语言，跨平台，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。但是HTTP也有其缺点，这是与其优点相对应的。首先是有用信息占比少，毕竟HTTP工作在第七层，包含了大量的HTTP头等信息。其次是效率低，还是因为第七层的缘故。还有，其可读性似乎没有必要，因为我们可以引入网关增加可读性。此外，使用HTTP协议调用远程方法比较复杂，要封装各种参数名和参数值。

• RPC是远程过程调用，过程其实就是方法，它的理念就是像调用本地方法一样调用远程方法，这个过程是应用间的内部过程，数据格式需要自己指定，因此牺牲可读性，且不能跨语言，但带来的效率提升、易用性是可取的。RPC要求在调用方中放置被调用的方法的接口。调用方只要调用了这些接口，就相当于调用了被调用方的实际方法，十分易用。于是，调用方可以像调用内部接口一样调用远程的方法，而不用封装参数名和参数值等操作。

  首先，调用方调用的是接口，必须得为接口构造一个假的实现。显然，要使用动态代理。这样，调用方的调用就被动态代理接收到了。

  第二，动态代理接收到调用后，应该想办法调用远程的实际实现。这包括下面几步：

  • 识别具体要调用的远程方法的IP、端口
  • 将调用方法的入参进行序列化
  • 通过通信将请求发送到远程的方法中

  这样，远程的服务就接收到了调用方的请求。它应该：

  • 反序列化各个调用参数
  • 定位到实际要调用的方法，然后输入参数，执行方法
  • 按照调用的路径返回调用的结果

  整个过程如下所示：

  

REST 接口更加规范，通用适配性要求高，建议对外服务的接口都统一成 REST。而多系统之间的内部调用采用RPC，主要是：①不用耗费太多精力去开发和维护多套的HTTP接口；②RPC的调用性能更高，有效信息多，效率高；③使用更加简单。

RPC的了解推荐项目：https://github.com/he2121/MyRPCFromZero
如果有什么不对的地方请指正，仅仅是我的理解，希望有错的地方能纠正。