【你问我答】如何理解RPC 和 RESTful ？

面试的回答的话： 1、从本质区别上看，RPC是基于TCP实现的，RESTFUL是基于HTTP来实现的。 2、从传输速度上来看，因为HTTP封装的数据量更多所以数据传输量更大，所以RPC的传输速度是比RESTFUL更快的。 3、因为HTTP协议是各个框架都普遍支持的。在toC情况下，因为不知道情况来源的框架、数据形势是什么样的，所以在网关可以使用Restful利用http来接受。而在微服务内部的各模块之间因为各协议方案是公司内部自己定的，所以知道各种数据方式，可以使用TCP传输以使各模块之间的数据传输更快。所以可以网关和外界的数据传输使用RESTFUL，微服务内部的各模块之间使用RPC。 4、RESTFUL的API的设计上是面向资源的，对于同一资源的获取、传输、修改可以使用GET、POST、PUT来对同一个URL进行区别，而RPC通常把动词直接体现在URL上

最简单的说法，RPC基于TCP，RESTFUL基于HTTP

RESTful是一个http接口的标准，你可以遵守，也可以不遵守。     RPC广义上讲是远程过程调用，实现方式可以使用基于tcp的http，也可以使用tcp➕其他协议，甚至udp，这样做主要为了安全性或者速度上面的一些属性的提升。

在微服务中，使用什么协议来构建服务体系，一直是个热门话题。 争论的焦点集中在两个候选技术： (binary) RPC&nbs***bsp;Restful。 以Apache Thrift为代表的二进制RPC，支持多种语言（但不是所有语言），四层通讯协议，性能高，节省带宽。相对Restful协议，使用Thrifpt RPC，在同等硬件条件下，带宽使用率仅为前者的20%，性能却提升一个数量级。但是这种协议最大的问题在于，无法穿透防火墙。 以Spring Cloud为代表所支持的Restful 协议，优势在于能够穿透防火墙，使用方便，语言无关，基本上可以使用各种开发语言实现的系统，都可以接受Restful 的请求。 但性能和带宽占用上有劣势。 所以，业内对微服务的实现，基本是确定一个组织边界，在该边界内，使用RPC; 边界外，使用Restful。这个边界，可以是业务、部门，甚至是全公司。 使用RPC远程服务调用方式与传统http接口直接调用方式的差别在于： 1. 从使用方面看，Http接口只关注服务提供方，对于客户端怎么调用，调用方式怎样并不关心，通常情况下，我们使用Http方式进行调用时，只要将内容进行传输即可，这样客户端在使用时，需要更关注网络方面的传输，比较不适用与业务方面的开发；而RPC服务则需要客户端接口与服务端保持一致，服务端提供一个方法，客户端通过接口直接发起调用，业务开发人员仅需要关注业务方法的调用即可，不再关注网络传输的细节，在开发上更为高效。 2. 从性能角度看，使用Http时，Http本身提供了丰富的状态功能与扩展功能，但也正由于Http提供的功能过多，导致在网络传输时，需要携带的信息更多，从性能角度上讲，较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据，传输数据更小，性能更高。 3. 从运维角度看，使用Http接口时，常常使用一个前端代理，来进行Http转发代理请求的操作，需要进行扩容时，则需要去修改代理服务器的配置，较为繁琐，也容易出错。而使用RPC方式的微服务，则只要增加一个服务节点即可，注册中心可自动感知到节点的变化，通知调用客户端进行负载的动态控制，更为智能，省去运维的操作。

RPC：远程过程调用（英语：Remote Procedure Call，缩写为 RPC）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。 1. 解决分布式系统中，服务之间的调用问题。 2. 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。 其中左边的Client，对应的就是前面的Service A，而右边的Server，对应的则是Service B。 RESTful是一个http接口的标准。详情请看REST规定

你想想看 要调用远端的接口 就必须要走网络 那么就必须要走socket去传输数据 发送信息告诉他 我要调用你的接口 那么如何约定双方的传输格式和规范呢（毕竟要被识别出来能够读取调用的方法），那么可以用已有的轮子http 并且基于resful风格（运用上http的状态码 方法类型）来做，或者自己写一套协议自己定消息头消息体 那么就是rpc风格

RPC是Remote Procedure Calling即远程过程调用。 客户端通过参数传递的方式调用服务器上的一个函数或方法并得到返回的结果。 1. 客户端和服务端分别维护一个（ID——>方法）的对应表，ID在所有进程中都是唯一确定的，客户端请求调用时附上ID，服务端通过查表来确定客户端需要调用的服务。 2. 客户端和服务端进行交互时将参数或结果转化为字节流在网络中传输（即序列化和反序列化） 3. 多数RPC框架选择TCP作为传输协议，也有部分选择HTTP。TCP更加高效，HTTP应用灵活，各有利弊。 RESTFUL并不是一种协议，可以说是一种架构风格，提供设计原则和约束条件。 对资源的操作（获取、创建、修改、删除）的操作和HTTP协议提供的GET/POST/PUT/DELETE对应。 特点是： 1. 基于HTTP/HTTPS，跟语言无关。java写的接口，c++也可以调用，ios也可以调用，能够统一接口 2. 和RPC相比，当RPC的server更新时，那么客户的jar包也需要更新。 两者比较： 都是网络交互的协议规范，通常用于多个微服务之间的通信协议。 HTTP相对更规范，标准，通用，各种语言都支持HTTP协议，所以对于对外开放的API为了适用于编程语言的多样性都包含了RESTful风格。 RPC大大降低了架构微服务化的成本，提供调用方与服务方的研发效率，屏蔽跨进程调用服务的各类复杂细节，像调用本地服务一样。