Модернизация существующих приложений .NET с помощью облака Azure и контейнеров Windows

Обновления книги и вклад сообщества см. в журнале изменений.

ОПУБЛИКОВАНО отделами Microsoft Press и Microsoft DevDiv корпорации Майкрософт, One Microsoft Way, Redmond, Washington 98052-6399

© Корпорация Майкрософт (Microsoft Corporation), 2022 г.

Все права защищены. Запрещается полное или частичное воспроизведение настоящей книги в любом виде или любыми средствами без письменного разрешения издателя.

Эту книгу можно получить бесплатно в электронном виде по нескольким каналам Майкрософт, например на сайте https://dot.net/architecture.

Если у вас есть вопросы, связанные с этой книгой, обращайтесь по адресу dotnet-architecture-ebooks-feedback@service.microsoft.com.

Эта книга предоставляется на условиях "как есть" и выражает взгляды и мнения автора. Взгляды, мнения и сведения, содержащиеся в этой книге, включая URL-адреса и другие ссылки на веб-сайты, могут изменяться без уведомления.

Некоторые приведенные в книге примеры служат только для иллюстрации и являются вымышленными. Все совпадения с реальными наименованиями, людьми и любыми другими предметами являются непреднамеренными и случайными.

Microsoft и товарные знаки, перечисленные на странице "Товарные знаки" на сайте https://www.microsoft.com, являются товарными знаками группы компаний Майкрософт. Все другие наименования являются собственностью своих законных владельцев.

Сезар де ла Торре (Cesar de la Torre), старший руководитель проекта, команда разработки .NET, корпорация Майкрософт.

Участники и рецензенты:

Скотт Хантер (Scott Hunter), директор-партнер по управлению проектами, отдел .NET, Майкрософт; Пол Юкневич (Paul Yuknewicz), ведущий руководитель проектов, отдел Инструментов Visual Studio, Майкрософт; Лиза Гатри (Lisa Guthrie), старший руководитель проектов, отдел Инструментов Visual Studio, Майкрософт; Анкит Астана (Ankit Asthana), ведущий руководитель проектов, отдел .NET, Майкрософт; Унаи Соррилья (Unai Zorrilla), руководитель группы разработчиков, Plain Concepts; Хавьер Валеро (Javier Valero), исполнительный директор Grupo Solutio; Стив Смит (Steve Smith), архитектор, NimblePros.

Вступление

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

какие приложения требуется преобразовать или перепроектировать;

какие приложения требуется частично модернизировать;

какие приложения можно сразу же перенести в облако.

Об этом руководстве

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

Здесь также выделяются преимущества переноса приложений в облако и частичной модернизаций приложений с помощью ряда новых технологий и методов, таких как контейнеры Windows и связанные платформы вычислений в контейнерах Windows с поддержкой Azure.

Перенос существующих приложений .NET в облако

Как правило, организации принимают решение о переносе рабочих нагрузок в облако, чтобы обеспечить гибкость и быстродействие приложений. Настройка тысяч серверов (виртуальных машин) в облаке занимает несколько минут, а не недель, требуемых для конфигурации локальных серверов.

Единой и универсальной стратегии перемещения приложений в облако не существует. Оптимальный вариант зависит от потребностей и приоритетов организации и типов переносимых приложений. Не все приложения оправдывают инвестиции в перемещение на платформу как услугу (PaaS) или разработку модели приложения, изначально созданного для облака. Во многих случаях в зависимости от потребностей бизнеса можно применять поэтапный или постепенный подход к инвестированию средств в перемещение активов в облако.

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

На рисунке 1-1 показаны возможные варианты поэтапного переноса существующих приложений .NET в облако.

Рис. 1-1. Варианты модернизации существующих приложений и служб .NET

Каждый вариант миграции имеет различные преимущества и причины использования. Для переноса приложений в облако можно остановиться на одном методе либо выбрать определенные компоненты из нескольких методов. Отдельные приложения поддерживают несколько подходов или состояний зрелости. Например, общий гибридный подход будет включать в себя некоторые компоненты в локальной среде и ряд других компонентов в облаке.

Ниже приведено определение и краткое описание каждого уровня зрелости приложений:

Уровень 1. Приложения, готовые для облачной инфраструктуры. Этот вариант миграции предполагает простое повторное размещение или перенос текущих локальных приложений на платформу инфраструктуры как услуги (IaaS). Приложения имеют почти ту же композицию, что и раньше, но теперь они развертываются на виртуальных машинах в облаке. Такой простой тип миграции, как правило, называется простым переносом.

Уровень 2. Оптимизированные для облака приложения. На этом уровне и по-прежнему без реконструирования или изменения важного кода вы можете получить дополнительные преимущества от запуска приложения в облаке с помощью современных технологий, таких как контейнеры и дополнительные облачные службы. За счет совершенствования корпоративных процессов DevOps повышается гибкость и скорость доставки приложений. Для реализации этих функций можно использовать такую технологию как контейнеры Windows на основе подсистемы Docker. Контейнеры позволяют избежать конфликтов, вызываемых зависимостями приложений при развертывании в несколько этапов. В этой модели зрелости можно развертывать контейнеры в IaaS или PaaS, используя дополнительные облачные службы, связанные с базами данных, кэширование как услугу, мониторинг и непрерывную интеграцию/непрерывное развертывание (CI/CD).

Третий уровень зрелости является конечной целью в облаке, но он необязателен для многих приложений и не служит главной темой этого руководства.

Уровень 3. Приложения, созданные для облака. Этот подход к миграции обычно зависит от бизнес-потребностей и необходимости модернизации критически важных приложений. На этом уровне перемещение приложений на вычислительные платформы PaaS осуществляется с помощью служб PaaS. Вы внедряете архитектуру изначально созданных для облака приложений и микрослужб для формирования приложений с более высокими показателями гибкости и масштабирования. Для этого типа модернизации обычно требуется проектирование специально для облака. Как правило, необходимо создать новый код, особенно при переходе на приложения, изначально созданные для облака, и модели на основе микрослужб. Этот подход может помочь получить преимущества, которых трудно достичь в средах монолитных и локальных приложений.

В таблице 1-1 приводятся основные преимущества и причины для выбора каждого подхода к миграции или модернизации.

Таблица 1-1. Преимущества и проблемы вариантов модернизации существующих приложений и служб .NET

Приложения .NET Framework изначально создавались в .NET Framework версии 1.0, выпущенной в конце 2001 г. Затем компании перешли на более новые версии (например, 2.0, 3.5 и .NET Framework 4.x). Большинство этих приложений выполнялись в Windows Server и службах IIS и использовали реляционную базу данных, например SQL Server, Oracle, MySQL или другие реляционные СУБД.

Сейчас в основе большинства существующих приложений .NET может быть .NET Framework 4.x или даже .NET Framework 3.5 и они могут использовать такие веб-платформы, как MVC ASP.NET, веб-формы ASP.NET, веб-API ASP.NET, Windows Communication Foundation (WCF), ASP.NET SignalR и веб-страницы ASP.NET. Эти технологии .NET Framework зависят от Windows. Эту зависимость важно учитывать в случае, если вы просто переносите приложения прежних версий и хотите внести незначительные изменения в инфраструктуру приложений.

На рисунке 1-2 показаны основные технологии и стили архитектуры, используемые на каждом из трех уровней зрелости облака.

Рис. 1-2. Основные технологии для каждого уровня зрелости для модернизации существующих веб-приложений .NET

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

Каждый уровень зрелости в процессе модернизации связан с приведенными далее основными технологиями и подходами.

Готовность для облачной инфраструктуры (повторное размещение или простой перенос): в качестве первого шага многие организации хотят только быстро реализовать стратегию миграции в облако. В этом случае приложения размещаются повторно. Большинство операций повторного размещения можно автоматизировать с помощью миграции Azure, службы, предоставляющей рекомендации, советы и механизмы, необходимые для переноса в Azure на базе таких облачных средств, как Azure Site Recovery и Azure Database Migration Service. Повторное размещение можно также выполнить вручную, чтобы получить сведения о ресурсах при перемещении приложений прежних версий в облако. Например, можно переместить приложения на виртуальные машины в Azure с незначительными изменениями конфигурации. В этом случае сетевое окружение аналогично локальной среде, особенно если виртуальные сети создаются в Azure.

Оптимизированные для облака (управляемые службы и контейнеры Windows): чтобы получить преимущества работы в облаке, в рамках этой модели выполняется несколько важных оптимизаций развертывания без изменения базовой архитектуры приложения. Основополагающим шагом является добавление поддержки контейнеров Windows в существующие приложения .NET Framework. Для этого действия (контейнеризации) не требуется изменять код, поэтому общие трудозатраты минимальны. Можно использовать такие средства, как Image2Docker или Visual Studio, с инструментами для Docker. Visual Studio автоматически выбирает интеллектуальные значения по умолчанию для приложений ASP.NET и образов контейнеров Windows. Эти средства позволяют ускорить внутренний цикл и быстрее создать контейнеры в Azure. При развертывании в нескольких средах заметно повышается уровень гибкости. Затем, перемещаясь в рабочую среду, можно развернуть контейнеры Windows в веб-приложении для контейнеров Azure, службе Экземпляры контейнеров Azure (ACI) и на виртуальных машинах Azure с Windows Server 2016 и контейнерами, если вы предпочитаете подход IaaS. Для более сложных приложений с несколькими контейнерами рассмотрите возможность использования оркестраторов, таких как служба Azure Kubernetes (AKS/ACS).

Во время этой начальной модернизации можно также добавить ресурсы из облака, например отслеживание с помощью таких средств, как Azure Application Insights, конвейеры CI/CD для жизненного цикла приложений с Azure DevOps Services и многие другие службы для ресурсов данных, доступные в Azure. Например, можно изменить монолитное веб-приложение, изначально разработанное с использованием традиционных веб-форм ASP.NET или ASP.NET MVC, и развертываемое уже в настоящее время с помощью контейнеров Windows. Используя контейнеры Windows, необходимо перенести данные в базу данных в управляемом экземпляре базы данных SQL Azure без изменения базовой архитектуры приложения.

• Облачные: как было сказано, следует подумать о проектировании облачных приложений, если вы используете большие и сложные приложения с несколькими независимыми группами разработчиков, работающими с различными микрослужбами, которые могут разрабатываться и развертываться автономно. Еще одно важное преимущество — детализированная и независимая масштабируемость микрослужб. Эти подходы к архитектуре сталкиваются с очень важными проблемами и сложностями, но их можно значительно упростить с помощью облачных PaaS и оркестраторов, таких как Служба Azure Kubernetes (AKS/ACS) (Управляемая среда Kubernetes) и Функции Azure для бессерверного подхода. Для реализации всех этих подходов (таких как микрослужбы и бессерверная архитектура) обычно требуется проектирование приложения для облака и написание нового кода, адаптированного для определенных платформ PaaS или соответствующего конкретным архитектурам, таким как микрослужбы.

На рисунке 1-3 приводятся внутренние технологии, которые можно использовать для каждого уровня зрелости.

Рис. 1-3. Внутренние технологии для каждого уровня зрелости модернизации

Сценарии переноса

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

Рис. 1-4. Пример чистого сценария IaaS в облаке

Сценарии модернизации

Для модернизации у вас может быть чистое приложение, оптимизированное для облака, которое использует элементы только из этого уровня зрелости. Или же у вас может быть приложение промежуточного состояния с одними элементами из модели готовности для облачной инфраструктуры и другими элементами из модели оптимизации для облака (смешанная модель), как показано на рисунке 1-5.

Рис. 1-5. Пример сценария выбора с базой данных в IaaS, DevOps и активами контейнеризации

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

Рис. 1-6. Пример сценария приложения, оптимизированного для облака, с контейнерами Windows и управляемыми службами

Если идти дальше, можно расширить существующее приложение, оптимизированное для облака, добавив несколько микрослужб для конкретных сценариев. Этот подход позволит частично перейти к модели изначальной ориентации на облако, которая не рассматривается в настоящем руководстве.

Темы, которые выходят за рамки этого руководства

Это руководство охватывает определенное подмножество примеров сценариев, как показано на рисунке 1-7. Основное внимание в нем уделяется сценариям переноса и, в конечном счете, модели, оптимизированной для облака. В модели оптимизации для облака модернизация приложений .NET Framework осуществляется с помощью контейнеров Windows и дополнительных компонентов, например мониторинга и конвейеров непрерывной интеграции и непрерывного развертывания. Каждый компонент является основой для быстрого и гибкого развертывания приложений в облаке.

Рис. 1-7. Собственно облачные приложения не рассматриваются в данном руководстве

Это руководство преследует конкретную цель. Оно показывает вариант переноса существующих приложений .NET без изменения архитектуры и кода. А также описывает, как оптимизировать приложение для облака.

В этом руководстве нет инструкций по созданию собственно облачных приложений, например, нет сведений о развитии до архитектур микрослужб. Информация о перепроектировании приложений или создании совершенно новых приложений на основе микрослужб доступна в электронной книге Микрослужбы .NET: архитектура контейнерных приложений .NET.

Жизненный цикл контейнерного приложения Docker на основе платформы и средств Майкрософт (электронная книга, доступная для скачивания) https://aka.ms/dockerlifecycleebook

Микрослужбы .NET. Архитектура контейнерных приложений .NET (электронная книга, доступная для скачивания) https://aka.ms/microservicesebook

Проектирование современных веб-приложений с помощью ASP.NET Core и Azure (электронная книга, доступная для скачивания) https://aka.ms/webappebook

Кому необходимо это руководство

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

Кроме того, сведения в этом руководстве могут быть полезны лицам, принимающим технические решения, таким как архитектор предприятия или руководитель отдела разработки, и тем, кто хочет узнать о преимуществах использования контейнеров Windows и развертывания в облаке при работе в Microsoft Azure.

Как пользоваться руководством

Это руководство отвечает на вопрос о необходимости модернизации существующих приложений и о том, какие преимущества будут вам доступны при перемещении приложений в облако с помощью контейнеров Windows. Содержимое нескольких первых глав руководства предназначено для архитекторов и лиц, принимающих технические решения, которые хотят получить общие сведения, но не ставят перед собой задачу детального изучения вопросов реализации и технических особенностей.

В последней главе руководства представлены несколько пошаговых руководств, нацеленных на конкретные сценарии развертывания. В этом руководстве предлагаются сокращенные версии пошаговых руководств. Это сделано для обобщения сценариев и выделения их преимуществ. Полные руководства содержат подробные сведения о настройке и реализации и опубликованы в виде серии статей на вики-сайтах в одном открытом репозитории GitHub. Там же размещены связанные примеры приложений (описаны в следующем разделе). Наибольший интерес у разработчиков и архитекторов, занимающихся вопросами реализации, вызовет последняя глава и пошаговые руководства на сайте GitHub.

Примеры приложений для модернизация приложений прежних версий: eShopModernizing

В репозитории eShopModernizing на сайте GitHub представлены два примера приложений, которые имитируют устаревшие монолитные веб-приложения. Одно веб-приложение разрабатывается с помощью ASP.NET MVC, второе веб-приложение разрабатывается с помощью веб-форм ASP.NET, а третье приложение — N-уровневое приложение с клиентским классом WinForms, использующим серверную часть службы WCF. Все эти веб-приложения основаны на традиционной платформе .NET Framework. Эти примеры приложений не используют .NET Core/.NET 6 и ASP.NET Core, так как предполагается, что это уже существующие или устаревшие приложения .NET Framework, которые подлежат модернизации.

Примеры приложений имеют вторые версии с измененным кодом и достаточно просты для понимания. Самое важное отличие между версиями приложений заключается в том, что во вторых версиях в качества варианта развертывания используются контейнеры Windows. Кроме того, вторые версии поддерживают ряд дополнений, таких как хранилище больших двоичных объектов Azure для управления образами, Azure Active Directory для управления безопасностью и Azure Application Insights для мониторинга и аудита приложений.