RPC 与 Restful 的区别
PRC 是一种技术的代名词，HTTP 是一种协议，RPC 可以通过 HTTP 来实现，也可以通过 Socket 自己实现一套协议来实现。所以谈论为什么用 RPC 不用 HTTP 是无意义的。但我们习惯性将两者进行比较，那就有必要将易混点提出来说说。
RPC主要是基于 TCP/IP协议的，而 HTTP服务主要是基于 HTTP协议的，我们都知道 HTTP协议是在传输层协议 TCP之上的，所以效率来看的话，RPC当然是要更胜一筹啦！下面来具体说一说 RPC服务和 HTTP服务。
OSI 网络七层模型
在说 RPC和 HTTP的区别之前，我觉的有必要了解一下OSI的七层网络结构模型（虽然实际应用中基本上都是五层），它可以分为以下几层：（从上到下）
第一层：应用层。定义了用于在网络中进行通信和传输数据的接口；
第二层：表示层。定义不同的系统中数据的传输格式，编码和解码规范等；
第三层：会话层。管理用户的会话，控制用户间逻辑连接的建立和中断；
第四层：传输层。管理着网络中的端到端的数据传输；
第五层：网络层。定义网络设备间如何传输数据；
第六层：链路层。将上面的网络层的数据包封装成数据帧，便于物理层传输；
第七层：物理层。这一层主要就是传输这些二进制数据；
实际应用过程中，五层协议结构里面是没有表示层和会话层的。应该说它们和应用层合并了。我们应该将重点放在应用层和传输层这两个层面。因为 HTTP是应用层协议，而 TCP是传输层协议。
RPC架构
RPC：Remote Produce Call远程过程调用，类似的还有RMI（Remote Methods Invoke 远程方法调用）。自定义数据格式，基于原生TCP通信，速度快，效率高。 缺点是当使用 RPC框架实现服务间调用的时候，要求服务提供方和服务消费方都必须使用统一的 RPC框架，要么都dubbo，要么都cxf。跨操作系统在同一编程语言内使用。
一个完整的 RPC架构里面包含了四个核心的组件，分别是Client 、Server、Client Stub以及Server Stub，这个Stub大家可以理解为存根。分别说说这几个组件：
【1】客户端（Client），服务的调用方；
【2】服务端（Server），真正的服务提供者；
【3】客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方；
【4】服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法；
传统的 RPC是基于二进制的。因此RPC主要是用在大型企业里面，因为大型企业里面系统繁多，业务线复杂，而且效率优势非常重要的一块，这个时候 RPC的优势就比较明显了。RPC框架要做到的最基本的三件事：
【1】服务端如何确定客户端要调用的函数：在远程调用中，客户端和服务端分别维护一个【ID->函数】的对应表， ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，附上这个ID，服务端通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
【2】如何进行序列化和反序列化：客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化，序列化和反序列化的速度也会影响远程调用的效率。
【3】如何进行网络传输（选择何种网络协议）：多数 RPC框架选择 TCP作为传输协议，也有部分选择 HTTP。如 gRPC使用HTTP2。不同的协议各有利弊。TCP更加高效，而 HTTP在实际应用中更加的灵活。
HTTP服务
HTTP其实是一种网络传输协议，现在客户端浏览器与服务端通信基本都是采用 Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。优势是无需关注服务提供方使用的编程语言，也无需关注服务消费方使用的编程语言，服务提供方只需要提供RESTful风格的接口，服务消费方，按照 RESTful的原则，请求服务，即可。跨系统跨编程语言的远程调用框架。通用性强。REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。RESTful规范把所有内容都视为资源，网络上一切皆资源。REST并没有创造新的技术，组件或服务，只是使用 Web的现有特征和能力。 可以完全通过 HTTP协议实现，使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应 HTTP协议提供的GET、POST、PUT和 DELETE方法。
其实在很久以前，我对于企业开发的模式一直定性为 HTTP接口开发，也就是我们常说的 RESTful风格的服务接口。的确，在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的 Http协议进行传输。
接口可能返回一个 JSON字符串或者是 XML文档。然后客户端再去处理这个返回的信息，从而可以比较快速地进行开发。但是对于大型企业来说，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像 HTTP一样去3次握手什么的，减少了网络开销；其次就是 RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
如何选择
既然两种方式都可以实现远程调用，我们该如何选择呢？
【1】速度来看，RPC要比 HTTP更快，虽然底层都是TCP，但是 HTTP协议的信息往往比较臃肿。
【2】难度来看，RPC实现较为复杂，HTTP相对比较简单。
【3】灵活性来看，HTTP更胜一筹，因为它不关心实现细节，跨平台、跨语言。
因此，两者都有不同的使用场景：
【1】如果对效率要求更高，并且开发过程使用统一的技术栈，那么用 RPC还是不错的。
【2】如果需要更加灵活，跨语言、跨平台，显然 HTTP更合适。
微服务，更加强调的是独立、自治、灵活。而 RPC方式的限制较多，因此微服务框架中，一般都会采用基于 HTTP的RESTful风格服务。
总结
【相同点】：底层通讯都是基于socket，都可以实现远程调用，都可以实现服务调用服务。
【不同点】：RPC服务和 HTTP服务还是存在很多的不同点的，一般来说，RPC服务主要是针对大型企业的，而 HTTP服务主要是针对小企业的，因为 RPC效率更高，而 HTTP服务开发迭代会更快。要对整个项目进行完整地评估，从而在仔细比较两种开发框架对于整个项目的影响，最后再决定什么才是最适合这个项目的。RESTful 调用及测试都很方便，RPC就显得有点繁琐，但是 RPC的效率是毋庸置疑的，所以建议在多系统之间的内部调用采用RPC，对外提供的服务RESTful 更加合适。IO 密集的服务调用用 RPC，低频服务用 RESTful（效率层面）。用更少的请求字节数来达到通信的目的，它主要用于分布式架构中应用与应用的交互。Restful基于Http应用层协议而 Http协议基于 Tcp协议，它遵守了 Http协议，当然它的请求字节数就大，它面向的是资源，通过对资源的Get/Post等实现前后端的交互。
| 比较项 | RESTful | RPC |
| 通信协议 | HTTP | 一般 TCP |
| 灵活度 | 高 | 低 |
| 效率 | 低 | 高 |
