Azure 网关迁移至 .NET Core 3.1 性能提升一倍
（给DotNet加星标，提升.Net技能）
英文：devblogs.microsoft.com 译文：cnblogs.com/Rwing/p/azure-active
译者：Rwing
前言
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 的组件和最佳实践，同时也做出回馈。
原文：https://devblogs.microsoft.com/dotnet/azure-active-directorys-gateway-service-is-on-net-core-3-1/
- EOF -
看完本文有收获？请转发分享给更多人
推荐关注「DotNet」，提升.Net技能
点赞和在看就是最大的支持❤️