Recorrido de Microsoft Teams a .NET Core

Microsoft Teams " MiddleTier" es un servicio interno que potencia varios escenarios en Microsoft Teams. Es uno de los servicios más grandes que consta de más de 700 API que mantienen más de 10 equipos de Microsoft. En los últimos dos años, más de 50 proyectos (bibliotecas, pruebas, aplicaciones) de este servicio se han convertido a .NET Standard 2.0 y .NET Core 3.1, con equivalencia funcional y de rendimiento (o superior), y ahora se ejecutan casi por completo en .NET Core 3.1 en producción y quieren pasar a .NET 6 a continuación. Antes de esta migración, el servicio se ejecutaba en .NET Framework 4.6.2 mediante la canalización de ASP.NET Core 2.2 MVC. Se ejecuta en Azure Service Fabric con implementaciones en 35 centros de datos de Azure.

El ámbito de esta migración era grande porque MiddleTier es un servicio muy grande en cuanto a la funcionalidad que proporciona a cientos de desarrolladores que trabajan en ella cada día.

Motivación para la migración

El equipo ha estado motivado para migrar a .NET Core 3.1 por los siguientes motivos:

• Mejoras de rendimiento y rentabilidad
• Probablemente, .NET Framework 4.6.2 llegue pronto al final del ciclo de vida
• Funcionalidad multiplataforma
• Pasar a un marco moderno para mejorar la experiencia del desarrollador

Ventajas después de migrar a .NET Core 3.1

Después de migrar a .NET Core 3.1, el equipo ha observado las siguientes mejoras:

• Mejora del 25 % de la CPU
• Reducción en torno al 25 % del costo de infraestructura
• Uso mejorado del grupo de subprocesos
• Reducción de la deuda técnica y los esfuerzos para pasar a las versiones anuales de .NET

En los gráficos siguientes, se muestran comparaciones entre .NET Framework y .NET Core. En el futuro, con .NET 6, deberíamos ver aún más mejoras.

Enfoque

La migración general se ha dividido en tres fases:

Asimismo, han optado por usar varios destinos para la aplicación para .NET Framework y .NET Core para que tuvieran ambos archivos binarios disponibles y pudieran seguir implementándolo lentamente.

Aprendizajes

OData y otras API de REST no pueden compartir el prefijo de ruta

Su servicio tiene pocos puntos de conexión de OData y muchos puntos de conexión de REST. Estos dos han compartido el mismo prefijo de enrutamiento para los puntos de conexión. Se ha usado para funcionar correctamente en .NET Framework pero, debido a los cambios de enrutamiento, ha dejado de funcionar en .NET Core. Han tenido que mover las API de OData a un prefijo de ruta diferente para resolverlo.

Problemas de rendimiento con las bibliotecas cliente de OData

El patrón HttpWebRequest con clientes OData para realizar llamadas a API de OData que siguen en la cadena provoca una latencia mayor en comparación con .NET Framework. Esto se debe a una regresión en .NET Core en la que el marco no almacena en caché las conexiones. Esto ya se ha resuelto en versiones más recientes de .NET.

Problemas con los SDK de Azure Service Bus

El SDK de Azure Service Bus ha tenido que actualizarse como parte de esta migración, debido a que la versión anterior no es compatible con .NET Standard. La versión más reciente del SDK de Azure Service Bus envía la carga de solicitud en formato JSON, mientras que el SDK anterior envía la carga en formato XML. Para seguir usando la carga XML, han tenido que usar el DataContractSerializer.

Problemas en el proyecto Service Fabric para la selección de varios destinos

El proyecto Service Fabric (sfproj) no admite la compatibilidad con múltiples destinos de forma inherente. Han debido realizar soluciones alternativas en la canalización de compilación para generar paquetes de Service Fabric para ambas plataformas de destino.

Problemas con la versión anterior de MimeKit NuGet

La versión anterior de MimeKit puede tener problemas con los caracteres de doble byte, por lo que se recomienda la validación específica del lenguaje en este escenario. Se han detectado problemas similares cuando se lanzaron en implementaciones ubicadas en la geografía de Asia.

Clásicas peculiaridades de ASP.NET

• Ha tenido que quitar el uso de algunas de las clases de .NET Framework marcadas como internas en .NET Core.
• El sufijo asincrónico MVC se ha quitado de los nombres de acción como se ha mencionado en el artículo cambios importantes de ASP.NET Core para las versiones 3.0 y 3.1. Si alguna de las rutas de acceso de código depende del nombre de la acción, esto puede provocar un cambio en el comportamiento.
• Las operaciones de E/S sincrónicas están desactivadas de forma predeterminada en todos los servidores que empiezan en .NET Core 3.0, como se menciona en el dotnet/aspnetcore#7644 problema de GitHub.
• Encabezado Content-Length no establecido en Content.Headers al enviar StreamContent como contenido de solicitud HTTP. Puede dar lugar a errores en el caso de las llamadas que siguen en la cadena.
• .NET Framework genera código hash estable para una cadena, pero .NET Core no lo hace.
• El atributo Required del espacio de nombres System.ComponentModel.DataAnnotations se comporta de forma diferente en .NET Core. En .NET Framework, este atributo no realiza ninguna validación de modelo para campos que no tienen valores nulos, pero en .NET Core sí lo hace.

Posteriormente

Cada nueva versión de .NET incluye enormes mejoras de productividad y rendimiento que siguen contribuyendo a lograr nuestros objetivos para crear servicios resistentes, escalables, de rendimiento y seguros. El equipo seguirá aprovechando las mejoras realizadas en .NET mediante la actualización a .NET 6 siguiente.