ГОСТ Р 70860-2023. Национальный стандарт Российской Федерации. Информационные технологии. Облачные вычисления. Общие технологии и методы

9.4 Многоуровневая архитектура

 

В программировании часто используются предметно-ориентированное проектирование и соответствующая многоуровневая архитектура (см. https://www.nareshbhatia.dev/articles/domain-driven-design-6-layered-architecture).

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

- эффективную совместную работу: каждый уровень разрабатывается специалистом, специализирующимся именно на данном уровне, например: графический интерфейс пользователя на основе веб-браузера разрабатывается веб-дизайнерами, а логика предметной области - программистами Java^TM. Специалисты могут сосредоточиться на своих собственных разработках при минимуме посторонних проблем;

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

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

Использование многоуровневой архитектуры оказывается эффективным в приложениях на базе микросервисов. Многоуровневая архитектура используется в приложениях, разработанных с использованием микросервисов, и отдельные методы, связанные с использованием многоуровневой архитектуры, достаточно подробно описываются в литературе. Хотя для микросервисов не существует стандартизированной многоуровневой архитектуры, может быть использована многоуровневая архитектура, предложенная в предметно-ориентированном проектировании, суть которой можно выразить с помощью четырех уровней компонентов (см. рисунок 5):

- пользовательский интерфейс. Программный компонент принимает запросы от пользователей и предоставляет ответы;

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

- предметная область. Программный компонент реализует бизнес-логику;

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

 

 

Рисунок 5 - Многоуровневая архитектура, используемая

с микросервисами

 

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

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

 

 

Рисунок 6 - Модель монолитного веб-приложения

 

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

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