gRPC的十年回顾：成功与挑战并存

  每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/

gRPC，高性能的RPC框架，对Google内部的成功贡献显著，并大幅改变了API的部署方式（当然，这主要是在Google内部）。gRPC和protobuf是极具性能优势的契约驱动框架，支持多种编程语言。不过，它也有一些不足。随着gRPC即将迎来十年使用里程碑，有必要回顾其可以改进的地方。

学习曲线

从最细微的地方说起。所谓的单一RPC是指客户端发送单个请求到服务器并获取单个响应。为什么gRPC要用这样一个非标准的术语，只有数学家才能直观理解？每次使用都要解释这个术语，真的很疲惫。

谈到单一RPC，其实现比实际需要的复杂。虽然gRPC的流功能很强大，但它给不需要流功能的简单RPC调用增加了复杂性。这妨碍了对gRPC调用的检查，因为现在每个单一RPC都有框架，而这种框架只对流功能有意义。protobuf编码已经够复杂了，所以不要再增加不必要的gRPC框架。此外，它不通过“发送一个cURL示例给朋友”的测试，对于任何Web API来说，都很难解释如何使用gRPC。“服务器反射启用了吗？”这个问题已经问了无数遍，真是让人厌烦。

这种复杂性也延伸到工具上，强制性的代码生成步骤是一个障碍，尤其是对于重视运行时灵活性的动态语言。许多开发者可能会对需要额外的构建步骤感到犹豫。现代Web开发已经需要20多个构建步骤了，有时真的很难再增加一个。

与Web的兼容性

依赖HTTP/2最初限制了gRPC的普及，因为并非所有平台和浏览器都完全支持它。尽管情况有所改善，但在某些环境中仍然是个挑战。而即使有HTTP/2支持，浏览器也避免添加处理HTTP尾部的方式，因此浏览器今天仍然无法使用“原始”gRPC。gRPC-Web作为这个问题的补救措施，通过避免使用尾部解决了问题，但通常需要运行支持gRPC-Web的代理，这很烦人。

HTTP/3的延迟采用

推迟采用HTTP/3可能妨碍了gRPC充分利用该协议的性能和效率优势。亲身经历过HTTP/2的阻塞问题，使用HTTP/3本可以彻底解决这个问题。令人费解的是，一个推动多种语言支持HTTP/2的框架，却在HTTP/3上举步维艰。

JSON映射和Prototext

另一个“时机”错误的地方是早期缺乏标准化的JSON映射。这让习惯于JSON的开发者难以接受gRPC，并且这种刻板印象似乎从未消除。protobuf类型与JSON的映射简化了与现有工具和系统的集成和互操作。告诉Web开发者“这是一个超级高效的二进制格式，但你可以设置一个标志来获得JSON以便调试”，他们会非常兴奋。不合理地兴奋。现在protobuf有了标准的JSON映射规则，protobuf文本格式显得多余了。没有了JSON，文本格式就失去了用武之地。大家都忘掉它的存在吧，行吗？

有限的消息大小

大多数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;
}

这在Protobuf中定义很简单，但实际实现却可能繁琐且易出错。虽然Google为其API找到了解决方案，但缺乏标准化方法导致其他人不得不重新发明轮子。

有人可能会想“Google在大多数API中使用gRPC，所以他们肯定解决了这个问题”，确实如此。他们实际上有一个gRPC和HTTP版本来下载（可能很大）文件。比较这两个版本，gRPC要复杂得多。

社区活动匮乏

许多gRPC/protobuf社区缺乏活动，这可能给人一种gRPC停滞或维护不积极的印象。这可能会阻碍潜在用户并导致社区增长缓慢。这可能是选择太多，难以找到gRPC爱好者的结果，除非在GitHub问题中，否则这种热情可能被认为是烦人的。

工具不完善

长期以来，当看到一个代码库使用protobuf时，通常会发现一个奇怪的脚本，以超级自定义的方式下载随机protobuf文件，并将其放置在随机路径，然后进行一系列复杂的protoc调用。只有Google才会认为不解决依赖管理是解决依赖管理的方法。Google有他们自己非常Google化的依赖管理方式，而我们只能梦想使用。

可以（并且确实）变得更好

虽然对gRPC有批评，但希望这些评论是建设性的。读到这里的人应该知道，很多问题已经解决或正在解决！

• 许多gRPC实现已经支持HTTP/3。ConnectRPC使使用HTTP/3与gRPC变得相当容易（将在未来的文章中详细讨论）。
• 由于protobuf规范有了JSON的规范映射，不再需要担心文本格式。真的希望大家忘记它的存在。文本格式太多了。这是最后一次提及它。
• gRPC社区实际上很活跃，只要知道在哪里寻找。例如，buf slack对我来说是一个很好的资源，经常会看到我在那里回答问题。
• Buf CLI是gRPC的一个神奇工具。它完全取代了protoc，还增加了代码检查、破坏性变更检测、gRPC的curl、与Buf Schema Registry的集成（哇，真正的依赖管理！）等等。此外，更多你熟悉和喜爱的HTTP工具也在支持gRPC，如Postman、Insomnia和k6。

尽管gRPC取得了不可否认的成功，但承认框架的不足对于确保其持续演进和改进至关重要。通过解决学习曲线、兼容性问题、标准化缺失和社区参与等问题，可以释放gRPC的全部潜力，使其成为所有开发者更易用、更友好的工具。