LinkedIn 从 Rest.li 迁移到 gRPC 的自动化过程

在 QCon London 2024 上，Karthik Ramgopal 和 Min Chen 分享了 LinkedIn 如何将 50,000 个生产端点的远程过程调用（RPC）协议从 Rest.li 迁移到 Google 的 gRPC。这一迁移过程仍在进行中，团队计划自动将 2,000 个服务迁移到 gRPC 桥接模式，且不会中断业务。

背景

• Rest.li: 使用 Pegasus 数据语言（PDL）定义 RPC 接口，并通过 PDL 生成 Java 类，使用 JSON over HTTP 作为传输协议。尽管 LinkedIn 开源了 Rest.li，但其在 LinkedIn 之外的采用率有限。
• gRPC: 起源于 Google，现已成为云原生计算基金会（CNCF）的孵化项目，广泛使用。

自动化迁移的原则

1. gRPC 桥接模式: 引入中间桥接模式，使 Rest.li 和 gRPC 在客户端和服务器上并行运行。现有代码无需手动更改即可继续运行，而新代码可以使用 gRPC。
2. 自定义模式转换器: 自动生成互操作桥接类，将 PDL 转换为 gRPC proto 模式，反之亦然。因此，gRPC proto 模式可以作为单一来源，任何更改都会自动反映到 PDL。

迁移过程

• 独立迁移: 由于 gRPC 桥接模式的存在，服务器和客户端可以独立迁移。
• 模拟迁移: LinkedIn 开发了模拟迁移的“干运行”过程，在测试环境中预判并发现潜在的错误，错误会生成 Jira 工单。
• 最终目标: 一旦所有流量从 Rest.li 切换到 gRPC，客户端将脱离桥接模式，使用原生 gRPC，随后服务器也将进行同样的迁移。

挑战与解决方案

• 依赖管理: 由于 LinkedIn 不使用单一代码库，PDL 依赖导致无法一次性更新所有代码。因此，LinkedIn 构建了一个协调器，通过计算依赖顺序来管理迁移。
• 代码修改: 使用抽象语法树（AST）进行代码修改不足以实现原生迁移，因此 LinkedIn 计划使用生成式 AI 进行未来的原生迁移，这一方法已在 LinkedIn 的其他两次迁移中成功应用。

迁移原因

• Rest.li 的局限性: 不支持流式传输、延迟响应或截止时间，性能较慢，对非 Java 客户端和服务器的支持不足。
• gRPC 的优势: 支持双向流式传输、延迟响应和截止时间，性能优异，支持多种编程语言，从而降低基础设施成本。

gRPC 的局限性

gRPC 缺少一些 Rest.li 的功能，如继承、必填字段、自定义默认值、类型联合和自定义类型。转换器将这些功能转换为 gRPC proto 模式中的“Pegasus 自定义选项”，并生成自定义代码来处理这些选项，例如检查必填字段是否包含值。

总结

LinkedIn 的迁移过程展示了如何通过自动化工具和策略，大规模地从 Rest.li 迁移到 gRPC，同时确保业务连续性和代码的逐步优化。