浅谈 RPC、RMI、REST 这些很绕的概念

最近准备详细看一下 RPC 相关的知识,这是第一篇

Posted by ChenJY on September 23, 2018 | Viewed times

什么是 RPC

RPC(Remote Procedure Call) 翻译过来叫远程过程调用,加上 Protocol 之后也有称之为远程过程调用协议,可以由不同的语言实现,根据维基百科的解释 —— RPC 指在分布式环境下,一个计算机程序能调用另一个不同地址空间里的方法(不同地址空间通常指局域网下的另一台计算机),但是编码的形式就像调用一个本地方法一样,程序员不用去关心背后的细节。

为什么要有 RPC 呢?因为你的代码所依赖的服务可能部署在不同的服务器上,而你的程序需要通过网络调用另一台服务器中的某个方法得到结果,在分布式系统中这种场景很常见,微服务的兴起也使得程序间的调用链变得非常复杂、有时候眼花缭乱,RPC 就是为了解决这种问题而诞生的。

常见的 RPC 框架

目前流行的 RPC 框架有阿里的 Dubbo,微博开源的 Motan,Google 开源的 gRpc,百度开源的 brpc,蚂蚁金服开源的 sofa-rpc 等等,Github 上还有数不清的又个人自己实现的简单 RPC 框架,虽然没有什么企业级利用价值,但是对于想了解 RPC 框架原理的新手来说是很宝贵的学习资料。

RPC 和 RMI 的区别

网上一搜这种答案写得都不太好,以我自己来看,二者区别有

  • RPC 更像一种协议,可以跨语言实现,而 RMI 仅支持 Java,需要双方都运行在 JVM 中
  • RPC 通过传入 class 和 methodName 的形式利用反射和代理类调用该方法;RMI 需要依靠方法签名去 lookUp,找到了该方法之后调用它
  • RMI 可以 Java 对象和基本数据类型,而 RPC 通常借助不同的序列化协议来进行网络传输,有编解码的过程

REST 和 RPC 的区别

看了上述的应用场景后,你可能觉得易用的 RESTful API 不也是差不多的么,也是调用一个地址,传入参数,返回结果,而且简单易用,为什么还要有 RPC 框架呢?

回答这个问题不太容易,因为其中的概念很绕。一般来说,在企业级应用中,外部请求进入系统通常使用 RESTful API 的形式,例如用户在 APP 端点击推荐列表;请求在内部系统间处理,服务之间的调用通常采用 RPC 的方式,例如根据算法返回该用户的推荐列表数据。

REST 风格

REST 是一种架构风格,面向资源(由一个 URL 唯一指定),主要是名词,它很好的利用了 HTTP 中已有的请求方法(PUT、POST、GET、DELETE)做操作形式的区分,例如以下场景,左边是错误的 RESTful API 定义(注意,这就是普通的 HTTP 请求地址,这种技术很早就有了,Spring 中你完全可以这样编码去实现功能,只是你的这种风格不叫 RESTful API,而就是普通的 HTTP 请求而已),右边才是符合 REST 风格的定义:

普通HTTP请求 REST 风格请求
GET /rest/api/getBooks GET /rest/api/books
GET /rest/api/addBooks POST /rest/api/books
GET /rest/api/editBooks/:bookId PUT /rest/api/books/:bookId

RPC

而 RPC 主要是动词组成,面向方法,例如方法名为 queryAllBooks,通过客户端和服务端共有的一个方法来进行调用,编码的时候可以像使用本地方法一样,编码效率更高。

二者区别

  • REST 基于 HTTP 传输协议,RPC 的传输协议可以不基于 HTTP,可以采用 TCP、UDP、HTTP、管道通信等技术去实现
  • 后端服务间调用 RPC 性能通常更高,因为实现更底层、封装的数据量更小;而前端请求则通常采用 REST,因为一定要走 HTTP 协议
  • 采用 REST 风格的 API,如果一旦要新增一个删除书籍的方法,那么 URL 地址依据不变,变化的仅是请求方法改为 DELETE;而 RPC 如果要增加这个方法,那么必须新建一个 deleteBook(int bookId) 的方法,客户端需要调用这个新方法达成功能
  • 但是因为 REST 基于 HTTP 协议,因此通常会有前端代理进行请求分发,这种前端代理层的水平扩展不太容易;但 RPC 服务借助注册中心可以轻易实现服务节点的增删和动态调整

License


这是一个不定时更新的、披着程序员外衣的文青小号。

在这里,既分享极客技术,也记录人间烟火,欢迎关注。

0

Comment