gRPC 与 REST

Posted 2023-03-04 crazy_itman

客户端/服务器架构、C/S架构，是一种分布式架构，它把客户端与服务器分割开来。每一个客户端软件的实例都可以向一个服务器或应用程序服务器发出请求。有很多不同类型的服务器，例如文件服务器、游戏服务器等。​主从式架构通过不同的途径应用于很多不同类型的应用程序，最常见就是目前在因特网上用的网页。例如，当你在维基百科阅读文章时，你的电脑和网页浏览器就被当做一个客户端，同时，组成维基百科的电脑、数据库和应用程序就被当做服务器。当你的网页浏览器向维基百科请求一个指定的文章时，维基百科服务器从维基百科的数据库中找出所有该文章需要的信息，结合成一个网页，再发送回你的浏览器。

流行的客户端-服务器架构将通信分为两部分： 

1. 服务器是承担所有繁重任务并提供服务的。

2. 客户端是享受这些服务的对象。

在一般的客户端-服务器通信中，客户端简单地向服务器发送请求资源或服务的请求，服务器响应该请求。

对于客户端-服务器通信，客户端和服务器需要有能够理解它们通信所用协议的库。协议是一种语言或一组互联网通信规则。它们是遵循一些准则的传输机制，用于通过 Internet 传输数据。

客户端通信的第二个最重要的方面是客户端和服务器都同意的消息格式。此消息格式基于某些模式，如果不遵循这些模式，就不会进行通信。消息格式可以类似于遵循模式的 XML，或包含特定键值对的 JSON 文件。

了解此类通信的另一个重要方面是它基于请求和响应机制，这意味着服务器仅在客户端发起通信时才进行通信。对于 REST 和 GraphQL，这主要是单向的。这是一个基本问题，将通过 gRPC 这样的技术来解决。

为什么 REST 应运而生？

在 20 世纪 90 年代初期，一种名为 SOAP 的流行客户端-服务器协议使用带有硬编码模式的 XML 消息格式。消息格式的架构非常严格。缺乏自由是导致 SOAP 被放弃和 REST 出现的原因。

由于 javascript 的日益流行，REST 应运而生，这导致了 JSON 文件格式的流行。它简单易懂且方便。它的消息格式中只有一些键值对。

简而言之，Rest 是使用 HTTP 作为其协议（传输机制）在 Internet 上传输 JSON 消息的指南。使用 Rest，无需担心制作模式。

什么是REST？

我们谈到了 REST 的出现。现在让我们深入探讨其核心技，REST 代表 Representational State Transfer。Rest是一种标准化的软件架构风格，是业界经常使用的API。

REST 流行和广泛使用的原因

• REST 是简单且标准化的通信架构。使用 REST 时，不必担心格式化消息或数据，不必每次都为的消息格式操心，因为它都是标准化的和行业使用的。

• REST 是可扩展的。假设服务变得更大并且需要更多功能，在这种情况下，可以轻松地改造服务器，而不必担心服务器的 REST 性能，并且可以完全隔离地创建新功能，除非它们弄乱了数据。

• REST 是无状态的。这意味着每个请求都会有一些服务器必须理解的数据。服务器的体系结构使服务器重新调用请求的信息。尽管如此，在 REST 架构中，会话状态存储在客户端，使服务器更高效，并为服务器提供更少的工作负载以实现更好的功能。

• 最后但同样重要的是，REST 是一种高性能架构并支持缓存。

何时使用 REST：

想象一下，你正在为一家餐馆制作一个网站。你有所有的在线菜单，食物分为三类：

1. 初学者

2. 主菜

3. 饮料

现在，假设想在线查看所有饮料。在 Rest 架构中，可以轻松且一致地对 API 端点上的所有资源进行分区。当然，你可以对它们使用多重身份验证来确保它们的安全。

在这种情况下，我们向服务器发送一个 GET 请求到一个我们可以获取饮料资源数据的端点。

同样，我们可以在Rest API中进行所有的CRUD（Create、Read、Update、Delete），这使得它适用于不需要超传输数据、不需要实时的大项目。

Rest 最适合高效数据传输是重要因素的项目。缓存是 REST 的另一个特性，它对食品预订应用程序、酒店预订应用程序、博客网站、在线论坛网站等标准应用程序很有用。

REST 的局限性和问题

REST 很棒，但它有很多缺点，在某些情况下这些缺点非常重要。让我们谈谈他们。

• 双向通信的需要。如果服务器需要向客户端发送一些数据怎么办？意思是服务器想要发起通信。在 REST 架构中，这是不可能的。当然，你可以使用一些技巧，但它们并不实用。

• 想象一下制作一个现场比分网站。你将如何管理服务器向客户端发送更新分数数据的请求？我们可以让客户端每 10 秒发送一次请求，但这根本不是一个好习惯。它会使服务器过载，这可能会导致速度问题。

• REST 架构纯粹是请求和响应，不支持数据流（连续事件处理）。

• 无状态的 REST 属性可以被认为是一种祝福和诅咒，因为你无法决定 REST 架构上数据的状态。

为什么 gRPC 应运而生？

为了解决 REST 的第一个问题，即双向通信的需要，发明了 WebSocket，它允许服务器发起通信。不过，它的问题是它没有格式。它只是发送字节，没有任何限制。

WebSockets 本身没有任何问题。尽管如此，实际问题仍然是任何类型的通信都需要一个协议，并且每个协议都需要一个可以使用该协议进行通信的客户端库。

如果你正在创建一个在 Rest 架构上运行的 Python 应用程序，你将需要一个可以与服务器通信的 HTTP 客户端。有时，客户端库是由第三方制作的，主要是独立开发人员。使用第三方库会暴露你的安全性，并且你的整个应用程序将依赖第三方进行通信。

对于 Web 应用程序，浏览器就像一个客户端库，但对于非 Web 项目，你将需要第三方客户端库。如果你正在考虑自己制作一个应用程序，请记住这并不容易，而且会因为维护另一个应用程序而加重自己的负担。

因此，为了解决 Rest 的一些问题和客户端库的问题，谷歌在 2015 年发明了 gRPC。

对于 gRPC，谷歌为几乎所有流行语言维护了一个客户端库。它在底层使用 HTTP 2 协议和协议缓冲区 (protobuf) 作为其消息格式。

无需担心任何客户端库，因为 Google 会为你和几乎所有编程语言维护它。然而，单一且集中的客户端库是 gRPC 的主要优势之一。

gRPC 的另一个好处是它使用的消息格式。此外，protocol buffer 与语言无关，因此可以在 Python 中创建客户端，在 Go 中创建服务器，并且仍然能够毫不费力地进行通信。

gRPC 本质上是一个客户端库和一种可以在任何设备上使用的协议。

什么是 gRPC？

gRPC 使用 protobuf 进行通信。它将proto文件序列化为二进制格式发送给服务器，在服务器端反序列化为原始格式。这就是它与 protobuf 一起工作的方式。

gRPC 有不同的通信形式，可以将它们视为 gRPC 的功能。

gRPC 的特点

1.单一请求

它是一种简单类型的请求-响应通信，其中客户端发送原始请求，服务器在收到请求后等待一段时间以执行某些过程，然后返回一些响应。

2.服务器流媒体

在发出单个请求时，大量数据作为来自服务器的响应。例如，当点击视频时，大量与视频相关的数据从服务器端涌入。

3.客户端流

对于服务器流，反之亦然。在这里，客户端一次向服务器发送大量数据。例如，当您在 Internet 上共享一个大文件或将图像或视频上传到 Internet 时，就会发生这种情况。客户端不断向服务器端发送数据。

4.双向流

在这种类型的通信中，客户端和服务器发送多条消息。聊天就是一个很好的例子。

gRPC 的四个流行特性使其如此强大。

何时使用 gRPC

至于 gRPC 的特性，我们看到了 gRPC 的一些用例。例如，假设你想制作一个聊天应用程序。你不会使用 Rest API，因为它无法允许双向通信的快速流式传输。为此，我们将使用 gRPC 流，这将提供速度以外的更多好处。

首先，它的语言中立行为与服务器或其他客户端正在编写的编程语言无关。在消息格式被接受之前，仍然可以建立通信。

因此，有了这个功能，android 版本的聊天应用程序可以与 ios 版本进行通信，反之亦然。

gRPC 的问题

一切都有问题，包括 gRPC。

有限的浏览器支持

gRPC 使用 HTTP 2，因此很难直接从浏览器调用 gRPC 服务。有时需要设置代理。

不可读形式

众所周知，gRPC 使用的是人类不可读的二进制格式。在某些情况下这是一个缺点。

缺乏成熟度

gRPC 是 2015 年开发的，所以相对于 REST 还有些不成熟，还有很多 bug 和问题需要解决。

学习问题

Rest 和 GraphQL 使用 JSON，它更容易学习。然而，大多数人会尝试坚持使用它们，因为 protobuf 仍然是一个新的复杂主题，因此很难找到 gRPC 专家。

休息与 gRPC

现在我们将讨论 REST 和 gRPC 之间的技术差异。

消息格式

REST 使用的消息格式主要是 JSON（有时是 XML 格式），这是一种可读性更好且更易于处理的形式。不必担心 Rest 中的模式。另一方面，gRPC 使用协议缓冲区来序列化数据。压缩形式更轻，携带起来更快。它是二进制格式，因此它对数据进行序列化和反序列化以进行传输。

HTTP 1.1 与 HTTP 2

Rest API 通常使用 HTTP 1.1 作为其协议，而 gRPC 使用 HTTP 2 作为其底层协议。Rest API 仍然可以使用 HTTP 2，但由于请求-响应机制仍然受到限制。gRPC 使用 HTTP 2 并利用 HTTP 2 支持客户端响应和双向通信。这是 gRPC 性能优于 REST 的另一个方面。它可以像 HTTP 1.1 一样管理单向请求，也可以像 HTTP 2 同时管理双向请求。

潜伏

gRPC 的低延迟和高速通信使其适用于连接由轻量级微服务架构组成的系统，从而提高消息传输效率。在网络的大多数情况下，REST 延迟需要 25ms，而 gRPC 延迟远低于 REST。

负载限制

在发送传出消息时，Rest 的最大负载限制为 45MB，而 gRPC 没有任何限制，这意味着你的传出消息可以随心所欲。

安全

在安全性方面，Rest 会有所滞后，因为它使用 HTTP 1.1 和易于解密和访问的 JSON 格式。另一方面，gRPC 使用安全得多的 HTTP 2，并使用二进制格式且难以解密的 protobuf。

速度

在这里，gRPC 再次获胜，因为它提供的速度是 Rest 的 10 倍，而且出于同样的原因，它使用 HTTP 2 作为协议，使用 protobuf 作为消息格式。

代码生成函数

Rest 不提供内置代码生成功能，这意味着开发人员需要第三方应用程序来生成 API 代码。相比之下，gRPC 由于其 protobuf 编译器而具有本机代码生成功能，该编译器与多种编程语言兼容。这是另一个好处，特别是对于微服务架构。

结论

最终，我想说的是，REST 仍然是使用最多、最流行的架构，放弃它是不可能的。当然REST也有很多缺点，比如没有数据流，没有双向通信，速度慢等等，但是最适合我们日常生活中看到的标准应用。

另一方面，gRPC 年轻难学，提供了很多东西，比如客户端和服务器端的高数据流，良好的双向数据流，快速紧凑，使用 HTTP 2。由于它的快速性能，gRPC 最适合高负载应用程序，如视频流、歌曲流、在线游戏、文件共享和聊天应用程序。