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

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

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

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。

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

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

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

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

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。

发布 Vue3 让尤雨溪吃尽苦头：犯了3个错，每一个都需开发者警惕

阿里被判向京东赔偿10亿；要求销毁 ChatGPT，微软和 OpenAI被起诉；阿里云大调整：混合云部分团队裁员30%｜Q资讯

80 岁 Postgres 创始人、数据库领域“祖师爷”想颠覆数据库设计：不推翻下当前技术，不足以谈人生