使用 .NET 为 Microsoft AI 构建可扩展网关

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

反向代理

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

Bing 运行着世界上最大、高性能且可靠的 .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> 元数据部分中设置此配置。我们在响应返回到客户端之前检查响应，从匹配的路由中获取元数据，然后使用直接 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 按顺序加载（最后加载的键获胜）：

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

简单示例：

当在环境2（生产组的一部分）上启动服务时，将导致如下配置：

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

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

性能很重要，.NET 8 甚至更快

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

展望未来

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