Percorso di Microsoft Teams verso .NET Core

Microsoft Teams "MiddleTier" è un servizio interno che gestisce vari scenari in Microsoft Teams. Si tratta di uno dei servizi più grandi costituiti da oltre 700 API gestite da più di 10 team Microsoft. Negli ultimi due anni, più di 50 progetti (librerie, test, applicazioni) di questo servizio sono stati convertiti in .NET Standard 2.0 e .NET Core 3.1, con equivalenza funzionale e delle prestazioni (o versione successiva) e sono ora quasi interamente in esecuzione in .NET Core 3.1 nell'ambiente di produzione e si sta cercando di passare a .NET 6. Prima di questa migrazione, il servizio era in esecuzione in .NET Framework 4.6.2 usando ASP.NET pipeline MVC core 2.2. Viene eseguito in Azure Service Fabric con distribuzioni in 35 data center di Azure.

L'ambito di questa migrazione è stato esteso perché MiddleTier è un servizio molto grande in termini di funzionalità che fornisce a centinaia di sviluppatori che la lavorano ogni giorno.

Motivazione per la migrazione

Il team è stato giustificato a passare a .NET Core 3.1 per i motivi seguenti:

• Miglioramenti delle prestazioni e dell'efficienza dei costi
• .NET Framework 4.6.2 sta per raggiungere la fine del ciclo vitale
• Supporto multipiattaforma
• Passa a un framework moderno per una migliore esperienza di sviluppo

Vantaggi dopo la migrazione a .NET Core 3.1

Dopo la migrazione a .NET Core 3.1, il team ha notato i miglioramenti seguenti:

• Miglioramento della CPU del 25%
• Riduzione 25% circa del costo dell'infrastruttura
• Miglioramento dell'utilizzo del pool di thread
• Riduzione del debito tecnico e degli sforzi per passare alle versioni annuali di .NET

I grafici seguenti mostrano i confronti tra .NET Framework e .NET Core. In futuro, con .NET 6, verranno apportati altri miglioramenti.

Approccio

La migrazione complessiva è stata suddivisa in tre fasi:

Hanno anche scelto di impostare come destinazione multipla l'applicazione per .NET Framework e .NET Core in modo che abbiano entrambi i file binari disponibili e possano continuare a implementare .NET Core lentamente.

Percorsi di apprendimento

OData e altre API REST non possono condividere il prefisso della route

Il servizio include alcuni endpoint OData e molti endpoint REST. Questi due hanno condiviso lo stesso prefisso di routing per gli endpoint. Questa operazione funzionava correttamente in .NET Framework ma a causa delle modifiche al routing, il funzionamento in .NET Core non funzionava più. Per risolvere questo errore, è stato necessario spostare le API OData in un prefisso di route diverso.

Problemi di prestazioni con le librerie client OData

Il modello HttpWebRequest con i client OData per effettuare chiamate alle API OData downstream comporta una latenza più elevata rispetto a .NET Framework. Ciò è dovuto a una regressione in .NET Core in cui il framework non memorizza nella cache le connessioni. Questo problema è già stato risolto nelle versioni più recenti di .NET.

Problemi con gli SDK di bus di servizio di Azure

È stato necessario aggiornare bus di servizio di Azure SDK come parte di questa migrazione perché la versione precedente non è .NET Standard compatibile. La versione più recente di bus di servizio di Azure SDK invia il payload della richiesta in formato JSON, mentre l'oder SDK invia il payload in formato XML. Per continuare a usare il payload XML, è stato necessario usare il DataContractSerializer.

Problemi di Service Fabric progetto per il multitargeting

Il progetto Service Fabric (sfproj) non supporta intrinsecamente la multitargeting. Dovevano eseguire soluzioni alternative nella pipeline di compilazione per produrre pacchetti Service Fabric per entrambi i framework di destinazione.

Problemi con la versione precedente di MimeKit NuGet

La versione precedente di MimeKit può avere problemi con i caratteri a byte doppio, pertanto in questo scenario è consigliata la convalida specifica del linguaggio. Sono stati rilevati problemi simili durante l'implementazione nelle distribuzioni che si trovano nell'area geografica asiatica.

ASP.NET classici

• È stato necessario rimuovere l'utilizzo di alcune delle classi .NET Framework contrassegnate come interne in .NET Core.
• Il suffisso asincrono MVC è stato eliminato dai nomi delle azioni come indicato nell’articolo modifiche ASP.NET Core che causano un'interruzione per le versioni 3.0 e 3.1. Se uno dei percorsi di codice dipende dal nome dell'azione, può causare una modifica del comportamento.
• Le operazioni di I/O sincrone sono disattivate per impostazione predefinita in tutti i server a partire da .NET Core 3.0, come indicato nel problema di GitHub dotnet/aspnetcore#7644.
• L'intestazione Content-Length non è impostata in Content.Headers quando si invia StreamContent come contenuto della richiesta HTTP. Può causare errori dalle chiamate downstream.
• .NET Framework produce codice hash stabile per una stringa, ma .NET Core no.
• L'attributo Required dello spazio dei nomi System.ComponentModel.DataAnnotations si comporta in modo diverso in .NET Core. In .NET Framework, questo attributo non esegue alcuna convalida del modello per i campi non Null, ma in .NET Core lo fa.

Futuri

Ogni nuova versione di .NET include straordinari miglioramenti della produttività e delle prestazioni che contribuiscono al raggiungimento dei nostri obiettivi per creare servizi resilienti, scalabili, performanti e sicuri. Il team continuerà a sfruttare i miglioramenti apportati a .NET eseguendo successivamente l'aggiornamento a .NET 6.