Упражнение. Развертывание n-уровневой архитектуры

Завершено

Вспомните наш сценарий миграции приложения из локальной системы в Azure. Как может выглядеть такая архитектура? У вашей организации есть некритическое приложение, которое отлично подходит для примера. Это приложение предназначено устранить распространенную проблему выбора блюда на обед.

Вспомните, когда вы в последний раз ходили обедать с друзьями или коллегами. Было ли вам легко принять решение или вы потратили много времени, пытаясь понять, что на самом деле означало выражение, когда они говорили: "Меня нравится все?" Давайте развернем приложение на основе трехуровневой архитектуры, которая может помочь решить эту проблему. Это приложение, в котором можно создавать предложения вариантов обеда и голосовать за лучший.

Мы создали шаблон для этого приложения, который развертывает каждый уровень как ресурсы Azure, а затем развертывает фактический код. Это приложение является приложением ASP.NET Core MVC, развернутым на серверах Linux, но вы можете использовать этот стиль архитектуры независимо от базовых платформ ОС или пакета SDK.

Ниже приведена высокоуровневая визуализация развертывания этого шаблона.

Visualization of the N-tier architecture to be deployed in this unit.

Развертывание n-уровневой архитектуры

  1. Выполните следующую команду, чтобы запустить развертывание. Команда az deployment group create запускает развертывание в группе ресурсов песочницы, используя файл шаблона и указанные параметры. Мы также укажем случайную строку из 32 символов, созданную командой head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32 в качестве пароля.

    Развертывание занимает около 5 минут.

    az deployment group create \
      --resource-group <rgn>[sandbox resource group name]</rgn> \
      --template-uri  https://raw.githubusercontent.com/MicrosoftDocs/mslearn-n-tier-architecture/master/Deployment/azuredeploy.json \
      --parameters password="$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)"
    

Просмотр развернутых ресурсов и тестирование приложения

По завершении развертывания проверьте приложение. Выполните следующую команду, которая возвращает URL-адрес приложения.

az deployment group show \
  --output table \
  --resource-group <rgn>[sandbox resource group name]</rgn> \
  --name azuredeploy \
  --query properties.outputs.webSiteUrl

Откройте браузер и перейдите на сайт. Появится окно, где можно добавить варианты блюд. После добавления параметра выберите его, добавив голосование.

Screenshot of the sample voting application.

Три уровня приложения "Что на обед?"

Это приложение намеренно упрощено. Это забавное приложение, демонстрирующее трехуровневую архитектуру. Этот шаблон создает две виртуальные машины, базу данных SQL Azure и ресурсы, необходимые для их поддержки, такие как диски, сетевые адаптеры и виртуальные сети. Он также развертывает код для запуска приложения на каждом уровне. Развернутая виртуальная сеть имеет две подсети — одна для уровня представления и одна для уровня приложения, предоставляя границу безопасности для каждого уровня.

Мы также применили теги к ресурсам в рамках развертывания, чтобы указать, какой уровень поддерживает ресурс (tier:presentation, tier:application, tier:data). Теги позволяют применять метаданные к ресурсам Azure, а в этом случае — легко фильтровать ресурсы для каждого уровня.

Давайте рассмотрим каждый уровень. Ниже приведена подробная визуализация развернутых ресурсов.

Visualization of the N-tier architecture to be deployed in this unit again.

Уровень представления

Выполните следующую команду, чтобы вывести список ресурсов уровня представления:

az resource list --tag tier=presentation --output table

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

Мы развернули веб-сервер с именем demo-web-vm, на котором выполняется веб-сайт. Сервер имеет сетевой интерфейс demo-web-vm-nic , имеющий общедоступный IP-адрес demo-web-vm-nic-pip , связанный с ним. Этот общедоступный IP-адрес — это URL-адрес, полученный ранее. Он также имеет группу безопасности сети demo-web-nsg , которая разрешает входящий трафик только через порт 80 (HTTP). Эта группа безопасности сети ограничивает доступ только к веб-сайту и предотвращает доступ через ненужные порты, которые могут использоваться злонамеренно. Этот уровень взаимодействует с уровнем представления по протоколу HTTP для выполнения запросов от пользователей.

Уровень приложения

Выполните следующую команду, чтобы вывести список ресурсов уровня приложения.

az resource list --tag tier=application --output table

Мы развернули уровень приложений на виртуальной машине с именем demo-biz-vm , выполняющей бизнес-логику. Он также имеет сетевой интерфейс demo-biz-vm-nic, но у этого сетевого интерфейса есть только частный IP-адрес и отсутствует механизм для прямого входящего подключения к серверу. У него также есть группа безопасности сети, demo-biz-nsg, которая разрешает доступ только из подсети уровня представления.

Этот уровень является каналом для доступа приложения к данным. Код, предоставляющий доступ к API, который вызывает уровень представления, развертывается на этом сервере. Данные здесь не хранятся, и пользователи не могут напрямую получить доступ к этому серверу. Чтобы получить доступ к данным и выполнять запросы пользователей, этот уровень взаимодействует с уровнем данных через команды T-SQL.

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

Уровень данных

Выполните следующую команду, чтобы вывести список ресурсов уровня данных.

az resource list --tag tier=data --output table

Уровень данных находится на сервере базы данных SQL Azure, demo-dbserver-abc123 (добавим случайную строку к имени сервера для глобальной уникальности). Этот сервер хранит данные приложения в базе данных с именем demo-sqldb. Этот уровень приложения предназначен исключительно для хранения данных и предоставления метода доступа к нему. В этом случае доступ осуществляется через T-SQL, который приложение выполняет в базе данных. Мы не обрабатываем бизнес-логику на этом уровне и не представляем данные пользователю.

Этот уровень предоставляет подключения через порт 1433 через конечную точку службы виртуальной сети. Конечные точки служб виртуальной сети создают механизм подключения служб PaaS (таких как База данных SQL Azure) к подсети. Он ограничивает возможности подключения только ресурсами в этой подсети.

Этот пример также демонстрирует использование PaaS вместо инфраструктуры как услуги (IaaS) на виртуальных машинах для работы уровня приложения. Мы часто думаем о N-уровнях приложений в качестве приложений на основе виртуальных машин, но это не является обязательным требованием. Используя службы PaaS вместо виртуальных машин, вы можете снизить затраты, повысить безопасность и сократить требования к администрированию.