原文:[Azure Active Directory’s gateway is on .NET Core 3.1!]

Azure Active Directory 的网关服务是一个反向代理，它为构成 Azure AD 的数百个服务提供前置服务。如果你使用过 office.com、outlook.com、azure.com 或 xbox.live.com 等服务，那么你已经使用了 Azure AD 的网关。网关为 Azure AD 中的服务提供了 TLS 终止、自动故障切换/重试、地理位置临近度路由、节流和 tarpitting 等功能。该网关存在于全球超过 53 个 Azure 数据中心中，每天服务于约 1150 亿次请求。一直以来，Azure AD 的网关都运行在 .NET Framework 4.6.2 上，直到2020年9月，我们把它迁移到了.NET Core 3.1上。

移植到 .NET Core 的动机

网关的执行规模导致计算资源的大量消耗，而计算资源的消耗又要花费大量的金钱。寻找降低服务执行成本的方法一直是我们团队的一个关键目标。而 .NET Core 对性能的大量改进引起了我们的注意，尤其是 TechEmpower 将ASP.NET Core 列为全球最快的 Web 框架之一。我们在 .NET Core 上的对网关原型运行了基准测试，测试结果让人很容易做出决定：我们必须移植到 .NET Core 上。

.NET Core 的性能改进能否转化为现实中的成本节约？

绝对是的。在 Azure AD 网关这个案例中，我们能够削减 50% 的 CPU 成本。
这个网关曾经在 IIS 上运行并采用 .NET Framework 4.6.2。如今，它运行在 .NET Core 3.1 的 IIS 上。
下图显示，与 .NET Framework 4.6.2 相比，我们在 .NET Core 3.1 上的 CPU 使用量减少了一半（有效地将我们的吞吐量提高了一倍）。
由于吞吐量的提升，使得我们能够将集群规模从 4 万个核心减少到约 2 万个核心（减少50%），如图二。

（图一）

（图二）

未来

移植到 .NET Core 后，我们的服务吞吐量增加了一倍，这是一个伟大的决定，并且我们的 .NET Core 之旅不会停止。对于未来，我们正在考虑：

• 升级到 .NET 5.0 以进一步提高性能。
• 移植到 Kestrel，以便我们能够在 TLS 层拦截连接，以获得更好的弹性。
• 在我们自己的反向代理中使用 YARP 的组件和最佳实践，同时也做出回馈。