Percurso do Microsoft Teams para o .NET Core

Microsoft Teams " MiddleTier" é um serviço interno que habilita vários cenários no Microsoft Teams. É um dos maiores serviços que consistem em mais de 700 APIs que são mantidas por mais de 10 equipes na Microsoft. Nos últimos dois anos, mais de 50 projetos (bibliotecas, testes, aplicativos) sob esse serviço foram convertidos para o .NET Standard 2.0 e o .NET Core 3.1, tendo equivalência funcional e de desempenho (ou melhor) e agora estão quase totalmente em execução no .NET Core 3.1 em produção e procurando mudar para o .NET 6 em seguida. Antes dessa migração, o serviço era executado no .NET Framework 4.6.2 usando o pipeline ASP.NET Core 2.2 MVC. Ele é executado no Azure Service Fabric com implantações em 35 datacenters do Azure.

O escopo dessa migração era grande porque o MiddleTier é um serviço extra grande em termos da funcionalidade que fornece com centenas de desenvolvedores que trabalham nele todos os dias.

Motivação para migração

A equipe foi motivada a migrar para o .NET Core 3.1 pelos seguintes motivos:

• Melhorias de desempenho e eficiência de custo
• .NET Framework 4.6.2 provavelmente atingirá o fim da vida útil em breve
• Suporte multiplataforma
• Migre para uma estrutura moderna para uma melhor experiência do desenvolvedor

Benefícios após a migração para o .NET Core 3.1

Depois de migrar para o .NET Core 3.1, a equipe observou as seguintes melhorias:

• Melhoria de 25% na CPU
• Redução de cerca de 25% no custo da infraestrutura
• Uso aprimorado do pool de threads
• Redução da dívida técnica e dos esforços na migração para versões anuais do .NET

Os gráficos a seguir mostram comparações entre .NET Framework e o .NET Core. No futuro, com o .NET 6, devemos ver ainda mais melhorias.

Abordagem

A migração geral foi dividida em três estágios:

Eles também optaram por aplicar vários destinos ao aplicativo .NET Framework e .NET Core para que eles tenham os dois binários disponíveis e possam continuar a distribuir o .NET Core lentamente.

Aprendizados

OData e outras APIs REST não podem compartilhar o prefixo de rota

O serviço deles também tem poucos pontos de extremidade OData, juntamente com muitos pontos de extremidade REST. Esses dois compartilharam o mesmo prefixo de roteamento para os pontos de extremidade. Isso funcionava bem no .NET Framework, mas devido a alterações de roteamento, isso parou de funcionar no .NET Core. Eles tiveram que mover as APIs OData para um prefixo de rota diferente para resolver isso.

Problemas de desempenho com bibliotecas de cliente OData

O padrão HttpWebRequest com clientes OData para fazer chamadas para APIs OData downstream resulta em latência mais alta em comparação com .NET Framework. Isso ocorreu devido a uma regressão no .NET Core na qual a estrutura não armazena conexões em cache. Isso já foi resolvido em versões mais recentes do .NET.

Problemas com Barramento de Serviço do Azure SDKs

O Barramento de Serviço do Azure SDK precisava ser atualizado como parte dessa migração, pois a versão antiga não é .NET Standard compatível. A versão mais recente do Barramento de Serviço do Azure SDK envia a carga de solicitação no formato JSON, enquanto o SDK mais antigo envia a carga em formato XML. Para continuar usando o conteúdo XML, eles tinham que usar o DataContractSerializer.

Problemas Service Fabric projeto para direcionamento múltiplo

O Service Fabric Project (sfproj) não dá suporte inerentemente a multi-direcionamento. Eles tinham que fazer soluções alternativas no pipeline de build para produzir Service Fabric pacotes para ambas as estruturas de destino.

Problemas com a versão mais antiga do MimeKit NuGet

A versão mais antiga do MimeKit pode ter problemas com caracteres de byte duplo, portanto, a validação específica do idioma é aconselhável nesse cenário. Eles descobriram problemas semelhantes quando foram distribuídos para implantações localizadas na geografia asiático.

Características ASP.NET clássicas

• Foi necessário remover o uso de algumas das classes .NET Framework que foram marcadas como internas no .NET Core.
• Sufixo assíncrono MVC removido dos nomes de ação, conforme mencionado no artigo Principais alterações interruptivas do ASP.NET para as versões 3.0 e 3.1. Se qualquer um dos caminhos de código depender do nome da ação, isso poderá causar uma alteração no comportamento.
• As operações de E/S síncronas são desativadas por padrão em todos os servidores a partir do .NET Core 3.0, conforme mencionado no problema do GitHub dotnet/aspnetcore#7644.
• Cabeçalho Content-Length não definido em Content.Headers ao enviar StreamContent como conteúdo de solicitação HTTP. Isso pode resultar em erros de chamadas downstream.
• O .NET Framework produz código hash estável para uma cadeia de caracteres, mas o .NET Core não.
• O atributo Obrigatório do namespace System.ComponentModel.DataAnnotations se comporta de maneira diferente no .NET Core. No .NET Framework, esse atributo não faz nenhuma validação de modelo para campos não nulos, mas sim no .NET Core.

Futuro

Cada nova versão do .NET vem com enormes melhorias de produtividade e desempenho que continuam a ajudar a atingir nossas metas para criar serviços resilientes, escalonáveis, de alto desempenho e seguros. A equipe continuará a aproveitar as melhorias feitas no .NET atualizando para o .NET 6 em seguida.