Bing 广告平台迁移到 .net6 _生活百科

广告组件平台对于微软搜索平台能给用户提供好的用户体验至关重要，这个平台支持超过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 包【Bing 广告平台迁移到 .net6】这个最需要花费时间了，对于开源的不支持.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 并重新编译。