好奇地想知道gRPC是否是未来的趋势？这篇文章旨在解释两种架构的API风格。REST和gRPC。在讨论它们的区别之前，我们将首先解释什么是API，以及为什么它对微服务基础架构至关重要。
之后，我们将描述RPC是如何成为gRPC的基础，并考虑gRPC和REST APIs之间区别的关键方面。考虑到它们的比较，我们最后将分析何时使用一种架构类型或另一种。
目录
了解什么是 API
➤API 和微服务
什么是 RPC？
什么是REST？
什么是 gRPC？
gRPC 与 REST：比较
➤HTTP 1.1 与 HTTP 2
➤浏览器支持
➤有效载荷数据结构
➤代码生成功能
➤gRPC 与 REST：比较表
何时使用 gRPC 与 REST？
结 论
了解什么是 API
API 是指应用编程接口。这些接口作为一个软件中介，为应用程序建立具体的确定和规则，以便相互之间进行交互和对话。API负责从用户到系统的响应，反过来又从系统发回给用户。这听起来还有点令人困惑吗？
让我们想象一下，我们正在预订一家酒店。我们在笔记本电脑上进入酒店预订页面，该页面--连接到互联网--向服务器发送数据（我们的请求）。反过来，服务器检索数据，解释它，然后，一旦所需的行动被执行，它就会向我们发送一个响应，其中包括我们界面上的信息。这个过程的发生要感谢API。
API规定了一个应用程序（网页或移动应用程序）可以向另一个应用程序提出的请求类型，并进一步规定了：如何提出这些请求；使用哪些数据格式；以及用户必须遵循的惯例。
本文比较了gRPC（谷歌远程程序调用）和REST（表示性状态传输），因为它们代表了创建API时最流行的两种架构风格。
API和微服务
一方面，在单体应用中，项目的所有功能都包含在一个单元中，更确切地说，是在一个代码库中。另一方面，微服务架构包括几个较小的服务，它们使用HTTP等协议相互通信。作为微服务架构一部分的组件服务通过API相互通信和互动。换句话说，API允许所有被整合到微服务应用程序的服务进行连接和通信。
最常用的架构风格是REST API。然而，在构建API时，有三种主要模式。RPC（远程过程调用）、REST（表示性状态传输）和 图形QL.在这篇文章中，我们将重点讨论前两种。
什么是RPC？
RPC使用客户端-服务器模型。提出请求的服务器（换句话说，客户端）请求一个消息，该消息由RPC翻译并发送给另一个服务器。一旦服务器收到请求，它就把响应发回给客户。当服务器在处理这个调用时，客户端被屏蔽了，服务器内部的消息传递被隐藏起来。
此外，RPC允许客户端以特定的格式请求一个函数，并以完全相同的格式接收响应。尽管如此，用RPC API提交调用的方法是在URL中找到的。RPC支持本地和分布式环境中的远程过程调用。
像REST API一样，RPC也建立了互动的规则，以及用户如何提交 "呼叫"（请求）来调用与服务沟通和互动的方法。
什么是REST？
当使用REST API时，来自后端数据的响应通过JSON或XML消息格式传递给客户（或用户）。这种架构模式倾向于遵循HTTP协议。然而，在保持RCP模式的同时，RCP设计也从HTTP中选择了一些想法，这并不罕见。事实上，大多数现代的API都是通过将API映射到相同的HTTP协议来实现的，尽管使用的是什么模型（RPC或REST）。
当REST API公开可用时，每个集成微服务应用的服务都可以作为资源呈现给用户/客户端，可以通过以下HTTP命令访问：GET,DELETE,POST, 和PUT 。
什么是gRPC？
gRPC是Google Remote Procedure Call的缩写，是基于RCP架构的一个变种。这项技术遵循RPC API的实现，使用HTTP 2.0协议，但HTTP没有呈现给API开发者，也没有呈现给服务器。因此，不需要担心RPC的概念如何被映射到HTTP，这就降低了复杂性。
总的来说，gRPC旨在使微服务之间的数据传输更快。它是基于确定服务的方法，建立方法和各自的参数，以实现远程调用和返回类型。
此外，它在IDL（接口描述语言）中表达了RPC API模型，提供了一个更直接的方式来确定远程程序。默认情况下，IDL使用协议缓冲区（但也有其他选择）来描述服务接口以及有效载荷消息的结构。
gRPC与REST：比较
现在我们对gRPC和REST有了一个概述，让我们看看它们的主要区别。
HTTP 1.1 vs HTTP 2
REST APIs遵循请求-响应的通信模式，通常建立在HTTP 1.1之上。不幸的是，这意味着如果一个微服务收到来自多个客户端的多个请求，该模型必须一次处理每个请求，从而导致整个系统变慢。然而，REST APIs也可以建立在HTTP 2的基础上，但请求-响应的通信模型仍然是一样的，这就禁止了REST APIs充分利用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 Buffer来序列化有效载荷数据。这个解决方案是比较轻的，因为它可以实现高度压缩的格式，减少消息的大小。更进一步。 Protobuf(或协议缓冲区）是二进制的；因此，它对结构化数据进行序列化和反序列化，以便进行通信和传输。换句话说，强类型的消息可以从Protobuf自动转换为客户端和服务器的编程语言。
相比之下，REST主要依靠JSON或XML格式来发送和接收数据。事实上，即使它没有规定任何结构，JSON是最流行的格式，因为它的灵活性和发送动态数据的能力，不一定要遵循严格的结构。 使用JSON的另一个重要好处是它的可读性水平，这一点Protobuf还无法与之竞争。
尽管如此，当涉及到数据传输时，JSON并没有那么轻巧和快速。原因在于，当使用REST时，JSON（或其他格式）必须被序列化，并转变成客户端和服务器端使用的编程语言。这在数据传输过程中增加了一个额外的步骤，从而损害了性能，并有可能出现错误。
代码生成功能
与gRPC不同，REST API不提供内置的代码生成功能，这意味着开发者必须使用第三方工具，如Swagger或Postman来生成API请求的代码。
相比之下，gRPC由于其protoc编译器与几种编程语言兼容，因此具有原生代码生成功能。这对集成了用不同语言和平台开发的各种服务的微服务系统特别有利。总而言之，内置的代码生成器也有利于创建SDK（软件开发工具包）。
gRPC与REST：对比表
| 特点 | gRPC | REST |
HTTP 1.1 vs HTTP 2 | 遵循客户-响应的通信模式，建立在HTTP 2之上，允许：流式通信和双向支持。 | 遵循请求-响应的通信模式，通常建立在HTTP 1.1上。 |
浏览器支持 | 有限的浏览器支持。gRPC需要gRPC-web和一个代理层来执行HTTP 1.1和HTTP 2之间的转换。 | 通用的浏览器支持。 |
有效载荷数据结构 | gRPC默认使用Protocol Buffer来序列化有效载荷数据。 | REST主要依靠JSON或XML格式来发送和接收数据。 |
代码生成功能 | gRPC具有本地代码生成功能。 | 开发人员必须使用第三方工具，如Swagger或Postman来生成API请求的代码。 |
什么时候使用gRPC与REST？
如前所述，尽管gRPC有很多优点，但它有一个主要障碍：浏览器兼容性低。因此，gRPC对于内部/私有系统来说有点局限。
相反，REST APIs可能有其缺点，正如我们已经讨论过的，但它们仍然是连接基于微服务的系统的最知名的API。另外，REST遵循HTTP协议的标准化，并提供普遍的支持，使这种API架构风格成为网络服务开发以及应用和微服务集成的最佳选择。然而，这并不意味着我们应该忽视gRPC的应用。
gRPC架构风格具有很有前途的功能，可以（也应该）加以探索。对于处理多语言系统、实时流来说，它是一个很好的选择，例如，在操作需要轻量级消息传输的物联网系统时，如序列化的Protobuf消息允许。此外，gRPC也应该被考虑用于移动应用，因为它们不需要浏览器，可以从较小的消息中受益，从而保持移动处理器的速度。
总结
gRPC提供了很多优势。与REST不同，它可以充分利用HTTP 2，使用多路复用流并遵循二进制协议。此外，由于采用了Protobuf消息结构，它还提供了性能上的优势，而且我们不要忘记内置的代码生成功能，它可以实现多语言环境。这些原因使得gRPC成为一种有前途的API架构风格。
尽管如此，浏览器的低支持率使得它在与REST普遍支持的竞争中面临挑战。REST仍然是微服务系统的粘合剂，是最流行的解决方案。因此，它极有可能长期存在，而且，说实话，它是一个非常完善和成功的架构。
