Cliente
Microsoft Teams (Microsoft)
Produtos e serviços
ASP.NET Core 3.1
Setor
Tecnologia
Tamanho da Organização
Grande (mais de 1000 funcionários)
País/região
EUA
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.
A equipe foi motivada a migrar para o .NET Core 3.1 pelos seguintes motivos:
Depois de migrar para o .NET Core 3.1, a equipe observou as seguintes melhorias:
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.
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.
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.
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.
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.
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.
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.
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.
Nosso tutorial passo a passo ajudará você a executar ASP.NET no computador.