RSS

C# 中 gRPC 的未来属于 grpc-dotnet

2023-10-02 更新:Grpc.Core 的维护期已再次延长,至少到 2024 年 10 月。有关 Grpc.Core 的最新信息,请参阅 公告

2022-05-03 更新:Grpc.Core 的维护期已延长至 2023 年 5 月。有关 Grpc.Core 未来的更多信息,请参阅公告

总结:grpc-dotnet(Grpc.Net.ClientGrpc.AspNetCore.Server nuget 包)现在是 .NET/C# 推荐的 gRPC 实现。原始 gRPC C# 实现(Grpc.Core nuget 包)将进入维护模式,不会获得任何新功能,并且只会收到重要的错误修复和安全修复。最终计划是在未来的某个时候完全淘汰 Grpc.Core。此公告描述了我们决定这样做的原因,并更详细地制定了计划。

在 2019 年 9 月,我们宣布正式推出一个新的 gRPC C# 实现,它不再基于 gRPC C 核心原生库,而是使用 .NET Core 3 和 ASP.NET Core 3 中添加的 HTTP/2 协议实现。我们将此实现称为“grpc-dotnet”。

当我们引入 grpc-dotnet 实现时,我们宣布两个 gRPC C# 实现(新的纯 C# grpc-dotnet 实现和基于 C 核心原生库的原始 gRPC C# 实现)将并存,让用户选择最适合他们的实现。这是非常有道理的,因为当时的 grpc-dotnet 是全新的,需要刚刚发布的 .NET Core 框架,而原始 gRPC C# 实现已经稳定了很长时间,有很多用户,并且甚至可以在非常旧的 .NET Framework 版本上运行。事情需要一些时间才能稳定下来。

从那时起,新的 grpc-dotnet 实现取得了长足的进步:它已被许多用户采用并变得非常流行,已被许多生产环境中的应用程序使用,并且还添加了许多有趣的新功能。此外,它的主要先决条件 .NET Core 3 框架已经存在一段时间了,并且其采用率正在增长。

与此同时,虽然 原始 gRPC C# 实现(通常称为“Grpc.Core”,其 nuget 包的名称)绝对有其地位并且非常受欢迎,但我们现在正接近这样一个时刻,即在 2016 年(当 gRPC C# 作为 GA 发布时)非常有意义的一些设计决策不再具有它们过去所拥有的重要性。例如,我们决定将 gRPC C# 实现基于原生库,因为在 2016 年,没有可用的 C# HTTP/2 库可供我们依赖。通过依赖 C 核心原生库,我们能够比从头开始用 C# 实现所有内容更快地交付稳定、高性能的 gRPC 库。但从今天的角度来看,采用原生依赖关系不再那么有意义了,因为 HTTP/2 支持现在已内置到 .NET Core 框架中。拥有原生依赖关系的好处正在减少,而拥有原生依赖关系的维护负担却保持不变。

在两个稳定的 C# 实现中,grpc-dotnet 实现无疑是更有未来潜力的一个。它是一个更现代的实现,与现代版本的 .NET 集成良好,并且很可能更符合 C# 社区未来几年的发展方向。它也是一个纯 C# 实现(没有原生组件),这使得它更方便贡献代码,更易于调试,并且也是 C# 爱好者喜欢看到的。

由于维护两个官方 gRPC C# 实现的成本不低,而且从长远来看,grpc-dotnet 似乎是所有用户的最佳选择,因此我们希望宣布计划逐步淘汰原始的 gRPC C# 实现(nuget 包 Grpc.Core),转而支持更现代、更具前瞻性的 grpc-dotnet 实现

计划的详细信息将在以下章节中介绍,并进一步解释其合理性。为了帮助理解逐步淘汰 Grpc.Core 的决定所带来的影响,我们还列出了一份常见问题列表并提供了答案。

是什么使 grpc-dotnet 成为首选实现

简而言之,grpc-dotnet 似乎是未来的更好选择。一些最重要的要点已经提及。以下是更详细的原因列表,说明为什么我们相信 grpc-dotnet 将更好地满足用户的需求:

  • 它是一个更现代的实现,基于最新版本的 .NET 框架的功能。因此,它很可能成为未来两个实现中更可行的一个。

  • 它更符合 C# / .NET 社区现在和未来的发展方向。与社区的发展方向保持一致似乎是 gRPC 在 C# 中发展的最佳选择。

  • 该实现更加敏捷且方便贡献代码 - 因为它在内部基于众所周知的原语/API(ASP.NET Core 服务 API 和 HTTP2 客户端),并且是用纯 C# 实现的,所以 C# 开发人员更容易访问代码(无论是只想了解其工作原理的用户,还是想要编写 PR 的潜在贡献者)。grpc-dotnet 代码库相对较小,构建只需几秒钟,运行测试也简单快捷。从长远来看,更轻松的开发和方便贡献代码应该可以弥补今天缺失的一些功能,并使其成为用户的更好选择 - 也就是说,降低贡献代码和修复/改进内容的门槛,经过一段时间后,将转化为更多的修复和更好的用户体验。

  • 与依赖于原生组件的实现相比,拥有一个用纯 C# 实现的库通常是 .NET 社区所青睐的。虽然 C# 对与原生库互操作提供了良好的支持,但这是一项大多数 C# 开发人员不熟悉的技术,对他们来说就像一个黑盒子。原生互操作很难做到正确,并且存在许多缺点(例如,更复杂的开发和构建过程、复杂的调试、难以维护、难以获得社区贡献、难以提供对多个平台的支持)。使用 Grpc.Core,我们能够克服大部分这些挑战(因此现在一切正常),但这需要付出很多努力,解决方案有时很复杂且脆弱,而且维护成本很高,需要大量的专业知识。

    注意:用于 C# 的 Google.Protobuf 库已经是纯 C# 编写的(没有原生组件),因此使用纯 C# 实现 gRPC 可以完全从开发人员的微服务堆栈中消除原生组件

为什么不永远保留 Grpc.Core?

开发两个 gRPC 的 C# 实现并非没有成本。它会消耗宝贵的资源,我们认为工程时间应该更好地用于使 gRPC 在 C# 中更易于使用,并添加新功能(当然还要修复错误),而不是需要处理两个用途相同的不同代码库。此外,拥有两个单独的实现必然会在某种程度上分散用户群,并将贡献者的努力分成两部分。此外,仅仅是用户需要选择他们想要押注哪一个实现的行为就带来了不确定性和固有风险(我们不希望我们的用户面临这些风险)。

通过使 grpc-dotnet 成为推荐的实现,并将 Grpc.Core 实现“仅限维护”(并最终逐步淘汰),我们的目标是实现以下目标:

  • 释放工程资源,以便开发更好的功能和更好的可用性。
  • 统一 gRPC C# 用户群。这将引导所有社区工作和贡献都集中在一个实现上。它还消除了用户需要选择使用哪个官方实现所造成的固有摩擦。
  • 解决 Grpc.Core 一些众所周知的痛点,这些痛点很难通过其他方式解决。
  • 通过与 .NET 社区保持一致,使 gRPC 的 C#/.NET 实现面向未来。

计划

第一阶段:Grpc.Core 进入“仅限维护”阶段

时间:立即生效(2021 年 5 月)

从现在开始,我们将不再为 Grpc.Core 提供新功能或增强功能。重要的错误和安全问题将继续以正常方式解决。

我们将按正常方式发布 Grpc.Core 版本,保持通常的 6 周频率。

这些版本将基于最新的 grpc C core 原生库构建,因此所有不需要 C# 特定工作的新功能也将被包含在内。

第二阶段:Grpc.Core 进入“已弃用”阶段

时间:一年后(2022 年 5 月)

一旦达到此里程碑,Grpc.Core 将不再获得官方支持,并且强烈建议所有用户从此开始仅使用 grpc-dotnet。

Grpc.Core nuget 包将继续在 nuget.org 存储库中提供,但不再提供任何修复(= 甚至包括安全修复)。

Grpc.Tools 和 Grpc.Core.Api nuget 包的未来

这两个包将继续获得全面支持,因为严格来说它们不是 Grpc.Core 的一部分,而且 grpc-dotnet 也使用它们。

  • 为 C# 项目提供代码生成构建集成的 Grpc.Tools nuget 包将继续获得支持(并可能得到改进) - 因为 Grpc.Core 和 grpc-dotnet 都使用它。此包独立于 C core。
  • Grpc.Core.Api 包是 grpc-dotnet 的先决条件,因此它也可能会随着时间的推移而发展(但它只是一个纯 C# API 包,而且由于它只包含公共 API 表面,因此更改非常不频繁)

问答

我当前是 Grpc.Core 用户,这对我的意味着什么?

虽然我们将继续支持 Grpc.Core 一段时间(有关详细信息,请参阅弃用计划),但如果您希望在未来继续获得更新和错误修复,则必须将您的项目迁移到 grpc-dotnet。

如何将我现有的项目迁移到 grpc-dotnet?

由于 Grpc.Core 和 grpc-dotnet 是两个不同的库,因此您的项目中需要进行一些代码更改。由于两个实现都共享用于调用和处理 RPC 的相同 API(我们有意将其设计为这样),我们认为必要的代码更改应该非常少。对于许多应用程序,您只需更改配置 gRPC 通道和服务器的方式;这通常只是应用程序实现的一小部分,并且往往与业务逻辑分离。

有关如何从 Grpc.Core 迁移到 grpc-dotnet 的更多提示,请参阅 将 gRPC 服务从 C-core 迁移到 ASP.NET Core

我们计划在未来发布更详细的迁移指南,以方便从 Grpc.Core 迁移到 grpc-dotnet。

我想在 C# 中为新项目使用 gRPC。我应该选择哪个实现?

我们强烈建议新项目仅使用 grpc-dotnet。我们将在未来停止支持 Grpc.Core。

这是否意味着我需要立即停止使用 Grpc.Core?

不,Grpc.Core 将在一段时间内继续得到支持(请参阅弃用时间表)。您应该有足够的时间来评估情况并计划迁移。

我没有在代码中直接使用 gRPC,但我正在使用 Google Cloud Client Libraries(它在底层使用了 Grpc.Core)。这对我有什么影响?

此弃用目前不会影响 Google Cloud Client Libraries 的现有用户。

由于 Grpc.Core 是这些客户端库的组成部分,因此将继续为 Google Cloud Client Libraries 提供 Grpc.Core 的安全性和错误修复。

将提供扩展支持的客户端库

请注意,Grpc.Core 的扩展支持仅在作为这些客户端库的一部分使用时提供。对于 Google Cloud Client Libraries 之外的其他用例,Grpc.Core 在弃用日期之后将不会获得官方支持,用户必须在弃用发生之前将现有工作负载迁移到 grpc-dotnet。

在哪里可以找到支持的功能列表?

我们在 github 上的文档 比较了支持的功能。

我有一个 Grpc.Core 的重要用例,本文档未涵盖。

欢迎您的反馈!请通过 grpc-io Google Group 或任何其他主要的gRPC 社区渠道联系我们。