Microsoft 365 （M365） 是一组广泛的生产力服务，可实现团队合作、通信和相关体验。大部分代码库都是用 C# 编写的。我想告诉您有关.NET Core获得“M365 Substrate”服务的旅程。Substrate是一组服务，您可以将其视为Microsoft Exchange的后裔。事实上，Exchange是微软第一个采用.NET并部署为64位的服务。
基材是一种成熟且非常庞大的产品。我们之所以有动力迁移到 .NET Core，有三个原因。首先，我们非常需要性能和成本效益的提高。任何基于云的供应商都知道，每一次低效率都会花费真金白银。第二，知道.NET Framework不再积极开发，我们希望转向一个现代框架，开辟一条通往未来的道路。第三，可能更重要的是它很酷，有光泽，很新。
虽然我们有许多用于辅助服务的git存储库，但 Substrate的核心包含在“Substrate”git存储库中。此存储库包含大约 3400 个用于产品代码的 C# 项目，另外 3400 个用于测试代码的项目，以及 1000 多个C++项目。我们的生产服务在 200，000 多台计算机上运行 100 多种不同的流程和应用池，并且有超过 1000 名贡献者。
方法论
转换工作从单个团队开始，专注于单个协议作为概念验证迁移 - POP3 协议。与其他协议相比，POP3 协议的使用率较低，并且需要转换的依赖程序集网络较小。因此，它非常适合首次迁移。即便如此，仍有大约 140 个程序集和 NuGet 包需要迁移到 .NET Core。
鉴于 .NET Core 程序集应仅使用其他 .NET Core（或标准）程序集，我们需要确定迁移这些程序集的顺序。我们根据日常构建构建构建了一个依赖关系图工具，向我们展示了给定协议的程序集依赖项（直接和间接），向我们展示了哪些程序集与.NET Core兼容（使用.NET Portability Analyzer），并向我们展示了如何将这些程序集迁移到.NET Core将累积到基板中的其他进程/应用程序池。
虽然我们最初将 .NET Standard 2.0 作为许多常见程序集的目标，但我们最终放弃了 .NET Standard，选择了多目标，直到迁移完所有项目，此时我们将生成仅 .NET Core 程序集。这使我们能够使用.NET Core中可用的新优点，而不必坚持使用.NET Framework和.NET Core之间常见的功能。
转换进度
在撰写本文时，我们已经成功地迁移了基板存储库中的 1061 个程序集。这些转换使我们能够在.NET Core上运行以下服务：
- POP3 服务
- IMAP4 服务
- Mapi-Http 应用程序池
- MSExchangeTransportLogSearch Service
- MSExchangeTransportStreamingOptics 服务
- 进行中 – EAS 在 http.sys
- 我们的测试和验证系统
迁移到 .NET Core 的一个重大挑战是，我们引用了大量 NuGet 包（包括 MSFT 内部和外部）。在某些情况下，当有问题的软件包中没有.NET Standard 2.0或.NET Core产品时，必须追捕这些软件包的所有者。这向我们展示了保持包所有权的最新映射的重要性。
流程迁移
应该注意的是，我们已经构建了许多新的 .NET Core 应用，但考虑到这些应用不是迁移，因此我们没有前/后数字可以比较。下面我们将深入探讨已完成的迁移及其结果。
Pop3
POP3 是一项 Windows 服务，它实现用于邮箱数据检索的 POP3 协议。下表显示了我们在此过程中针对多个指标遇到的改进。
有趣的是，这些性能优势不包括迁移到更现代的 .NET 概念，如 Span 和 Memory。一旦我们这样做，我们期望进一步节省。
Imap4
我们的IMAP4进程的迁移方式与POP3略有不同，因此很难获得良好的.NET Framework到.NET Core的比较，但是最近我们刚刚将IMAP4从.NET 5提升到.NET 6，并注意到由于升级而提高了性能，如下表所示：
使用 .NET 6 后，CPU 和内存使用率都较低。虽然 IMAP4 代码中还有其他一些更改有助于提高性能，但 .NET 6 很可能是主要贡献者。
Mapi Http
MapiHttp 是基于 IIS 的应用池，已迁移到基于 Kestrel 的应用程序。对于MapiHttp，我们测量了以下改进：
cso
CSO 是一个 .NET Core 6，基于 Kestrel 的 gRPC 服务，位于 Exchange 存储之上。它旨在向数据中心内的其他节点公开快速访问协议（与RPC相反，RPC对于开箱即用的通信非常健谈）。鉴于CSO最初是作为.NET Core应用程序创建的，因此我们无法显示与.NET Framework版本的任何比较。但是，一个显示显著改进的 CSO 方案是项目查询，我们从邮箱数据库获取分页视图。我们将 REST API（ASP.NET，NET Framework RESTful 服务）中现有的 Item Query 功能与我们的 CSO、基于 kestrel 的 gRPC 解决方案进行了比较。结果给我们留下了深刻的印象，包括以下内容：
值得注意的是，这不是一个苹果对苹果的比较。这是一个不同的服务，它使用gRPC，它是使用较新的构造编写的，并且考虑到了效率。尽管如此，使该服务性能比其前身好得多的许多功能可以归因于.NET Core和相关产品（gRPC，Kestrel等）。
前进
鉴于迁移到 .NET Core 具有令人印象深刻的性能优势，我们的北极星目标是将所有基板进程迁移到 .NET Core，并移动所有内部微服务以使用 gRPC 进行通信。此外，我们的构建团队实现的基础结构更改将使此大型产品在 .NET 版本可用时保持在最前沿，以确保我们以最佳水平运行，并为客户提供最大的性能优势。
