GMTC深圳站售票最后一周,点击查看最新日程>> 了解详情
写点什么

gRPC vs REST:两种 API 架构风格的对比

  • 2021 年 6 月 15 日
  • 本文字数:3192 字

    阅读完需:约 10 分钟

gRPC vs REST:两种API架构风格的对比

想知道未来是不是 gRPC 的天下?本文会具体介绍两种 API 架构风格:REST 和 gRPC,并讨论它们之间的区别。不过,首先,我们会解释什么是 API,以及为什么它对微服务基础设施而言至关重要。之后,我们会介绍 gRPC 的基础——RPC,并探讨 gRPC 和 REST API 之间的重要差异。根据它们的对比结果,我们最后会分析什么时候应该使用哪种架构类型。

API 是什么


API,即应用程序编程接口。这些接口充当软件中介,为应用程序之间的交互和对话建立特定的定义和规则。API 负责将响应从用户传递到系统,然后从系统返回给用户。听起来还是有点糊涂?


API 的工作机制


假设我们正在预订一个酒店。我们在笔记本电脑上访问酒店预订页面,连接到互联网的这个页面会将数据(我们的请求)发送到服务器。然后,服务器检索数据,解析它,一旦所需的操作得到执行,它就会向我们发送一个响应,并在我们的界面上提供信息。这个过程需要 API 才能实现。


API 指定了一个应用程序(网页或移动应用)可以向另一个应用程序发出的请求类型,并进一步确定:如何发出这些请求;使用哪些数据格式;以及用户必须遵循的实践。


本文会对比 gRPC 和 REST 两大架构风格,因为它们代表了人们创建 API 时最常用的两种架构风格。

API 和微服务


一方面,在单体应用程序中,项目的所有功能都包含在一个单元中,更准确地说是包含在一个代码库中。另一方面,微服务架构由一些较小的服务组成,这些服务使用 HTTP 等协议相互通信。作为微服务架构一部分的组件服务通过 API 相互通信和交互。换句话说,API 允许集成到微服务应用程序中的所有服务互相连接和通信。


最常用的架构风格是 REST API。但构建 API 时主要有 3 种模型:RPC(远程过程调用)、REST(表征状态传输)和 GraphQL。在本文中,我们将重点介绍前两个。

什么是 RPC?


RPC 使用客户端-服务器模型。请求服务器(换句话说就是客户端)请求一条消息,该消息由 RPC 转换并发送到另一台服务器。服务器收到请求后将响应发送回客户端。当服务器处理这个调用时,客户端被阻塞,服务器内部的消息传递被隐藏。


此外,RPC 允许客户端以特定格式请求函数,并以完全相同的格式接收响应。在 URL 中可以找到使用 RPC API 提交调用的方法。RPC 支持本地和分布式环境中的远程过程调用。


与 REST API 一样,RPC 还建立了交互规则以及用户如何提交“调用”(请求)以调用方法与服务通信和交互的机制。

什么是 REST?


使用 REST API 时,来自后端数据的响应通过 JSON 或 XML 消息格式传递给客户端(或用户)。这种架构模型倾向于遵循 HTTP 协议。然而,在维护 RCP 模型的同时,RCP 设计也时常从 HTTP 中汲取一些想法。事实上,不管使用的是哪种模型(RPC 或 REST),大多数现代 API 实现都将 API 映射到相同的 HTTP 协议时。


当 REST API 公开可用时,每个集成微服务应用程序的服务都可以作为资源呈现给用户/客户端,资源可以通过以下 HTTP 命令访问:GETDELETEPOSTPUT

什么是 gRPC?


gRPC 是 Google Remote Procedure Call 的简写,是基于 RCP 架构的变体。该技术遵循一个使用 HTTP 2.0 协议的 RPC API 实现,但 HTTP 不会呈现给 API 开发人员或服务器。因此,开发人员无需担心 RPC 概念如何映射到 HTTP,从而降低了复杂性。


总的来说,gRPC 旨在加快微服务之间的数据传输。它的基础方法是确定一个服务,建立方法和相应的参数来实现远程调用和返回类型。


此外,它以一个 IDL(接口描述语言)表示 RPC API 模型,这为确定远程过程提供了更直接的方法。默认情况下,IDL 使用 Protocol Buffers(但也可以使用其他替代方案)来描述服务接口以及负载消息的结构。

gRPC 与 REST:对比


现在,我们对 gRPC 和 REST 有了一个初步认识,下面我们来看看它们的主要区别。

HTTP 1.1 vs HTTP 2


REST API 遵循一个通常基于 HTTP 1.1 构建的请求-响应通信模型。不幸的是,这意味着如果一个微服务收到来自多个客户端的多个请求,该模型必须每次只处理一个请求,拖慢了整个系统的速度。REST API 也可以构建在 HTTP 2 上,但通信的请求-响应模型保持不变,这使得 REST API 无法充分利用 HTTP 2 的优势,例如流式通信双向支持


gRPC 没有面临类似的障碍。它建立在 HTTP 2 之上,且遵循客户端-响应通信模型。这让它支持双向通信和流式通信,因为 gRPC 能接收来自多个客户端的多个请求,并通过不断地流式传输信息来同时处理这些请求。此外,gRPC 还可以处理“一元”交互,例如构建在 HTTP 1.1 上的交互。


总之,gRPC 能处理一元交互和多种类型的流:


  • 一元:客户端发出单个请求并接收单个响应。

  • 服务器流:服务器对客户端的请求响应一个消息流。当全部数据发送完毕后,服务器会再发送一条状态消息来完成流程。

  • 客户端流:客户端向服务器发送一个消息流,并接收单个响应消息。

  • 双向流:客户端和服务器的两个流互相独立,也就是说它们都能以任何顺序传输消息。客户端负责发起并结束双向流。


流类型

浏览器支持


这可能是 REST 相对于 gRPC 的主要优势之一。一方面,所有浏览器都完全支持 REST。另一方面,gRPC 获得的浏览器支持仍然非常有限。


不幸的是,它需要 gRPC-web 和一个代理层来执行 HTTP 1.1 和 HTTP 2 之间的转换。因此,gRPC 主要用于内部/私有系统(特定组织的后端数据和应用程序功能中的 API 程序)。

负载数据结构


如前所述,gRPC 默认使用 Protocol Buffers 来序列化负载数据。这个方案更轻便,因为它支持高度压缩的格式并减少了消息的大小。此外,Protobuf(或 Protocol Buffer)是二进制的;它对结构化数据进行序列化和反序列化,以便通信和传输。换句话说,强类型消息可以自动从 Protobuf 转换为客户端和服务器的编程语言。


相比之下,REST 主要依靠 JSON 或 XML 格式来发送和接收数据。事实上,即使它不强制要求任何结构,JSON 也是最流行的格式,因为它具有灵活性和发送动态数据的能力,而不必遵循严格的结构。使用 JSON 的另一显著优势是其人类可读水平,这方面 Protobuf 尚无法与之竞争。


尽管如此,JSON 在数据传输方面并不够轻量或快速。其原因在于,在使用 REST 时,必须将 JSON(或其他格式)序列化并转换为客户端和服务器端使用的编程语言。这在传输数据的过程中增加了一个额外步骤,从而可能会损害性能并增加出现错误的可能性。

代码生成功能


与 gRPC 不同,REST API 不提供内置代码生成功能,这意味着开发人员必须使用 Swagger 或 Postman 等第三方工具为 API 请求生成代码。


相比之下,gRPC 由于其 protoc 编译器而具有原生代码生成功能,该编译器与多种编程语言兼容。这对于集成了以不同语言和平台开发的各种服务的微服务系统来说尤其方便。此外,内置的代码生成器还有助于创建 SDK(软件开发工具包)。

gRPC 与 REST:对比表



何时使用 gRPC,何时使用 REST?


如前所述,尽管 gRPC 提供了许多优势,但它有一个主要障碍:浏览器兼容性低。因此,gRPC 的用例一般局限在内部/私有系统。


相比之下,正如我们所讨论的那样,REST API 可能有其缺点,但它们仍然是连接基于微服务的系统的最流行的 API。此外,REST 遵循 HTTP 协议标准化并提供通用支持,使这种 API 架构风格成为 Web 服务开发以及应用程序和微服务集成的首选。然而,这并不意味着我们应该忽视 gRPC 的应用场景。


gRPC 架构风格具有很多值得(并且应该)探索的有前途的特性。它是处理多语言系统和实时流的绝佳选择,例如,当运营需要轻量级消息传输(可以由序列化 Protobuf 消息支持)的 IoT 系统时,gRPC 就很合适。此外,gRPC 也可以考虑用于移动应用程序,因为它们不需要浏览器,且消息体积更小,不会拖慢移动设备的速度。

结论


gRPC 提供了很多优势。与 REST 不同,它可以充分利用 HTTP 2,使用多路复用流并遵循二进制协议。此外,由于 Protobuf 消息结构,它还具备性能优势,支持多语言环境的内置代码生成功能也是一大好处。这些因素使 gRPC 成为了一种很有前途的 API 架构风格。


尽管如此,浏览器支持不足使 gRPC 很难匹敌 REST 的通用支持能力。REST 仍然是微服务系统中的粘合剂,是最流行的解决方案。因此它很可能会存在很长时间,而且说实话,它是一个非常成熟和成功的架构。


原文链接:


https://www.imaginarycloud.com/blog/grpc-vs-rest/?fileGuid=3WQyP6YQDvcqhcXx

2021 年 6 月 15 日 15:426102
用户头像
王强 技术是文明进步的力量

发布了 641 篇内容, 共 239.4 次阅读, 收获喜欢 1400 次。

关注

评论 2 条评论

发布
用户头像
RPC or RCP ?

RCP

2021 年 06 月 25 日 11:18
回复
没有更多了
发现更多内容

Spring Boot 两行代码轻松实现国际化

Java架构师迁哥

⼤规模短⽂本聚类的设计和实践

百度Geek说

聚类 query 内聚

凡尔赛?拿到阿里offer只用了29天?

Java架构师迁哥

这几道面试题,难倒了牛客网98%的程序员,刷完后直接斩获9个大厂offer

Java架构师迁哥

Github又爆神作,阿里JVM垃圾回收全解小册全网开源!(算法+底层实现)

程序员小毕

Java spring 程序员 架构 算法

中寰-卜钢-采访提纲:车联网行业发展趋势

马踏飞机747

采访

Redis持久化方案介绍之RDB方案

大数据技术指南

redis 4月日更

skywalking dubbo agent 分析

kaiwen

【只要努力,方能成功。】四面字节跳动Java研发岗,成功斩获Offer。分享4面技术面真题及复习资料!

Java架构之路

Java 程序员 架构 面试 编程语言

iOS 面试策略之算法基础6-7节

iOSer

ios 面试 算法 ios开发 算法解析

罗美琪和春波特的故事...

阿里巴巴云原生

容器 开发者 云原生 开发工具 消息中间件

Fluid 给数据弹性一双隐形的翅膀 -- 自定义弹性伸缩

阿里巴巴云原生

大数据 容器 云原生 监控 弹性计算

想要写优秀的设计测试用例,不懂这个可不行!

程序员阿沐

软件测试 自动化测试 测试开发 测试用例 测试工程师

第一课作业纠正

杰语

疫情影响到底有多大?《2020年移动互联网报告》深度解读垂直行业变化趋势

Lily

从Map和Reduce角度谈Hive优化

五分钟学大数据

hive 4月日更 hive性能优化

留存率计算

Flychen

如何打造高效技术团队|专访前美篇首席架构师张超

穿过生命散发芬芳

调查采访能力考核

当时尚撞上区块链,为潮酷创意赋予专属“ID”

旺链科技

产业链

裸辞在家闭关修炼,意外发现一份据说是从阿里内部泄露出来的《Java程序员金三银四面试秘籍》

Java架构之路

Java 程序员 架构 面试 编程语言

用知识点+实例+项目完全深入地讲解springboot原理,这份《springboot实战派》火了!

Java架构之路

Java 程序员 架构 面试 编程语言

会议更流畅,表情更生动!视频生成编码 VS 国际最新 VVC 标准

阿里云视频云

阿里云 视频压缩 VVC

国产监控夜莺v4来了,大幅降低部署维护难度

运维散兵

Nightingale 滴滴夜莺

《专访阿里研究员吴翰清:大数据时代下,如何保障网络安全和用户隐私》(采访提纲)

三掌柜

调查采访能力考核

anyHouse-iOS 高仿ClubHouse

anyRTC开发者

ios 音视频 WebRTC RTC 语音通话

Disruptor 源码解读

lich0079

Java volatile Disruptor CAS Concurrent

全球案例 | 霍尼韦尔:Atlassian 帮助我们在疫情期间拯救生命

Atlassian

敏捷 Atlassian Jira 远程协作 霍尼韦尔

裸辞还可以吊打大厂面试官?四面拿到阿里、字节offer后我还是选择了美团!

Java架构师迁哥

点击量破百万!阿里内产微服务进阶讲义,简直是Java开发者的福音

Crud的程序员

Java 程序员 架构 微服务

[TcaplusDB知识库]TcaplusDB备份与回档机制介绍

TcaplusDB

数据库 nosql TcaplusDB NoSQL数据库

MySQL 表列数和行大小有哪些限制?

码农架构

MySQL 运维

数据cool谈(第2期)寻找下一代企业级数据库

数据cool谈(第2期)寻找下一代企业级数据库

gRPC vs REST:两种API架构风格的对比-InfoQ