使用 Rust 构建 gRPC 服务器

弗洛里安·克鲁姆 ( Florian Krumm ) 在Unsplash上拍摄的照片

一旦我了解了gRPC和Thrift，就很难再回到使用更具过渡性的基于 JSON 的 REST API 或SOAP API 了。

两个著名的RPC框架 gRPC 和 Thrift 有很多相似之处。前者源自谷歌，后者源自Facebook。它们都易于使用，对多种编程语言都有很好的支持，并且都具有高性能。

最有价值的功能是多种语言的代码生成以及服务器端反射。这些使 API 本质上是类型安全的。使用服务器端反射，可以更轻松地 探索 API 的模式定义，而无需阅读和理解实现。

Apache Thrift在 历史 上一直是一个流行的选择。然而近年来，由于缺乏来自 Facebook 的持续支持，以及与fbthrift的分叉分叉，慢慢失去了人气。

与此同时，gRPC 已经赶上了越来越多的功能，拥有更 健康 的生态系统。

GRPC（蓝色）与 Apache Thrift（红色）的比较。谷歌趋势

gRPC、fbThrift 和 Apache Thrift 之间的 GitHub 明星 历史 。https://star-history.com

到今天为止，除非您的应用程序以某种方式隶属于 Facebook，否则没有充分的理由考虑 Thrift。

GraphQL是另一个由 Facebook 发起的框架。它与上面的两个 RPC 框架有很多相似之处。

移动 API 开发的最大痛点之一是一些用户从不升级他们的应用程序。因为我们想保持向后兼容性，我们要么必须在 API 中保留旧的未使用字段，要么创建 API 的多个版本。GraphQL 的一个动机就是解决这个问题。它被设计成一种“查询语言”，允许客户端指定它需要的数据字段。这使得处理向后兼容性变得更容易。

GraphQL 在开发移动 API 以及面向公众的 API（例如GitHub）方面具有巨大价值。因为，在这两种情况下，我们都无法轻易控制客户端的行为。

但是，如果我们正在为 Web 前端构建 API 或为内部后端服务构建 API，那么选择 GraphQL 而不是 gRPC 几乎没有什么好处。

以上是迄今为止网络框架的一个小概述。除了网络，我们还需要决定应用服务器的语言。

基于Stack Overflow 调查：“六年来，Rust 是最受欢迎的语言。” 尽管学习曲线相对陡峭，但它的类型安全、优雅的内存管理、广泛的社区支持和性能，都使 Rust 成为一种非常有吸引力和有前途的后端服务开发编程语言。

Rust 是最受欢迎的语言。2021 年 Stackoverflow 调查

我们也开始看到 Rust 在行业中得到越来越广泛的采用：Facebook、Dropbox、Yelp、AWS、Google等。很明显，Rust 将继续增长并继续存在。

这就是我们将在今天的教程中看到的内容——在 Rust 中使用 gRPC 构建一个小型服务器。

使用以下命令安装 Rust：

如果您以前安装过 Rust，我们可以通过以下方式对其进行更新：

让我们仔细检查rustc（Rust 编译器）和cargo（Rust 包管理器）的安装版本：

有关安装的更多信息，请查看https://www.rust-lang.org/tools/install。

运行以下命令创建一个新的“Hello World”项目：

让我们编译并运行程序：

这显示了我们到目前为止的文件结构：

gRPC 使用协议缓冲区来序列化和反序列化数据。.proto让我们在一个文件中定义服务器 API 。

我们定义了一个书店服务，只有一个方法：提供一个书本 id，并返回有关该书的一些详细信息。

我们将使用tonic创建我们的 gRPC 服务。将以下依赖项添加到Cargo.toml文件中：

为了从 生成 Rust 代码bookstore.proto，我们tonic-build在 crate 的build.rs构建脚本中使用。

将以下内容添加到build.rs文件中：

需要特别指出的一件事是，我们添加它.out_dir(“./src”)是为了将默认输出目录更改为该src目录，以便我们可以更轻松地查看生成的文件，以达到本文的目的。

在我们准备编译之前还有一件事。tonic-build依赖于Protocol Buffers 编译器将文件解析.proto为可以转换为 Rust 的表示。让我们安装protobuf：

并仔细检查 protobuf 编译器是否安装正确：

准备编译：

有了这个，我们应该src/bookstore.rs生成一个文件。此时，我们的文件结构应该如下所示：

最后，是时候将服务放在一起了。替换为main.rs以下内容：

正如我们所见，为了简单起见，我们并没有真正的图书设置数据库。在这个端点中，我们只是返回一本假书。

运行服务器的时间：

很好，我们在 Rust 中启动并运行了 gRPC 服务器！

正如开头所说，gRPC 最初给我留下了深刻的印象，因为它具有做服务器反射的能力。它不仅在服务开发过程中很方便，而且还使与前端工程师的沟通变得更加容易。因此，如果不解释如何为 Rust 服务器添加它，那么结束本教程是不完整的。

将以下内容添加到依赖项中：

更新build.rs。需要更改的行用// Add this注释标记。

最后，将其更新main.rs为以下内容。

有许多 GUI 客户端可以使用 gRPC Server，例如Postman、Kreya、bloomrpc、grpcox等。为了简单起见，我们将使用命令行工具grpc_cli。

安装：

并测试我们的第一个 gRPC 端点：

看起来它有效！我的朋友，这就是我们在 Rust 中构建 gRPC 服务器的方式。

这就是今天的内容。感谢阅读和快乐的编码！与往常一样，源代码可在GitHub 上获得。

grpc每个流只有一个grpc的数据帧，这个数据帧在传输的时候，会拆成多个http2的数据帧进行传输，然后在接受端，把所有http2的数据帧拼接成grpc的数据帧，再反序列化成请求的结构体。如果一次传输数据过大，在序列化和反序列化的时候，都会占用大量的cpu，不仅仅序列化，单纯的内存复制，也会占用大量cpu，而且，传输的时候，对带宽的影响也是很大的。因此，grpc不推荐一次传输大量数据，如果有大量数据要传输，则使用stream模式。【当然，grpc单次数据传输的大小限制是可以修改的，但是不建议你这么做】【默认最大消息大小为4MB

】

【不断修改增加服务端和客户端消息大小，每次请求不一定需要全部数据，会导致性能上和资源上的浪费】

【grpc协议层是基于http2设计的（但之前看一片测评文章，结构发现文件传输的时候速度有点慢，因为大量数据传输的场景瓶颈在于tcp，如果还在一个tcp上进行多路复用，那只会加剧锁竞争）】

【4 MB 的限制是为了保护没有考虑过消息大小限制的客户端/服务器。 gRPC 本身可以提高很多（100 MB），但大多数应用程序可能会受到轻微攻击或意外内存不足，从而允许该大小的消息。】

【grpc本质是为了提高单连接的利用率，如果单个stream上传输大量的数据，那么其他stream的数据就很难得到及时的传输，grpc适用于大量的请求，但是每次请求的传输数据量不大的情况】

【如果单次传输的数据量过大，建议从新开一个tcp连接，也就是用http1.1，因为在数据量很大的情况下，瓶颈在于底层的tcp】

【同理，在IM系统中，拉消息也建议使用http1.1的接口，避免占用大量的长连带宽，影响下行推送及时性】

【http1.1有维护连接池，每次请求都会独占一个tcp连接，所以，在传输大量数据的场景下，也不会影响到其他请求的数据传输，瓶颈在于机器性能】

grpc 连接池 https://github.com/rfyiamcool/grpc-client-pool

https://xiaorui.cc/archives/6001

---