把RESTful和RPC说清楚的一篇文章「摘抄自网络」

基本都是复制黏贴，全是一个答案，没看到有真正深入思考过的答案，还是我来说说吧。

前言：其实计算机里面的很多概念都是来源于现实世界的，通过现实里面具体的例子来理解RPC。A：代表一栋大楼（相当于一个大的服务端内网集群），B：代表大楼内的一个个房间（每个房间相当于一个应用框架)，C：代表人员管理机构（相当于楼管处或者各级人口管理部门）。首先，在项目架构比较简单的时候，可能一个项目就一个统一的框架，一种语言，这时候我们程序里面的一个方法里面可能会调用N个其他的方法，但因为都是在同一个框架内，都属于框架级的内部调用，这个时候自然用不到RPC，RESTful足以满足当前场景。 但是当你的项目架构越来越复杂，访问量越来越多的时候，可能上了N多框架，N个语言，当你在业务里面调用其他框架的方法或者调用其他独立部署的服务的时候，自然没法像最初那样直接在框架/容器的内部去调用，当这种框架和容器间的这种调用量不是很大的时候依然可以选择用RESTful方式去调用，但是当这种调用量很大，服务很多的时候，RESTful显然是无法满足需求的。

打个比方，最初的内部调用相当于你要找的人和你在同一个房间内，直接就可以找到。但当要找的人分散在大楼的各个房间的时候，你怎么找他呢？你可以去区里人口部门查，查不到去市里 - 省里 - 国家人口管理部门查，最终肯定总能找到他，但这样的方式是不是效率很低，路径很长？所以这个时候就来了RPC解决了这个问题，我们在该大楼一楼建立了统一的楼管处（服务注册中心），该出记录了大楼里面每个人的详细信息，每个人要先去登记（服务注册），要查的时候直接去楼管处查（服务发现）就可以了。当然你可以直接走路（HTTP协议）去查，也可以直接打电话（TCP协议）去楼管处查，也可以微信群（自定义协议）去查。 首先该楼管处记录的信息量非常小（只记录你们大楼的人），非常垂直和精确，所以你去查的速度会非常快，路径会非常短。 如果你还用传统RESTful的方式，首先查找范围会非常大，因为你根本不知道这个人到底在哪里，他可能在你们大楼内，也可能在本市某个角落的大楼里面，还可能在几千公里外的另一个城市，你查找的目标范围会非常大，路径会非常长，不确定性非常大。所以最终的效率肯定是非常低的。

完整的 RPC 框架

在一个典型 RPC 的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中“RPC 协议”就指明了程序如何进行网络传输和序列化。

图完整 RPC 架构图

RPC和RESTful的区别

RPC的优势：

是查找的精确性，快速性，短路径，和确定性，因为属于内网查询，独立的注册中心，所以查找的速度更快。
而且由于做了精简和优化，删去了RESTful方式里面很多多余的信息，比如Header，而且做了压缩和序列化，通过二进制方式传输，传输的内容更少，传输的速度也更快。
环节和流程更少，因为RESTful需要经过路由，负载均衡，网关，防火墙和一系列的身份识别和校验，就像大楼内来了个不认识的人，楼管大叔肯定要查你的身份证等等信息核实你的信息。 而且RPC就省去了这些环节，就像你天天出来进去，楼管大妈早就对你很熟了，不需要每次核实你的信息，RPC省去了很多环节。
RESTful的优势：

通用性更好，RESTful可以供任何接入互联网的终端调用，各种平台，各种终端都可以用RESTful传输和交换数据，而且有一套标准和规范的传输格式，所以格式更加标准化和通用化。
调用及测试都很方便。RPC 实现需要实现编码，序列化，网络传输等。而 RESTful 不要关注这些，RESTful 实现更简单。
移植性更好，从一个服务器迁移到另一个服务器，从一个节点迁移到另一个节点，从一个架构移植到另一种架构，都可以轻松完成。
RPC的应用场景：当你的框架和语言种类也比较多，内部子系统较多、接口非常多的情况下，RPC是最佳的选择。RPC更多是内网之间的数据传输，性能消耗低，传输效率高，实现复杂。一般是部署在服务层的分布式系统里面，或者微服务系统。有服务治理，服务限流、服务降级、服务熔断、服务监控等等，类似于大楼里面配了治安处，物业处、后勤处、监控中心等。

长链接。不必每次通信都要像 HTTP 一样去 3 次握手，减少了网络开销。
注册发布机制。RPC 框架一般都有注册中心，有丰富的监控管理;发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
安全性，没有暴露资源操作。
微服务支持。就是最近流行的服务化架构、服务化治理，RPC 框架是一个强力的支撑。
RESTful的应用场景：数据更多是公网上的传输，主要用于对外的异构环境，浏览器接口调用，App 接口调用，第三方接口调用等。