扫码阅读
手机扫码阅读

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

64 2024-07-04

LinkedIn 迁移到 gRPC 和 Protocol Buffers 的决策背景

LinkedIn 已宣布从使用开源的 Rest.li 框架和 JSON 序列化格式,转向采用 gRPC 和 Protocol Buffers 作为其微服务平台的服务间通信方式。InfoQ 采访了 LinkedIn 的两位工程师,Karthik Ramgopal 和 Min Chen,以揭示这一变化的动机。

选择 gRPC 和 Protocol Buffers 的原因

切换到 gRPC 的主要原因包括:gRPC 提供的高级功能(如双向流、流量控制和截止时间);其高效性能,具有性能优化的实现;以及对多种编程语言的高质量支持。此外,gRPC 背后有一个庞大且活跃的开源社区,并在业界广泛应用,而 Rest.li 主要由 LinkedIn 贡献和使用。

从 JSON 到 Protocol Buffers 的转变和序列化格式评估

将 JSON 更换为 Protocol Buffers 带来了显著的性能提升,特别是在数据载荷大的场景下,能够降低延迟并提高吞吐量。除了 Protobuf,LinkedIn 还评估了 CBOR、MessagePack、SMILE、Avro、Kryo、Flatbuffers 和 Cap’n’Proto 等其他序列化格式,最终选定 Protobuf,因为它在运行时性能、开发者体验以及多语言环境支持方面提供了最佳平衡。

对 Rest.li 用户的建议

随着 Rest.li 框架将不再继续开发,LinkedIn 建议用户考虑迁移到 gRPC,并提供了联系方式以获取迁移指南。

服务延迟和效率的改善

服务延迟通过更小的数据载荷和减少 CPU 时间占用的序列化/反序列化得到改善,尤其是在大且复杂数据载荷的服务中,最高达到 60% 的延迟减少。使用 Protobuf 还有助于显著改善服务的尾部延迟(p95/p99),主要是由于减少了垃圾回收。

LinkedIn 复杂的服务端点数量

LinkedIn 作为专业人脉网络,拥有复杂的“经济图谱”实体,各种业务和内部应用程序、工具系统等,采用三层架构,鼓励 CRUD 建模方式,这些都通过 Rest.li 进行建模,导致了超过 50000 个 Rest.li 端点的产生。

采用 gRPC+Protobuf 的未来规划

LinkedIn 采用 gRPC+Protobuf 目的在于提升性能和多语言支持,正在进行的项目包括将有状态存储和流式处理系统从 Avro 迁移到 Protobuf,将通用基础设施功能移至 Sidecar,以及改进内部服务发现和负载均衡器,以适配 gRPC xDS SDK 和 Envoy Sidecar。

想要了解更多,点击 查看原文

为一线互联网公司核心技术人员提供优质内容。科技圈的观察者,前沿技术的传播者。

98 篇文章
浏览 4465
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线