Стиль архитектуры N-уровней

Архитектура N-уровня делит приложение на логические слои и физические уровни.

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

Уровни физически разделены и выполняются на отдельных компьютерах. В соответствии с договором уровень взаимодействия может иметь строгие или разрешенные модели коммуникации. В строгой модели запрос должен проходить по смежным уровням, по одному и не может пропускать какой-либо уровень между ними. Например, запрос перемещается из брандмауэра веб-приложения (WAF) на веб-уровень, а затем на средний уровень 1 и продолжается. В отличие от этого, расслабленный подход позволяет запросам пропускать некоторые уровни при необходимости. Строгий подход имеет большую задержку и издержки. Расслабленный подход имеет больше связей, что делает изменения более сложными. Вы также можете объединить оба подхода в одной системе.

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

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

Приложение уровня N может иметь архитектуру закрытого слоя или архитектуру открытого слоя:

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

Архитектура закрытого слоя ограничивает зависимости между слоями. Но эта архитектура может создать ненужный сетевой трафик, если один слой передает запросы только на следующий уровень.

Когда следует использовать эту архитектуру

Рассмотрим архитектуру уровня N для следующих сценариев:

• Поддержка требований архитектуры, которые по-прежнему развиваются.
• Перенос локального приложения в Azure с минимальными изменениями.
• Разработка приложений, охватывающих как локальные, так и облачные среды.

Архитектуры N-уровня распространены в традиционных локальных системах, что делает их естественным подходом для перехода существующих рабочих нагрузок в Azure.

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

Преимущества

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

Сложности

• Средний уровень может выполнять только основные операции создания, чтения, обновления, удаления (CRUD), которые добавляют задержку и сложность, не предоставляя понятное значение.
• Монолитная конструкция предотвращает независимое развертывание функций.
• Крупные системы могут затруднить управление безопасностью сети.
• Запросы пользователей и данные, которые перемещаются по нескольким уровням, усложняют тестирование и мониторинг.

Лучшие практики

• Используйте автомасштабирование для обработки изменений в нагрузке. Дополнительные сведения см. в рекомендациях по автомасштабированию.
• Используйте асинхронное обмен сообщениями , чтобы разделить уровни.
• Кэшируйте данные, которые часто не изменяются. Дополнительные сведения см. в рекомендациях по кэшированию.
• Настройте уровень базы данных для обеспечения высокой доступности с помощью такого решения, как группы доступности SQL Server AlwaysOn.
• Поместите WAF между интерфейсом и Интернетом.
• Поместите каждый уровень в собственную подсеть и используйте подсети в качестве границы безопасности.
• Ограничить доступ к уровню данных, разрешая только запросы со среднего уровня.

Архитектура уровня N на виртуальных машинах

В этом разделе описывается архитектура уровня N, которая выполняется на виртуальных машинах.

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

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

Веб-уровни и бизнес-уровни являются без отслеживания состояния. Любая виртуальная машина может обрабатывать любой запрос для этого уровня. Уровень данных должен состоять из реплицированной базы данных. По возможности используйте управляемую базу данных, но также можно размещать базы данных на виртуальных машинах. Для Windows рекомендуется использовать SQL Server с группами доступности AlwaysOn для обеспечения высокой доступности. Для Linux выберите базу данных, которая поддерживает репликацию, например Apache Cassandra.

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

Другие вопросы

• Архитектуры N-уровней не ограничиваются тремя уровнями. Более сложные приложения часто имеют больше уровней. В этом случае рекомендуется использовать маршрутизацию уровня 7 для маршрутизации запросов к конкретному уровню.

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

• Используйте масштабируемые наборы виртуальных машин для автомасштабирования.

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

• Поместите сеть периметра (также называемую DMZ, демилитаризованной зоной и экранной подсетью) перед приложением для повышения безопасности. Сеть периметра включает сетевые виртуальные устройства (NVA), которые реализуют функции безопасности, такие как брандмауэры и проверка пакетов. Дополнительные сведения см. в разделе "Реализация безопасной гибридной сети".

• Используйте два или более NVA в масштабируемом наборе виртуальных машин с внешней подсистемой балансировки нагрузки для распространения интернет-запросов между экземплярами для обеспечения высокой доступности. Дополнительные сведения см. в разделе "Развертывание высокодоступных NVAs".

• Блокировать прямой доступ к протоколу удаленного рабочего стола (RDP) или Secure Shell (SSH) к виртуальным машинам, выполняющим код приложения. Вместо этого используйте Бастион Azure для безопасного подключения к виртуальным машинам через частные IP-адреса, обеспечивающие подключение RDP и SSH. Дополнительные сведения см. в обзоре Бастиона Azure.

• Расширьте виртуальную сеть Azure до вашей локальной сети с помощью виртуальной частной сети типа "межсайтовая VPN" или Azure ExpressRoute. Дополнительные сведения см. в статье о эталонной архитектуре гибридной сети.

Следующий шаг

• Создание безопасного многоуровневого приложения в Службе Приложений

Связанный ресурс

• Обмен сообщениями в стиле архитектуры N уровня в Azure