LinkedIn 解释为什么选择用 gRPC+Protobuf 替代 Rest.li+JSON

作者 | Rafal Gancarz

译者 | 明知山

策划 | 丁晓昀

LinkedIn 宣布将转向使用 gRPC 和 Protocol Buffers 作为其微服务平台的服务间通信，之前主要使用开源的 Rest.li 框架，以 JSON 作为主要的序列化格式。

InfoQ 采访了 LinkedIn 杰出工程师Karthik Ramgopal和首席工程师Min Chen，了解了这一决定背后的主要原因和动机。

InfoQ：放弃 REST 和 JSON 转而选择 gRPC 和 Protocol Buffers 的主要原因是什么？

Karthik Ramgopal/Min Chen：我们选择使用 gRPC 替换当前的 REST 框架 Rest.li， 主要基于以下原因：

• 优越的功能——gRPC 是一个功能强大的框架，支持一些高级功能，如双向流、流量控制和截止时间，而这些是 Rest.li 不支持的。

• 效率——gRPC 也是一个高效的框架，其实现中融入了性能优化，比如完全异步非阻塞绑定和先进的线程模型。我们通过合成基准测试以及并行运行 gRPC 和 Rest.li 服务验证了这一点。

• 多语言支持——Rest.li 主要用 Java 实现，对其他编程语言支持不全或者根本不支持。gRPC 对多种编程语言提供了高质量的支持，考虑到 LinkedIn 的底层支持需求，这一点很重要。

除了这些原因，gRPC 背后还有一个庞大而活跃的开源社区，并在行业中得到了广泛应用。Rest.li 虽然是开源的，但主要由 LinkedIn 参与贡献，主要使用者也是 LinkedIn。

InfoQ：你们之前在 Rest.li 框架中采用 Protocol Buffers 作为序列化格式。你们从中学到了什么？还评估了哪些其他的序列化格式？

Karthik Ramgopal：我们已经在博文中详细介绍了这些，我们的主要收获是了解到，从 JSON 转换为 Protobuf 可以在大规模场景下显著降低延迟并提高吞吐量。除了 Protobuf 外，我们还评估了 CBOR、MessagePack、SMILE)、Avro、Kryo、Flatbuffers 和 Cap’n’Proto 等其他序列化格式。最终我们选择了 Protobuf，因为它在运行时性能（延迟、数据量大小、吞吐量）、开发者体验（IDE 编写、模式验证、注解支持等）、以及多语言 / 环境支持方面提供了最佳的平衡。

InfoQ：你们在 Rest.li GitHub 页面** 宣布该框架将不再继续开发并将被弃用。你们对当前框架的用户有什么建议？

Karthik Ramgopal/Min Chen：考虑迁移到 gRPC。如果需要迁移指南，请通过 LinkedIn 联系我们。

InfoQ：你们在博文中提到一些服务的延迟改善达到了 60%。你们能否提供更详尽的细节？

Karthik Ramgopal：延迟的改善主要来自于更小的数据载荷和序列化 / 反序列减少对 CPU 时间的占用。60% 这个数字是针对具有非常大且复杂数据载荷的服务，在这些服务中，这些成本是导致延迟的主要因素。我们还注意到使用 Protobuf 时，许多服务的尾部延迟（p95/p99）也有了显著改善，主要是因为减少了垃圾回收。

InfoQ：你们也提到 LinkedIn 目前在生产环境中有超过 50000 个 Rest.li 端点。这是一个惊人的数字，你么能解释一下为设么有这么多端点吗？

Karthik Ramgopal：作为最大的专业人脉网络之一，我们有着复杂的“经济图谱”实体。其中，我们的企业业务（如 Recruiter、LinkedIn Learning、Sales Navigator 等）拥有各自的实体。另外，我们还有内部应用程序、工具系统等。此外，我们通常采用三层架构，包括 BFF（Backend For Frontend）、中间层和后端。我们鼓励采用基于 CRUD 的建模方式，使用规范化实体进行标准化建模。在过去的 10 年中，所有这些用例都是通过 Rest.li 进行建模的，这解释了为什么会有那么多端点。

InfoQ：采用 gRPC+Protobuf 的主要目标 / 原因是什么？LinkedIn 是否正在进行或计划开展其他支持类似目标的项目？

Karthik Ramgopal/Min Chen：采用 gRPC+Protobuf 的原因与我们选择 gRPC+Protobuf 而不是 REST+JSON 的目标保持一致。

我们正在将所有有状态存储和流式处理系统从 Avro 迁移到 Protobuf。我们也在将一些通用基础设施功能（如授权、调用追踪、日志记录等）从 Java 库移至 Sidecar，并通过 UDS（Unix Domain Socket）提供 gRPC API，以降低多语言支持的成本。我们还在改进我们的内部服务发现和负载均衡器，采用工业标准的 xDS 协议，以适配 gRPC xDS SDK 和 Envoy Sidecar。

查看英文原文：

https://www.infoq.com/news/2023/12/linkedin-grpc-protobuf-rest-json/

声明：本文由 InfoQ 翻译，未经许可禁止转载。