gRPC 与 REST：优缺点和技术比较

在本文中，我们将研究两种 HTTP 通信协议和 API 设计之间的高级方法；gRPC 和 REST。

大多数开发人员都非常熟悉 REST，这是因为 REST 在世界上主要使用，并且在教授 HTTP 编程的初学者教程中也使用它。因此，默认情况下，新开发人员会熟悉 REST。

大多数关于编程语言或框架（如 Reactjs、Angular、PHP 等）的教程在教授客户端-服务器通信时都使用 HTTP。gRPC 很少被使用或提出，因此 gRPC 变得未知，当开发人员开始深入研究 HTTP 通信时，它就会被挖掘出来。

因此，我们将在这篇文章中介绍 REST 和 gRPC，以解释它们的好处及其工作原理。

REST 概述

REST（REpresentational State Transfer 的缩写）是一种架构风格，旨在帮助创建和组织分布式系统。这一切都始于 2000 年的 Fielding，他致力于开发一种独特的客户端-服务器通信标准化方法。

REST 使用 HTTP 协议进行通信，它被广泛用于 Web 应用程序中。REST 只是为高层架构实现提供了关于后端数据如何通过 JSON/XML 消息格式提供给客户端的指南。

API 使用 REST 指南来提供可供使用的 Web 服务。REST API 在所谓的资源中提供这些 Web 服务。资源代表服务器中的单个状态，可以通过通用接口访问，然后可以通过 HTTP 动词获取或操作：GET、POST、DELETE 和 PUT。

如果系统满足以下约束，则系统被视为 RESTful：

客户端服务器

此约束要求客户端和服务器必须独立运行。服务器不应该依赖客户端运行，客户端也不应该依赖服务器。

服务器包含服务器代码并通过 URL 向公众公开端点。API 端点通常使用 Swagger 等工具发布在 API 文档中。

另一方面，客户端知道 API 端点并调用它们以完成服务并获得响应。

这在开发两个系统时提供了很大的灵活性，而不会相互影响。

根据Fernando Doglio 在 Node.js REST API 开发中的说法：

这种约束背后的主要原则是****关注点分离****。它允许
将前端代码（信息的表示和可能的 UI 相关处理
）与服务器端代码分离，服务器端代码应负责数据的存储和服务器端处理。

客户端只知道 API 并调用它们，而无需知道它们是如何工作的。服务器服务是独立开发的，它们只是在负载上提供客户端可以调用的接口。

无国籍

此约束适用于服务器不得保存有关客户端请求的数据。通信必须是无状态的，每个请求必须包含服务器的所有信息。
客户端负责将状态数据保存在其存储中。

这种约束使系统高度可见且易于检查和调试，因为需要知道的一切都在请求中，而且系统具有高度的可扩展性和可靠性。

可缓存

此约束提高了服务器和客户端的性能。

在服务器中，可以缓存影响服务器 CPU 的高配置服务，例如处理图像、计算巨大数字序列等的服务，这种缓存使其只运行一次并缓存结果，然后在后续调用中使用到服务，它从缓存中返回结果。其他东西可以缓存，例如数据库请求可能会变得冗长，结果可以缓存以备将来的请求。

在客户端，高配置会因高加载时间而导致性能问题。

可能会有对状态数据和其他数据的抱怨，可以通过使用缓存控制、max-age 和到期时间来缓解。

这种可缓存的约束使系统具有高性能。

统一界面

此约束涉及使 API 接口与客户端统一。必须提供 API 接口，以便服务的消费者可以通过 API 接口调用服务。

接口是公开可用的点，因此世界可以与您的资源或服务进行通信。没有接口，消费者就无法使用服务器中的服务。

它就像一个执行特定工作的库，工作的实现，即工作是如何完成的，都包含在其中。库必须公开消费者可以用来执行操作的函数/方法。如果库不公开函数/方法，我们就无法使用库。

分层系统

服务器可以有不同的层，例如我们可以有业务逻辑层、存储层、会话管理层等。

此约束声明系统必须分层，以便允许在不同的服务器上维护不同的组件。

这些层仅与下面的层通信以获取其输入并使用它来将其输出传达给它上面的层。

通过将组件分层，我们使服务器更加灵活，并且在需要时非常易于维护和扩展。

点播代码

此约束是可选的。它涉及客户端能够从服务器获取可执行代码并执行它。

这是非常不必要的，因为客户端需要做的就是从服务器获取信息并对其进行处理，但是在客户端是浏览器的情况下，它必须下载 JavaScript 代码，该代码可以使其能够处理未来来自服务器的信息。

REST 架构的构建块是一种资源。一切都可以成为资源，这取决于服务器将提供的服务。这些资源是通过使用 HTTP 方法的公共接口访问的。

HTTP 动词可用于引用对资源执行的操作类型。

• GET 以只读模式访问资源。
• POST 创建一个新资源。
• PUT 更新给定的资源。
• DELETE 移除或删除资源。

如果我们有一个产品资源，我们将对该资源执行以下类型的操作：

• /products GET：获取所有产品
• /products/:id GET：获取由 id 指定的给定产品。
• /products:id DELETE：删除给定的产品。
• /products:id PUT：编辑给定的产品。
• /products POST：创建一个新产品。

gRPC 概述

gRPC是构建在 RPC 协议之上的最新框架。

gRPC 是一种进程间通信，允许连接到分布式应用程序并调用应用程序中的本地方法/函数。

简单的说，gRPC 是 RPC 的扩展。在 RPC 中，想法是调用或调用远程函数/方法。函数可以托管在某处的远程服务器上，并且可以从另一个远程服务器或客户端机器调用，而不必托管在同一台服务器上。

在开发 gRPC 应用程序时，定义了一个服务接口。此服务接口包含可以使用其参数和返回类型远程调用的方法。此服务接口还包含调用这些方法时将使用的消息格式、方法的参数和返回类型。

所以基本上，服务定义接口包含消息和方法框架或结构。

有了这个接口，服务端服务就可以实现这个接口，提供底层的代码逻辑。服务器将提供处理客户端调用的方法。

在客户端，客户端也会使用这个接口来远程调用函数。gRPC 框架抽象了所有复杂性，例如数据序列化、网络通信、身份验证、访问控制等。用户对通信是如何发生的一无所知。

根据我们上面所说的，我们可以推断出 gRPC 服务具有三个组件：

• 服务器
• 服务定义接口
• 客户端

gRPC 服务器可以在任何环境下运行，客户端也是如此，它可以在任何环境中运行，并且它们都可以用 gRPC 框架支持的不同语言编写。

gRPC 服务器可以用 Java 构建，客户端可以用 JavaScript 构建，它们可以无阻碍地运行和相互通信。gRPC 服务器可以用 C++ 编写，而客户端可以用 Go 编写，它们可以相互通信。这就是 gRPC 在许多应用程序中主要受青睐的原因，因为它们是多语言的。

gRPC：协议缓冲区

服务定义接口是使用协议缓冲区定义的。

Protocol Buffers 是由 Google 构建的开源数据序列化工具，用于描述数据结构并生成表示数据的字节流。

gRPC使用此协议缓冲区作为 IDL（接口定义语言）和消息交换格式。这意味着 gRPC 使用协议缓冲区来定义其服务器要公开的方法，例如

service ProductService {
    addProduct() returns () {}
    removeProduct() returns () {}
    getAllProducts() returns () {}
}

上面是一个 proto 文件，它定义了三个将被客户端公开和调用的方法。

作为一种消息格式，它定义了类型，就像我们在静态类型语言中一样，我们定义类型来显示类、函数或方法将作为 arg 返回、使用或接收的数据的形状。所以在协议缓冲区中，这就是消息传递格式的作用。

message ProductRequest {
    string id = 1;
}

message ProductResponse {
    string name = 1;
}

service ProductService {
    addProduct(ProductRequest) returns (ProductResponse) {}
}

带有消息的对象是服务器和客户端使用的类型和消息格式。addProduct 方法必须使用 ProductRequest 数据结构调用，并且它必须返回 ProductResponse 数据结构。因此，响应客户端类的服务器和调用该方法的客户端都必须遵循 ProductResponse ProductRequest 格式。

gRPC 使用 HTTP/2 进行调用和通信。这允许用户执行传统的请求-响应类型的调用，它还可以执行单或双（双向）流。

比较和对比：REST/gRPC

我们已经看到了 REST 和 gRPC 的概述，现在我们可以比较和对比这两种 HTTP 协议。

让我们来看看 gRPC 和 REST 之间的区别。

Protobuf 与 JSON

gRPC 和 REST 接收响应的格式不同。

REST 使用 JSON 格式接收消息。虽然我们可以接收 XML、原始二进制格式等格式的消息，但最佳实践和教程使 JSON 成为规范，而且由于 JSON 灵活、高效、平台中立且与语言无关。

gRPC 使用 Protobuf 消息格式以消息二进制格式发送请求和接收响应。

JSON 和 Protobuf 都与平台无关，这意味着它们可以被开发和使用，而与所使用的平台无关。

JSON 在系统之间传输时速度较慢。Protobuf 消息传递速度更快，因为消息包在通过网络发送之前被编组。编组是将参数和远程函数打包成消息二进制包的过程。

HTTP/1.1 与 HTTP/2

REST 在通信以及发送请求和接收响应中使用 HTTP/1.1。gRPC 使用 HTTP/2，这对于进程间通信来说甚至更快。

HTTP/1.1 比 HTTP/2 慢。HTTP/2 旨在改进 HTTP/1.1 的局限性。这使得 gRPC 在请求-响应方面比 REST 更快。

REST 在多路复用方面缺乏更多。REST 一个接一个地加载资源，一个资源必须等到前一个资源加载完成。gRPC 使用 HTTP/2，它使用 TCP 连接发送多个数据流，这些数据被拆分为二进制代码消息并为消息编号，以便客户端知道每个二进制消息属于哪个流，从而确保没有资源被阻塞.

所以我们看到，HTTP/1.1 对于多个请求是低效的。

通过服务器推送和标头压缩，gRPC 的 HTTP/2 仍然比 REST 的 HTTP/1.1 提高了性能排名。服务器推送允许 HTTP/2 在请求之前将内容从服务器推送到客户端，而 HTTP/1.1 无法做到这一点，服务器仅在请求时提供内容。Header 压缩要求 HTTP/2 能够使用 HPACK 压缩方法从 Header 中删除不必要的消息。

流媒体与请求/响应

在 REST 中，我们只能执行请求并获得响应之类的东西。这是由于它用于通信的 HTTP/1.1 协议在事物的各个方面都非常有限。

另一方面，正如我们所知，gRPC 使用 HTTP/2 进行通信。使用 TCP 连接，HTTP/2 支持来自服务器的多个数据流以及传统的请求-响应。

使用 gRPC，我们可以执行：

• 客户端流：这涉及客户端向服务器发送数据流。服务器注册以接收来自客户端的数据流，然后发送一条消息作为响应。
• 服务器流：客户端向服务器发送一个单曲，服务器将打开一个流连接，并随着时间的推移向客户端发送数据流。当流到达时，客户端将注册一个要注意的事件。
• 双向流：这是双向的。服务器和客户端可以相互发送和接收数据流。

优点：gRPC/REST

让我们看看事情的光明面：

gRPC 优势

让我们列出 gRPC 的一些优点

• 它是多语种
• 它有双工流
• 它是强类型的。
• 它与平台无关
• 它使用 HTTP/2，这是对传统 HTTP 1.1 的升级

休息优势

• 它帮助我们构建高度灵活的系统。
• 它帮助我们构建具有高可见性的高度可扩展的系统。
• REST 更易于使用且学习速度更快。

底线

没有哪个比另一个更好，但从表面上看，我们可以得出结论，gRPC 非常适合大型分布式应用程序。gRPC 的一个缺点是它不是那么受欢迎，所以没有多少初学者教程可以让开发人员直接使用它而无需四处乱搞，而且大多数浏览器不支持 gRPC，因此我们必须使用代理工具，例如Envoy帮助我们将请求从浏览器代理到 gRPC 服务器。

REST 仍然很棒，并且被世界各地的公司和开发人员广泛使用。此外，大多数新技术自然支持，这使其成为开发人员和军团的首选。gRPC 被视为未来，因为它使用的技术和技术带来的好处。

那么gRPC over REST？不，我认为您选择了您的用例需要的那个