广告组件平台对于微软搜索平台能给用户提供好的用户体验至关重要，这个平台支持超过450000个广告商允许他们创建广告。

在一秒钟内，该平台处理数千个web请求，而且时延不超过100毫秒。

支撑这个平台的是几十个分布式服务，现在这些服务都要构建在.net 6 之上，运行在微软自己的AKS云服务的Linux容器中。

要实现这一目的其实并不容易，博文后面部分就介绍多年来我们将代码升级到.net 6所面临的挑战以及如何解决的。（注意：.net core 现在已经统一到.net 平台，这里提到.net 都指.net core,如果是.net framework 会明确指出）

代码仓库概述

我们有超级多的代码，光c#项目就超过600个,一下就是分解以后的代码占比图

我们有超过800万行代码，其中c#超过了700万行，统计代码行数虽然不能说明代码仓库的全部，但是可以给出一个粗略的印象我们有多大的工作量要搞。在这超过600多个的项目中，我们引用了500多个不同的nuget包，而且很多依赖项会对迁移产生影响。

我们的出发点

多年来我们的服务发生了很大的变化，而且托管他们的基础设施也发生了巨变，从物理机到云服务。以前我们是在windows服务托管在iis上，此外我们还有大量服务构建使用wcf，这是问题的复杂所在。所以最开始我们的迁移只是从物理机的windows服务迁移到了云上的windows 虚拟机，仍然是windows-only。

为什么迁移到.net(.netcore)

为什么我们要花费两年多时间从.netframework -.net 我们的技术团队给出了以下理由：

跨平台

好处很明显，不用跟windows绑定了。

.Net  代表未来

.net framework 4.8 是计划更新的 最后一个版本，很多新的特性，以及性能优化的创新都只能在.net 上可用，坚持.net framework 死路一条。

开源

更好用的工具

dotnet cli 工具无需IDE借助命令行终端就可以完成很多工作，其他的感觉不是工具，就不列举了。

我们的迁移过程

对于类库：

.NET Framework 4.6 -> .NET Framework 4.7 -> .NET Standard 2.0

对于应用：

.NET Framework 4.6 -> .NET Framework 4.7 -> .NET Core 3.1 -> .NET 5 -> .NET 6

.NET Standard

简单理解这是一个提供了一部分公共api抽象的定义，在.net framework 跟.net 会有相应的实现。

挑战

主要是我们依赖的那500多个包如果更新了会有很多break changes，比如Unity这个IOC库，支持 .NET Standard 的可用版本已经完全重写了其 API，我们必须更新数万行代码才能与这些更改兼容。

绑定重定向地狱

WCF

我们重度依赖 WCF，超过45 个服务构建在wcf之上，但是现在普遍看法是基于REST的服务是未来，但是我们不能这样，因为我们有无数个现有客户大量构建在这些 WCF 服务之上，并使用我们的 SDK 直接调用它们，告诉我们的付费客户，嘿，你得用GRPC这类新东西冲洗你的客户端，这显然不现实，所以这是一个大问题。

解决问题

不兼容的Nuget 包

这个最需要花费时间了，对于开源的不支持.net standard 的我们在内部自己打一个补丁包使得支持，对于不开源的我们也会选择反编译使得与.net standard 兼容。

绑定重定向问题

WCF

最终，微软决定针对.Net d的wcf有限子集开源Core wcf捐献给开源社区。CoreWCF 对来自传统 WCF 的 System.ServiceModel 命名空间的许多现有类型使用全新的命名空间，因此转换现有服务并非易事。此外，我们的代码库中使用了如此广泛的通用代码，以至于我们需要在转换过程中支持在 CoreWCF 服务和 .NET Framework 服务中运行该代码。我们最终使用multi-targeting （在代码中可以使用条件编译指定不同平台实现不同代码，在工程文件中指定目标平台使用TargetFrameworks，这样可以指定多个）来实现这一目标。过程很艰辛，单总算迁移完了，所以如果您需要托管 SOAP 服务并且想要在 .NET 6 上运行所带来的高性能，那么 CoreWCF 是一个很好的答案。

结果

性能层面

值得吗？做了这么多答案是肯定的。这图显示了我们的一项服务的延迟改进，这仅仅是由于将其更改为目标 .NET 并重新编译。

这甚至没有任何新的功能做任何优化，这些都是.net 团队做的运行时级别的改进，下图是另一个例子，我们迁移到Core wcf 以后内存使用情况

现代服务架构

除了这些明显的性能优势之外，进入 .NET 为我们提供了从 IIS 和 Windows 迁移到在 AKS 中托管的 Linux 容器内运行的 Kestrel 服务器的机会，我们现在可以使用所有可用于管理和配置云服务的现代化工具和资源(比如K8s）

总结

对于计划将大型现有 .NET Framework 代码库迁移到 .NET 6 及更高版本的其他人，可以应用从我们的经验中吸取的教训：

1. 现有代码从4.7 升级到4.8

2. 将所有项目迁移到新的 SDK 格式，以便它们在执行任何其他操作之前使用 PackageReference。（说实话我忘了.net framework 是咋回事了，所以上面这块儿原文也没怎看就没翻译）

3. 使用 .NET Standard 作为桥梁，允许在迁移过程中在 .NET Framework 和 .NET 项目之间共享库代码

4. 使用集中的包引用来极大地简化向较新 NuGet 包的过渡。

迁移完成了，我们的脚步并没有停下，接下来我们会研究.net的一些新的特性：

1. 找到我们可以使用 Span\<T> 来减少堆分配并提高性能的地方，例如，我们的代码有一些地方可以检查两个字节缓冲区是否相同。我们可以使用高度优化的 SequenceEqual 方法，而不是遍历每个字节并测试相等性

```return bufferA.AsSpan().SequenceEqual(bufferB);```

以下是benchmark

随着我们的前进，重写我们的一些代码以专门利用新的语言和运行时特性，这将继续是一项有趣且非常有益的练习

标签：