Путь Microsoft Teams к .NET Core

Область этой миграции велика, поскольку 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 делает это.