Путь Microsoft Teams к .NET Core

Microsoft Teams "MiddleTier" — это внутренняя служба, поддерживающая различные сценарии в Microsoft Teams. Это одна из крупнейших служб, состоящая из более чем 700 API, которые поддерживаются более чем 10 командами Microsoft. За последние два года более 50 проектов (библиотеки, тесты, приложения) в рамках этой услуги были преобразованы в .NET Standard 2.0 и .NET Core 3.1, имеющие функциональную эквивалентность и производительность (или лучше), и теперь почти полностью работают на .NET Core 3.1 в производственной среде, планируется переход на .NET 6. До этой миграции служба работала в .NET Framework 4.6.2 с использованием конвейера MVC ASP.NET Core 2.2. Она работает в Azure Service Fabric с развертыванием в 35 центрах обработки данных Azure.

Область этой миграции велика, поскольку MiddleTier — служба очень большого размера в аспекте предоставляемой функциональности благодаря сотням разработчиков, которые ежедневно трудятся над ней.

Мотивация миграции

Команда была заинтересована в переходе на .NET Core 3.1 по следующим причинам:

• Повышение производительности и экономической эффективности
• Платформа .NET Framework 4.6.2, видимо, скоро будет выведена из употребления
• Кроссплатформенная поддержка
• Переход на современную платформу для лучшего взаимодействия с разработчиком

Преимущества после перехода на .NET Core 3.1

После перехода на .NET Core 3.1 команда заметила следующие улучшения:

• Улучшение ЦП на 25%
• Сокращение затрат на инфраструктуру примерно на 25%
• Улучшено использование пула потоков
• Сокращение технического долга и усилий по переходу на ежегодные выпуски .NET.

На следующих диаграммах показано сравнение между .NET Framework и .NET Core. В будущем, с .NET 6, мы должны увидеть еще больше улучшений.

Подход

Общая миграция была разделена на три этапа:

Они также выбрали многоцелевое приложение для .NET Framework и .NET Core, чтобы у них были доступны оба двоичных файла, и они могли продолжать медленное развертывание .NET Core.

Обучение

OData и другие REST API не могут совместно использовать префикс маршрута

Их служба также имеет несколько конечных точек OData и множество конечных точек REST. Эти двое используют один и тот же префикс маршрутизации для конечных точек. Раньше это нормально работало в .NET Framework, но из-за изменений маршрутизации перестало работать в .NET Core. Чтобы решить эту проблему, им пришлось переместить API-интерфейсы OData на другой префикс маршрута.

Проблемы производительности с клиентскими библиотеками OData

HttpWebRequest с клиентами OData для выполнения вызовов нижестоящих API-интерфейсов OData приводит к большей задержке по сравнению с .NET Framework. Это произошло из-за регрессии в .NET Core, когда платформа не кэширует соединения. Это уже решено в более новых версиях .NET.

Проблемы с пакетами SDK служебной шины Azure

Пакет SDK служебной шины Azure необходимо было обновить в рамках этой миграции, поскольку старая версия не совместима с .NET Standard. Последняя версия SDK служебной шины Azure отправляет полезные данные запроса в формате JSON, тогда как старый SDK отправляет полезные данные в формате XML. Чтобы продолжить использование полезной нагрузки XML, им пришлось использовать DataContractSerializer.

Проблемы в проекте Service Fabric для множественного таргетинга

Проект Service Fabric (sfproj) по своей сути не поддерживает множественное нацеливание. Им пришлось использовать обходные пути в конвейере сборки, чтобы создать пакеты Service Fabric для обеих целевых платформ.

Проблемы со старой версией MimeKit NuGet

Старая версия MimeKit может иметь проблемы с двухбайтовыми символами, поэтому в этом случае рекомендуется проверка для конкретного языка. Они обнаружили аналогичные проблемы при развертывании развертываний, расположенных в азиатской географии.

Классические особенности ASP.NET

• Пришлось отказаться от использования некоторых классов .NET Framework, которые были помечены как внутренние в .NET Core.
• Асинхронный суффикс MVC удален из имен действий, как указано в статье Критические изменения ASP.NET Core для версий 3.0 и 3.1. Если какой-либо из путей к коду зависит от имени действия, это может привести к изменению поведения.
• Синхронные операции ввода-вывода по умолчанию отключены на всех серверах, начиная с .NET Core 3.0, как указано в проблеме dotnet/aspnetcore#7644 GitHub.
• Заголовок Content-Length не задан в Content.Headers при отправке StreamContent в виде содержимого HTTP-запроса. Это может привести к ошибкам от нижестоящих вызовов.
• Платформа .NET создает стабильный хэш-код для строки, а .NET Core — нет.
• Required из пространства имен System.ComponentModel.DataAnnotations ведет себя в .NET Core иначе. В .NET Framework этот атрибут не выполняет проверку модели для полей, отличных от NULL, но в .NET Core делает это.

Будущее

Каждый новый выпуск .NET содержит потрясающие улучшения производительности и продуктивности, которые все так же хорошо помогают достичь целей по сборке устойчивых, масштабируемых, производительных и надежно защищенных служб. Мы проведем обновление до .NET 6., чтобы по-прежнему использовать улучшения, внесенные в .NET.