LinkedIn 解释为什么选择用 gRPC+Protobuf 替代 Rest.li+JSON
![](/theme/default/default/images/main/eye-open.png)
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
![](/theme/default/default/images/main/icon-jing.png)
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。
想要了解更多内容?
![](/theme/default/default/images/main/icon-jing.png)
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)