.NET YARP为微软AI构建高扩展网关

Building a scalable gateway with .NET for Microsoft AI

卡拉·索斯曼（Kara Saucerman）

英文原文：Building a scalable gateway with .NET for Microsoft AI - .NET Blog

Microsoft AI 团队为消费者构建全面的内容、服务、平台和技术，以便在任何设备、任何位置获取他们想要的信息，并为企业改善其客户和员工体验。我们的团队为 Bing、Copilot、Advertising、Maps 和 Edge 等多种体验提供支持，通过 Edge 新标签页、Windows 10 和 11 等入口点浮出水面，这些平台每月活跃用户超过 10 亿。我们意识到需要一个高性能和可靠的网关作为 Microsoft AI 的前端和入口层。这将使多个团队能够利用我们开发的通用功能来帮助运营业务并专注于客户体验和功能。在这篇博文中，我们将介绍在 .NET 8 上的 YARP 的帮助下构建代号为 CETO 的网关的过程。

Reverse Proxy 反向代理

在我们开始编写 CETO 代码之前，我们必须决定使用反向代理。我们应该使用外部的还是尝试自己制作的？这些外部的会涵盖我们所有的用例吗？我们还必须考虑定制这些代理的高成本和持续维护。我们有支持 HTTP/2、HTTP/3、WebSocket 等流协议、简单可扩展性等要求。当我们开始环顾 Microsoft 的其他内部团队在做什么时，我们遇到了 YARP 项目。YARP 代表：“又一个反向代理”。该项目使用 http://ASP.NET 和 .NET（.NET 6 及更高版本）来提供可通过 .NET 代码修改的灵活解决方案。这有多方便？事实证明，这正是我们所需要的。

必应运行世界上最大、高性能且可靠的 .NET 应用程序之一。我们一直依赖于与 .NET 团队的密切工作关系，并且是每个 .NET 版本的早期采用者。通过试用和升级到每个新版本，我们可以向 .NET 团队提供有用的反馈。这有助于我们的平台和将升级服务的外部客户使用这些新版本。我们将 YARP 纳入该反馈周期。

在新 .NET 上创建新服务

由于 CETO 是一项新服务，我们当时有机会使用最新版本的 .NET。如今，它建立在 .NET 8、Kestrel + YARP 2.1 之上，在多个基础结构平台和数千台服务器的 Linux 和 Windows 容器上运行。跨平台运行的能力提高了我们模块的可移植性和兼容性，以及部署在任何地方的灵活性和效率。性能很快，这一层的每一毫秒都很重要。CPU% 较低，可降低运营成本。

CETO通过在我们的平台上统一我们的业务逻辑来提供融合，然后将请求移交给YARP，以完成路由到适当的上游服务的繁重工作。我们希望我们的路线和地图非常可定制，因为我们处理许多不同的团队，这些团队具有不同的交通模式，这会影响其他关键功能。

灵活性至关重要

对于如何使用 .NET 和 YARP，我们有很多选择和控制权，因为它们具有很强的适应性和通用性。.NET 提供了多种 API 来满足不同的需求，例如配置、依赖项注入、日志记录、测试和调试。通过使用 .NET，我们从事 CETO 工作的开发人员可以编写灵活、易于维护的代码，这些代码可以与我们服务的其他部分无缝连接。

以下是我们调整的几种方法来满足我们的要求：

我们希望从一个中心位置管理我们内部团队的路线和目的地，以便客户流量。使用 YARP，我们可以通过提供几个实现 IProxyConfigProvider 和 IProxyConfig 的类来选择从外部位置加载配置。团队可以创建任意数量的简单或复杂路由，并将它们与其他团队分开部署。更改在后台重新加载，然后我们将代理配置状态与新快照交换，表示旧快照已过时。

使用完整的 YARP 代理，因此我们具有路由和负载均衡的好处。我们希望提供一个选项，以便在从服务接收回某些 http 状态代码时转发到另一个位置。团队可以在 YARP 路由配置的 IReadOnlyDictionary<string， string> Metadata 部分中设置此配置。在响应返回到客户端之前，我们会检查响应，从匹配的路由中获取元数据，然后使用直接 IHttpForwarder 将请求转发到另一个位置。通过使用 IHttpForwarder，我们仍会获得这些请求的错误处理、流式处理协议和 http 客户端自定义。

YARP 具有多个适合大多数方案的默认负载均衡策略。我们不需要修改这些策略的目标选择，而是在选择过程中进行干预并做其他事情。从 ILoadBalancingPolicy 创建新策略并利用 IReadOnlyDictionary<string， string> 元数据在目标属性中的使用，我们可以为其他目的对特定目标进行分类。

在本例中，我们希望将一定百分比的请求镜像到不同的目的地。流量镜像或流量重演用于将生产流量重放到测试环境，而不会影响最终用户的体验。请求被克隆并发送到队列进行处理，同时我们继续正常的选择逻辑，为请求选择可用的目标（不是镜像类型）。

.NET 速率限制是另一个易于利用的功能。它有一个使用 PartitionedRateLimiter 的选项，它允许您根据可以是任何唯一 UserId 或其他标识符的密钥设置速率限制策略。我们通过使用 YARP routeId 作为密钥的一部分，实现了每个路由的速率限制。这些路由的所有者可以直接在 YARP 路由配置（元数据部分）中指定其许可值，我们将其传递给速率限制器扩展。密钥创建为 routeId + 唯一标识符，以便当团队更新其许可限制时，我们会生成一个新密钥。速率限制库可以自动获取此信息，而无需重新启动服务。如果策略已存在，速率限制不会更新允许限制，因此我们创建新密钥。库会在大约 30 秒后删除过时的策略。这使我们能够保护每条路线的服务，并在一个位置管理我们团队的容量。

大多数 CETO 配置将 .NET 中的 Configure 和 IOptionsMonitor 接口与 Json 配置提供程序结合使用。IOptionsMonitor 接口用于检索 IOptions 实例的选项和管理选项通知。

使用我们的自定义服务扩展 AddSingletonServiceConfig 添加配置，该扩展使用 ConfigurationBuilder 按顺序加载（最后加载的键优先）：

• Default values services.Configure(serviceConfig.GetSection(“Default”));
  

• Environment group values services.Configure(serviceConfig.GetSection(environmentAlias));
  

• Per environment values services.Configure(serviceConfig.GetSection(environmentName));
  

然后将配置添加到接受 IOptionsMonitor 的单一例 IConfigurationReader。

简单示例：

在属于生产组的 environment2 上启动服务时，将生成如下配置：

"ModuleA": {
  "SSLCertificateSecretIdentifier": "ProdCert",
  "PollingIntervalInSec": 30
},

当模块所有者想要添加新配置时，他们会将其新架构模型创建为 C# 类，添加 Json 配置文件，并更改 CETO 以调用我们的服务扩展。它们的类现在通过依赖注入接收特定运行环境的配置。当我们使用 IOptionsMonitor 时，它还支持更改通知。

性能很重要，.NET 8 一直很快

我们始终对服务的性能负责。随着服务所有者不断增加功能数量，延迟可能会逐渐增加。每个版本的 .NET 都带来了性能提升。当我们可以免费升级并获得这些性能改进时，我们将不胜感激。但是，我们仍然需要定期介绍我们的服务，以确保我们明智地使用我们的资源。对于我们的开发人员来说，阅读开发博客文章以获取有用的提示非常有用。

展望未来

通过使用现代 .NET 及其功能，我们能够为我们的组织创建一个有效且高质量的网关，没有重大困难。我们仅展示了几个示例，说明扩展 .NET 库以满足我们的组织需求是多么容易。我们对未来的 .NET 版本以及与 .NET 团队的持续合作感到兴奋。