交换 .NET Core 的在线旅程

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 版本可用时保持在最前沿,以确保我们以最佳水平运行,并为客户提供最大的性能优势。

给TA打赏
共{{data.count}}人
人已打赏
.Net Core

陈计节-使用 .NET Core 开发 Kubernetes 基础组件(下篇)

2022-6-6 12:07:22

.Net Core

ASP.NET Core技术内幕与项目实战 ——基于DDD与前后端分离【杨中科最新力作】

2022-6-29 19:22:49

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
今日签到
有新私信 私信列表
搜索