编辑 | 言征
出品 | 51CTO技术栈（微信号：blog51cto）
gRPC 是一种高性能 RPC 框架，它取得了巨大的成功，并且彻底改变了我们部署 API 的方式。gRPC 和 protobuf 是一种性能极高的以契约为中心的框架，具有极其广泛的语言支持。但它并非没有缺点。制作一个需要代码生成和多种编程语言支持的 RPC 框架肯定会出错。随着 gRPC 的使用时间接近十年，反思哪些方面可以做得更好是很重要的。
1.学习曲线
让我们从极其挑剔开始。所谓的一元 RPC 是指客户端向服务器发送单个请求并收到单个响应的调用。为什么 gRPC 必须使用这样一个只有数学家才直观理解的非标准术语来表示这一点？每次使用这个术语时，我都必须解释一下。我有点厌倦了。
说到一元 RPC，其实现比它需要的更复杂。虽然 gRPC 的流式传输功能很强大，但它们为不需要流式传输的简单 RPC 调用引入了复杂性。这损害了检查 gRPC 调用的能力，因为现在每个一元 RPC 上都有框架，而这只对流式传输有意义。Protobuf 编码已经足够复杂了，所以我们不要在不需要的地方添加额外的 gRPC 框架。此外，它没有通过我对任何 Web API 的“向朋友发送 cURL 示例”测试。向某人解释如何使用 gRPC 实在是太烦人了。我已经说过“好的，但是服务器反射启用了吗？”很多次了。我只是厌倦了。
这种复杂性还通过强制代码生成步骤渗透到工具中。这可能是一个障碍，尤其是对于重视运行时灵活性的动态语言。此外，一些开发人员可能不愿意采用需要额外构建步骤的技术。现代 Web 开发已经需要 20 个构建步骤，有时很难再增加一个步骤。
图片
2.与 Web 的兼容性
对 HTTP/2 的依赖最初限制了 gRPC 的覆盖范围，因为并非所有平台和浏览器都完全支持它。这种情况随着时间的推移有所改善，但在某些环境中仍然构成挑战。但即使有了 HTTP/2 支持，浏览器也避免添加处理 HTTP 尾部的方法，因此今天的浏览器仍然无法使用“原始” gRPC。gRPC-Web 通过避免使用尾部充当了这个问题的膏药，但它通常需要“额外的东西”，比如运行支持 gRPC-Web 的代理。这很烦人。
HTTP/3 的采用较晚：HTTP/3 的采用延迟可能阻碍了 gRPC 充分利用该协议的性能和效率优势。我个人受到将 gRPC 与 HTTP/2 结合使用时可能发生的队头阻塞问题的影响，如果能够将 HTTP/3 与 gRPC 结合使用，可以完全消除此问题，那就太好了。看到一个推动多种语言支持 HTTP/2 的框架在努力用 HTTP/3 做同样的事情，真是奇怪。
3.JSON 映射和 Prototext
另一个“时机”不对的领域是早期缺乏标准化的 JSON 映射。这让习惯于基于 JSON 的 API 的开发人员更难使用 gRPC，而且我认为它从未从这种污名中恢复过来。在 protobuf 类型和 JSON 之间建立映射简化了与现有工具和系统的集成和互操作性。当你说“是的，这是一种超高效的二进制格式……但如果你想调试，你可以设置这个标志并取回 JSON”时，你不会相信 Web 开发人员会有多高兴。他们会兴奋得不得了。太兴奋了。无论如何，既然 protobuf 有了将 protobuf 类型映射到 JSON（反之亦然）的标准规则，我觉得protobuf 文本格式是一种不必要的复杂性。既然有了 JSON，我看不到文本格式的用例。所以让我们抛弃文本格式吧。我们不需要它，如果其他人都不需要它，我愿意假装它从未存在过。很酷吧？
4.有限的消息大小
大多数 Protobuf 编码器/解码器都希望完全解析整个消息并向消费者提供完整的响应，但内存是有限的，有时您可能需要更大的消息。有时您希望将这些较大消息的部分流式传输到其他地方，而不是将整个消息保存在内存中。因此，如果您想要上传大文件，您将需要实现某种分块。虽然分块是处理大文件的合理解决方案，但 gRPC 中缺乏标准化方法可能会导致实现不一致并增加开发工作量。
作为演示，使用 gRPC 上传文件如下所示：
syntax = "proto3";
package file_service;
service FileService {
rpc Upload(stream UploadRequest) returns(UploadResponse);
}
message UploadRequest {
string file_name = 1;
bytes chunk = 2;
}
message UploadResponse {
string etag = 1;
}5.协议缓冲区
这是 protobuf 的优点，也是缺点。这个概念在 protobuf 中非常容易定义，但在实践中，正确实现它的代码可能很麻烦且容易出错。虽然 gRPC 的创建者 Google 已经为他们的 API 找到了解决方案，但缺乏标准化方法使得其他人只能重新发明轮子。
你可能会想“Google 在其大多数 API 中使用 gRPC，因此显然他们已经这样做了”，您是对的。他们实际上有一个用于下载（可能很大的）文件的 gRPC 和 HTTP 版本。我们可以直接比较 gRPC 和 HTTP 版本，并且gRPC到目前为止要复杂得多。继续比较链接的代码。我会等待。
6.互联网理论
我看到很多 gRPC/protobuf 社区都缺乏活动。一些网站上缺乏可见的活动可能会给人留下 gRPC 停滞不前或维护不积极的印象。这可能会阻碍潜在的采用者并导致社区增长放缓。这可能是因为选择太多，很难在 GitHub 问题之外找到对 gRPC 感兴趣的人，因为这种热情可能会被视为烦人。
7.糟糕的工具
很长一段时间以来，当我看到代码库使用 protobuf 时，我都会发现一个奇怪的脚本，它以超级自定义的方式下载随机的 protobuf 文件并将它们放置在随机路径中，然后对进行一系列超级复杂的调用protoc。只有谷歌会认为不解决依赖管理就是解决依赖管理问题的办法。谷歌有自己非常谷歌式的管理依赖的方式，我们这些农民只能梦想着使用。
- 当生活给你锤子时，就把它变成锤子吧。
- 它可以更好（而且确实更好）
虽然我一直批评 gRPC，但我希望我的评论能起到建设性的作用。读到本文末尾的人会知道，其中许多问题已经得到解决，或者至少正在得到解决！
一些 gRPC 实现已经支持 HTTP/3。ConnectRPC 使得使用 HTTP/3 和 gRPC 变得非常容易（我将在以后的文章中继续介绍这一点）。
由于protobuf 规范具有与 JSON 的规范映射，我不再需要担心文本格式。我真的希望每个人都忘记它的存在。文本格式的空间有限。我不是开玩笑。这是我最后一次承认它的存在。
如果您知道该去哪里找，gRPC 社区实际上非常活跃。例如，buf slack对我来说是一个很好的资源。您可能会发现我经常在这里闲逛并回答问题。
Buf CLI是一款出色的 gRPC 工具。它protoc不仅完全替代了 gRPC 的 linting、重大更改检测、用于 gRPC 的 curl、与 Buf Schema Registry 的集成（哇，真正的依赖管理！），而且还添加了更多功能！此外，您熟悉和喜爱的 HTTP 工具也支持 gRPC，例如Postman、Insomnia和k6。
尽管 gRPC 取得了不可否认的成功，但承认该框架的缺点以确保其持续发展和改进仍然很重要。通过解决其学习曲线、兼容性问题、缺乏标准化和社区参与，我们可以释放 gRPC 的全部潜力，使其成为所有开发人员更易于访问和用户友好的工具。
