rest接口_RPC 和 REST 的优缺点、区别、如何选择

写在前面

PRC 是一种技术的代名词，HTTP 是一种协议, RPC 可以通过 HTTP 来实现,也可以通过 Socket 自己实现一套协议来实现。所以谈论为什么用 RPC 不用 HTTP 是无意义的。

所以为什么要用rpc调用？
因为良好的 rpc 调用是面向服务的封装，针对服务的可用性和效率等都做了优化。单纯使用 http 调用则缺少了这些特性。

RPC

调用过程

原理：socket + 动态代理

优点

调用简单，清晰，透明，不用像 rest 一样复杂，就像调用本地方法一样简单

高效低延迟，性能高

自定义协议（让传输报文提及更小）

性能消耗低，高效的序列化协议可以支持高效的二进制传输

自带负载均衡

缺点

1. 耦合性强

引用其他人的总结：

我们为每个微服务定义了各自的 service 抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并 install 之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。
而 REST 接口相比 RPC 更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然 REST 接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST 方式的服务依赖要比 RPC 方式的依赖更为灵活。

2. 无法跨语言，平台敏感

Java 写的 RPC 微服务无法给 Python 调用。需要再实现一层 REST 来对外提供服务

REST

这里就指 HTTP 调用了

优点

耦合性低，兼容性好，提高开发效率

不用关心接口实现细节，相对更规范，更标准，更通用，跨语言支持

缺点

性能不如 RPC 高

选择

RPC 适用于内网服务调用，对外提供服务请走 REST。

IO 密集的服务调用用 RPC，低频服务用 REST

服务调用过于密集与复杂，RPC 就比较适用