Что такое n-уровневая архитектура?
В n-уровневой архитектуре приложение разделяется на логические слои и физические уровни. N представляет число физических уровней, на которые разделено приложение. Обычно это число соотносится с количеством слоев. У нас может быть двухуровневая архитектура (клиент-сервер) или даже пятиуровневая, но обычно уровней бывает четыре или меньше.
Давайте поговорим о том, из чего состоят слои и уровни.
Что собой представляют слои?
Слои логически разделяют код приложения, из которого состоит приложение. Каждый слой имеет свои обязанности, например обработка запросов от пользователей, выполнение бизнес-логики или обработка хранения данных.
Разделяя приложение на эти логически слои, мы работаем с каждым слоем по отдельности. Это разделение делает компоненты модульного приложения и позволяет нам более легко поддерживать приложение. Также мы можем оптимизировать приложение для каждой задачи. Слой, обрабатывающий веб-запросы, выполняет свою основную задачу: обработка веб-запросов. Он не связан с хранением данных или выполнением бизнес-логики. И наоборот, уровень доступа к данным фокусируется на оптимизации связи с хранилищем данных и игнорирует сведения о том, как он представляет данные пользователю. Этот принцип ограниченного фокуса называется разделением зон ответственности.
Ниже приведена схема, показывающая слои в обычной n-уровневой архитектуре. Каждый слой обрабатывает один аспект приложения. Бизнес-слой управляет взаимодействием между слоем пользовательского интерфейса и слоем доступа к данным.
Что такое уровни?
Уровни представляют собой физическое разделение частей приложения на отдельных вычислительных ресурсах. Как правило, каждый физический уровень выполняет один логический слой приложения.
Разделение архитектуры на физические уровни имеет несколько преимуществ:
- Компоненты приложения можно масштабировать отдельно, добавляя ресурсы на каждый уровень.
- Приложение может быть более устойчивым, если вы будете добавлять балансировку нагрузки для обнаружения ресурсов с ошибками и перенаправлять запросы работоспособным системам.
- Приложение может быть более безопасным, ограничив сетевое взаимодействие между уровнями и разрешая только необходимый доступ.
Архитектура определяет, что обмен данными между уровнями должен находиться в верхней части. Каждый уровень может взаимодействовать со следующим уровнем ниже, но обычно не допускается пропускать уровни. Эта конструкция повышает безопасность, ограничивая доступную область поверхности уровня.
Трехуровневая архитектура
Обычно n-уровневая архитектура имеет три уровня. Задачи и названия каждого слоя и уровня зависят от приложения и бизнеса, но обычно у трехуровневого приложения есть уровень представления, уровень приложения, или средний уровень, и уровень данных. Эта архитектура является наиболее распространенным стилем N-уровня. Для остальной части этого модуля мы будем ссылаться на трехуровневую модель с каждым уровнем, на котором выполняется один слой приложения, и ссылаться на них синонимами как уровни.
Уровень представления
Уровень представления обычно отвечает за запросы пользователей. Эти запросы могут быть пользователями, обращаюющимися к веб-странице, или общедоступным доступом к приложению через предоставляемый API. Фокус на этом уровне находится на пользовательском интерфейсе. Предоставление таких вещей, как интуитивно понятный интерфейс и обеспечение безопасного взаимодействия между конечным пользователем и приложением.
Здесь вас интересуют не сами данные, а их представление пользователю. Как правило, на этом уровне нет доступа к данным или обработке данных. Этим занимаются нижние уровни.
Уровень приложения
Уровень приложений (также называемый средним уровнем) обычно обрабатывает бизнес-логику приложения. Например, обрабатывает заказ клиента, отслеживает посылку или обновляет запасы на основе полученных материалов. Этот уровень также отвечает за создание, чтение, обновление и удаление (CRUD) на уровне данных. На нем также можно выполнять вызовы к зависимым службам, таким как внешние API.
Этот уровень не отвечает за то, как информация предоставляется пользователю или как хранятся и извлекаются данные. Основное внимание уделяется бизнес-логике, необходимой для выполнения запроса, полученного приложением.
Уровень данных
Этот уровень предусматривает хранение данных. Его задача — хранение данных в таблицах, файлах или других носителях. Этот уровень предоставляет интерфейс (например, T-SQL) для доступа к данным. В трехуровневой архитектуре уровень данных предоставляет доступ к данным уровню приложения.
Этот уровень не ориентирован на то, как данные представлены пользователю, и не ориентированы на логику вокруг данных. Использование хранимых процедур может находиться на этом уровне, но большая часть логики вокруг данных должна обрабатываться на более высоком уровне.
Когда использовать n-уровневые архитектуры
Теперь, когда мы говорили о том, что такое архитектура N-уровней, давайте рассмотрим, когда вы будете использовать архитектуру этого стиля. Используйте n-уровневую архитектуру для следующих сценариев:
- Небольшие и средние веб-приложения.
- перенос локального приложения в Azure с минимальным рефакторингом;
- Использование навыков, возможностей и опыта локальных разработчиков.
Веб-приложения являются хорошим вариантом использования для архитектур данного стиля. Поскольку такая архитектура является упрощенной и задачи в веб-приложениях естественным образом разделяются, n-уровневые архитектуры хорошо подойдут для таких сценариев. Эти приложения могут быть общедоступными или бизнес-приложениями, которые используются внутри организации. Для небольших или менее сложных приложений достаточно будет двухуровневой архитектуры (клиент-сервер), где уровни представления и приложения можно объединить.
N-уровневые архитектуры распространены в традиционных локальных приложениях, поэтому они естественным образом подходят для переноса существующих рабочих нагрузок в Azure. Приложения в этом стиле часто переносятся в Azure с минимальным рефакторингом или изменениями, что упрощает первоначальную миграцию. После переноса в Azure вы можете пользоваться преимуществами платформы как услуги (PaaS) для дальнейшей оптимизации приложения.
Так как это распространенный стиль архитектуры, инженеры хорошо знакомы с ним и имеют большой опыт. Выбрав эту архитектуру, вы можете использовать имеющиеся навыки для развертывания приложений без необходимости в изучении новых архитектурных шаблонов.