LinkedIn 宣布采用 gRPC 和 Protocol Buffers 进行微服务间通信

LinkedIn 宣布将微服务平台中的服务间通信从 Rest.li 框架（主要使用 JSON 作为序列化格式）迁移到 gRPC 和 Protocol Buffers（Protobuf）。这一决策旨在提升性能、效率和跨语言支持。

选择 gRPC 和 Protobuf 的主要原因

在采访中，LinkedIn 的杰出工程师 Karthik Ramgopal 和首席工程师 Min Chen 解释了选择 gRPC 和 Protobuf 的主要原因：

1. 强大的功能：gRPC 支持双向流、流量控制和截止时间等高级功能，而 Rest.li 并不具备这些能力。
2. 高效性：gRPC 是一个高效的框架，具备完全异步非阻塞绑定和高级线程模型等性能优化特性。通过合成基准测试和生产环境中的并行运行验证，gRPC 在性能上优于 Rest.li。
3. 多语言支持：Rest.li 主要支持 Java，对其他编程语言的支持有限，而 gRPC 提供了多种编程语言的高质量支持，这符合 LinkedIn 的基础设施需求。

此外，gRPC 拥有庞大且活跃的开源社区，并在行业内广泛应用，而 Rest.li 主要由 LinkedIn 贡献和使用。

从 Rest.li 迁移到 gRPC 的经验

LinkedIn 曾在 Rest.li 框架中采用了 Protobuf 作为序列化格式，并从中获得了宝贵的经验。他们发现，在大规模场景下，从 JSON 切换到 Protobuf 可以显著降低延迟并提高吞吐量。除了 Protobuf，LinkedIn 还评估了 CBOR、MessagePack、SMILE、Avro、Kryo、Flatbuffers 和 Cap’n’Proto 等序列化格式，最终选择 Protobuf 是因为它在运行时性能、开发者体验和多语言支持之间提供了最佳平衡。

对 Rest.li 用户的建议

LinkedIn 宣布 Rest.li 框架将不再开发并逐步弃用。他们建议当前用户考虑迁移到 gRPC，并表示可以通过 LinkedIn 联系他们获取迁移自动化工具的指导。

性能提升的具体细节

在迁移到 gRPC 和 Protobuf 后，LinkedIn 观察到某些服务的延迟降低了高达 60%。这种改进主要来自于更小的负载大小和更少的 CPU 时间用于序列化/反序列化。对于负载非常大且复杂的服务，这些因素对延迟的贡献尤为显著。此外，由于 Protobuf 的使用减少了垃圾回收（GC）的频率，许多服务的尾部延迟（p95/p99）也得到了显著改善。

LinkedIn 的 Rest.li 端点数量

LinkedIn 目前在生产环境中拥有超过 50,000 个 Rest.li 端点。这主要源于其复杂的“经济图”结构，包括企业业务（如 Recruiter、LinkedIn Learning、Sales Navigator 等）和内部应用程序。此外，LinkedIn 采用三层架构（BFF、中间层和后端），并鼓励基于 CRUD 的建模和标准化实体，这些因素在过去十年中导致了大量 Rest.li 端点的创建。

gRPC+Protobuf 采用项目的目标

LinkedIn 采用 gRPC 和 Protobuf 的主要目标与选择它们的原因一致：提升性能、效率和跨语言支持。此外，LinkedIn 正在将所有有状态存储和流式系统从 Avro 迁移到 Protobuf，并将一些常见基础设施功能（如授权、调用追踪、日志记录等）从 Java 库迁移到 sidecar，通过 gRPC 暴露 UDS API，以减少多语言支持的成本。他们还计划改造其自主研发的服务发现和负载均衡器，采用工业标准的 xDS 协议，以与 gRPC xDS SDK 和 Envoy sidecar 兼容。