Путь Microsoft Teams к .NET Core
Клиент
Microsoft Teams (Microsoft)
Продукты и службы
ASP.NET Core 3.1
Промышленность
Технологии
Размер организации
Большой (1000+ сотрудников)
Страна/регион
США
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.
Готовы приступить?
Наше пошаговое руководство поможет вам запустить ASP.NET на вашем компьютере.