Le parcours de Microsoft Teams vers .NET Core

Microsoft Teams "MiddleTier" est un service interne qui alimente divers scénarios dans Microsoft Teams. C'est l'un des plus grands services composé de plus de 700 API gérées par plus de 10 équipes Microsoft. Au cours des deux dernières années, plus de 50 projets (bibliothèques, tests, applications) dans le cadre de ce service ont été convertis en .NET Standard 2.0 et .NET Core 3.1, ayant une équivalence fonctionnelle et de performances (ou mieux), et fonctionnent désormais presque entièrement sur .NET Core 3.1 en production et envisage de passer ensuite à .NET 6. Avant cette migration, le service s'exécutait sur .NET Framework 4.6.2 à l'aide du pipeline MVC ASP.NET Core 2.2. Il s'exécute sur Azure Service Fabric avec des déploiements dans 35 centres de données Azure.

La portée de cette migration était importante car MiddleTier est un service extra-large en termes de fonctionnalités qu'il fournit avec des centaines de développeurs qui y travaillent chaque jour.

Motivation pour la migration

L'équipe était motivée pour passer à .NET Core 3.1 pour les raisons suivantes :

• Améliorations des performances et de la rentabilité
• .NET Framework 4.6.2 arrive probablement bientôt en fin de vie
• Support multiplateforme
• Passez à un framework moderne pour une meilleure expérience développeur

Avantages après la migration vers .NET Core 3.1

Après la migration vers .NET Core 3.1, l'équipe a remarqué les améliorations suivantes :

• 25 % d'amélioration du processeur
• Environ 25 % de réduction des coûts d'infrastructure
• Amélioration de l'utilisation du pool de threads
• Réduction de la dette technique et des efforts pour passer aux versions annuelles de .NET

Les graphiques suivants montrent des comparaisons entre .NET Framework et .NET Core. À l'avenir, avec .NET 6, nous devrions voir encore plus d'améliorations.

Approche

La migration globale a été divisée en trois étapes :

Ils ont également choisi de cibler plusieurs fois l'application sur .NET Framework et .NET Core afin de disposer des deux fichiers binaires et de continuer à déployer .NET Core lentement.

Formations

OData et les autres API REST ne peuvent pas partager le préfixe de route

Leur service a également quelques points de terminaison OData ainsi que de nombreux points de terminaison REST. Ces deux partageaient le même préfixe de routage pour les points de terminaison. Cela fonctionnait bien dans .NET Framework, mais en raison de modifications de routage, cela a cessé de fonctionner dans .NET Core. Ils ont dû déplacer les API OData vers un autre préfixe de route pour résoudre ce problème.

Problèmes de performances avec les bibliothèques clientes OData

Le modèle HttpWebRequest avec les clients OData pour effectuer des appels vers les API OData en aval entraîne une latence plus élevée par rapport à .NET Framework. Cela était dû à une régression dans .NET Core dans laquelle le framework ne met pas en cache les connexions. Ceci est déjà résolu dans les nouvelles versions de .NET.

Problèmes avec les SDK Azure Service Bus

Le SDK Azure Service Bus a dû être mis à niveau dans le cadre de cette migration car l'ancienne version n'est pas compatible avec .NET Standard. La dernière version du SDK Azure Service Bus envoie la charge utile de la requête au format JSON alors que le l'ancien SDK envoie la charge utile au format XML. Pour continuer à utiliser la charge utile XML, ils devaient utiliser le DataContractSerializer.

Problèmes dans le projet Service Fabric pour le ciblage multiple

Le projet Service Fabric (sfproj) ne prend pas en charge le multi-ciblage de manière inhérente. Ils ont dû effectuer des solutions de contournement dans le pipeline de build pour produire des packages Service Fabric pour les deux frameworks cibles.

Problèmes avec l'ancienne version de MimeKit NuGet

L'ancienne version de MimeKit peut avoir des problèmes avec les caractères à deux octets, une validation spécifique à la langue est donc conseillée dans ce scénario. Ils ont découvert des problèmes similaires lors du déploiement dans des déploiements situés dans la géographie asiatique.

Erreurs de ASP.NET classiques

• A dû supprimer l'utilisation de certaines des classes .NET Framework qui étaient marquées comme internes dans .NET Core.
• Le suffixe asynchrone MVC a été supprimé des noms d'action, comme mentionné dans l'article modifications avec rupture d'ASP.NET Core pour les versions 3.0 et 3.1. Si l'un des chemins de code dépend du nom de l'action, cela peut entraîner un changement de comportement.
• Les opérations d'E/S synchrones sont désactivées par défaut sur tous les serveurs à partir de .NET Core 3.0, comme indiqué dans le problème dotnet/aspnetcore#7644 GitHub.
• L'en-tête Content-Length n'est pas défini dans Content.Headers lors de l'envoi de StreamContent en tant que contenu de requête HTTP. Cela peut entraîner des erreurs dans les appels en aval.
• Le framework .NET produit un code de hachage stable pour une chaîne, mais pas .NET Core.
• L'attribut Required de l'espace de noms System.ComponentModel.DataAnnotations se comporte différemment dans .NET Core. Sur .NET Framework, cet attribut n'effectue aucune validation de modèle pour les champs non nuls, mais sur .NET Core, il le fait.

À venir

Chaque nouvelle version de .NET s'accompagne d'améliorations considérables de la productivité et des performances qui continuent d'aider à atteindre nos objectifs de création de services résilients, évolutifs, performants et sécurisés. L'équipe continuera à tirer parti des améliorations apportées à .NET en passant ensuite à .NET 6.