使用 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官方介绍（ https://www.grpc.io/docs/what-is-grpc/introduction/ ）如下：

gRPC是一个能在不同语言不同平台中进行高效通信的服务。gRPC默认使用Protocol Buffers数据格式：

Protocol Buffers以.proto作为拓展名，是一系列以name-value键值对的形式存储的数据格式。

Protocol Buffers从开源到现在已经经过很长时间，目前已经到了proto3版本，有着更加简化的语法，更加有用的特性，能够支持更多的语言。你可以从 proto3 language guide 和  reference documentation 看到更多有用的东西。另外.proto的文件格式能够从 formal specification 获取到更详细的讲解。

每个参数带有一个唯一的标识符，这些标识符被用来在message的二进制中被识别出来。不是代表每个数据的数值。

有了gRPC，我们可以在.proto文件中定义我们的服务，并用gRPC支持的任何语言生成客户端和服务器，它可以在从大型数据中心内的服务器到您自己的平板电脑的各种环境中运行，不同语言和环境之间的所有复杂通信都由gRPC为您处理。我们还获得了使用协议缓冲区的所有优点，包括高效的序列化、简单的IDL和容易的接口更新。

声明定义proto使用3版本，如果不生命默认2版本号。

在proto文件中定义java_package，指定了我们要用于生成的Java类的包。如果.proto文件中没有显式的java_package选项，那么默认情况下将使用proto包（使用“package”关键字指定）。

使用service定义服务。然后在service中使用rpc方法定义，gRPC允许使用4种不同的定义方式，定义方法。

区别在客户端调用Grpc中Stub发送请求方法时：

可以使用message定义所有的request and response types，在service中使用到的数据格式。

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

---