微软产品 .NET 6 迁移之旅

“.NET性能不行！”

“.NET有什么像样的产品吗！？”

“升级到.NET 6有什么好处！？”

……

听人扯淡还不如看看微软自己是怎么做的。

本文将汇总一下微软的开发博客——这些博客均涉及微软将产品和服务迁移到.NET 6的成果。

博客按时间由近及远排序。

《Microsoft Teams’ Infrastructure and Azure Communication Services’ Journey to .NET 6》: https://devblogs.microsoft.com/dotnet/microsoft-teams-infrastructure-and-azure-communication-services-journey-to-dotnet-6/

迁移到 .NET Core 是由多种因素驱动的：

成本降低：Azure 计算成本平均节省 29%。
性能提升：性能提升30-50%，包括P99 CPU利用率和P99服务时延。
服务和网络现代化：访问框架中的最新功能，例如轻量级应用程序内存占用，支持Linux上的容器，更好的异常处理，从而在恶劣的条件下获得更好的可靠性以及最新的安全修复。
提高工程满意度和生产力

《Microsoft Commerce’s .NET 6 Migration Journey》：https://devblogs.microsoft.com/dotnet/microsoft-commerce-dotnet-6-migration-journey/

一个特别重要的例子是，一个服务从 .NET Framework 迁移到 .NET Core 3.1，同时尽可能多地保留其他相同内容（尽管此更改也包括对 .NET Core 的依赖项更新，以及在迁移其代码时所做的小改进）。下图显示了服务延迟提高了约 78%，并且在最初部署后（使用相同的负载、环境和硬件运行）显著提高了稳定性！

随着我们更复杂的服务迁移到 Kubernetes 中，我们的迁移需要的不仅仅是 .NET：

从Windows 到Linux
.NET 框架到 .NET Core（3.1，在某些情况下为 5.0，现在是 6.0）
平台转向容器和Kubernetes（远离虚拟机）
更换构建和发布系统，以利用最新的安全性和合规性改进并支持容器化应用程序。
随着我们在迁移时利用平台和 .NET 中的增强和改进，以及我们的合作伙伴对依赖项执行了相同的操作，还有更多功能。虽然这些好处并不完全归功于我们的 .NET Core 迁移，但它们是通过迁移实现的，我们非常感谢 .NET 团队在迁移过程中提供的所有帮助和支持！

《Microsoft Teams Assignments Service’s Journey to .NET 6》：https://devblogs.microsoft.com/dotnet/microsoft-teams-assignments-service-dotnet-6-journey/

在迁移后，我们确实看到了一些 CPU 和延迟的改进，但最一致的改进是内存消耗（进程\专用字节）的减少。随着我们继续调整我们的代码库，我们对此迁移解锁的更有针对性的优化感到非常兴奋！例如，我们可以利用它来减少更多代码路径中的分配，因为大多数 BCL API 现在都支持它作为的替代方法。此外，我们现在可以访问 .NET 6 （https://docs.microsoft.com/en-us/dotnet/core/runtime-config/）中的大量新配置选项，并期待调整和调整运行时以更好地适应我们的所有工作负载。

《OneService Journey to .NET 6》：https://devblogs.microsoft.com/dotnet/one-service-journey-to-dotnet-6/

在两年多的时间里，我们将大量 .NET Framework 4.7.2 应用、库和测试项目转换为 .NET 6，验证了功能和性能等效性（或更好），现在几乎完全在生产中的 .NET 6 上运行。该项目取得了重大成功，有助于降低运营成本并改善开发人员体验。

突出：

基础设施成本降低 29%。
迁移服务的 CPU 平均提高 30%。
主 API 的 P95 延迟提高了 8-27%。
减少了技术债务，现在可以轻松地升级到年度 .NET 版本。
更快乐、更高效的团队。

《Exchange Online Journey to .NET Core》：https://devblogs.microsoft.com/dotnet/exchange-online-journey-to-net-core/

出于三个原因，我们之所以有动力迁移到 .NET Core。首先，我们非常需要提高性能和成本效益。任何基于云的供应商都知道，每一次低效率都会花费真金白银。第二，知道 .NET Framework 不再积极开发，我们希望迁移到一个为未来开辟道路的现代框架。第三，可能更重要的是它很酷，有光泽和新鲜。

《The Azure Cosmos DB Journey to .NET 6》：https://devblogs.microsoft.com/dotnet/the-azure-cosmos-db-journey-to-net-6/

Azure Cosmos DB's API网关是一种低延迟的 Azure 服务。它以多种方式利用 .NET 来实现其性能和延迟要求。多年来，每次 .NET 升级都产生了许多好处，既包括新的 API，这些 API 提供了更好的方法来管理性能，并改进了框架中的现有 API 和运行时行为。我们正在积极与 .NET 团队合作，采用 .NET 7，并期待在即将发布的 .NET 版本中推出更多影响深远的性能功能。

《Microsoft Graph’s Journey to .NET 6》：https://devblogs.microsoft.com/dotnet/microsoft-graph-dotnet-6-journey/

四年前，该服务在 IIS 上运行，在 .NET Framework 4.6.2 上 ASP.NET。目前，该服务在 HTTP 上运行.sys.NET 6 上 ASP.NET 核心，在 .NET Core 3.1 和 .NET 5 上暂时停止。每次升级时，我们都观察到 CPU 利用率有所提高，尤其是在 .NET Core 3.1 和最近的 .NET 6 中。

从 .NET 框架到 .NET Core 3.1，我们观察到在相同的流量下 CPU 减少了 30%。
从 .NET Core 3.1 到 .NET 5，我们没有观察到要报告的有意义的差异。
从 .NET 5 到 .NET 6，我们观察到在相同的流量下，CPU 又减少了 10%。

CPU 利用率的大幅降低转化为更好的延迟、吞吐量和有意义的计算容量成本节约，从而有效地帮助我们实现目标。

《Azure Active Directory’s gateway is on .NET 6.0!》：https://devblogs.microsoft.com/dotnet/azure-active-directorys-gateway-is-on-net-6-0/

Azure 活动目录的网关服务是一个反向代理，用于处理构成 Azure 活动目录（Azure AD）的数百个服务。如果使用了 office.com、outlook.com、portal.azure.com 或 xbox.live.com 等服务，则表示你已使用 Azure AD 的网关。网关提供 TLS 终止、自动故障转移/重试、异地邻近路由、限制和向 Azure AD 中的服务分段等功能。该网关存在于全球 54 个 Azure 数据中心，每天为大约 1850 亿个请求提供服务。直到最近，Azure AD 的网关还在 .NET 5.0 上运行。截至 2021 年 9 月，它已在 .NET 6.0 上运行。