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

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。