Первые разработчики создавали программное обеспечение без архитектуры. Сначала это казалось удобным: никаких издержек, связанных с планированием, и ускоренное прототипирование. Но мере усложнения ПО теряло гибкость и управляемость, а каждое новое изменение обходилось все дороже. Это мешало развивать проект за границы, определенные изначально. Такая система получила название Большой комок грязи (Big Ball of Mud).

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

• Многослойная архитектура (Layered Architecture).
• Многоуровневая архитектура (Tiered Architecture).
• Сервис-ориентированная архитектура (Service Oriented Architecture — SOA).
• Микросервисная архитектура (Microservice Architecture).

Подробно рассмотрим каждую из них.

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

Архитектура делит ПО на следующие слои.

• Слой представления (Presentation Layer) содержит пользовательский интерфейс и отвечает за обеспечение хорошего пользовательского опыта.
• Слой бизнес-логики (Business Logic Layer) , как следует из названия, содержит бизнес-логику приложения. Он отделяет UI/UX от вычислений, связанных с бизнесом. Это позволяет с легкостью изменять логику в зависимости от постоянно меняющихся бизнес-требований, никак не влияя на другие слои.
• Слой передачи данных (Data Link Layer) отвечает за взаимодействие с постоянными хранилищами, такими как базы данных, и прочую обработку информации, которая не связана с бизнесом.

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

Так выглядит многослойная архитектура

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

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

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

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

В данном подходе единая система работает как на стороне сервера, так и клиента. Это обеспечивает простоту развертывания и отличную скорость связи, а также устраняет необходимость межсистемного взаимодействия (Inter-system communication  —  ISC).

Такая система подходит только для небольших однопользовательских приложений.

Так выглядит двухуровневая архитектура

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

• Клиент содержит слои презентации, бизнес-логики и передачи данных.
• Сервер включает хранилища и базы данных.

Так выглядит трехуровневая архитектура

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

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

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

Она состоит из 5 элементов:

• сервисы (Services);
• сервисная шина (Service Bus);
• сервисный репозиторий (Service Repository catalogue of services );
• безопасность SOA (SOA Security);
• управление SOA (SOA Governance).

Клиент отправляет запрос с использованием стандартного протокола и формата данных по сети. Этот запрос обрабатывается ESB (enterprise service bus  —  сервисная шина предприятия), которая считается сердцем сервис-ориентированной архитектуры и отвечает за оркестровку и маршрутизацию. С помощью сервисного репозитория ESB направляет запрос в специальный сервис, который может взаимодействовать с другими сервисами и базами данных, чтобы составить полезную нагрузку (данные) ответа.

Полный вызов ответа на запрос согласуется с правилами управления и безопасности SOA для выполнения безопасной и корректной транзакции.

Как правило, сервисы делятся на два вида.

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

• Организационные сервисы (Entity service).
• Доменные сервисы (Domain Service).
• Вспомогательные сервисы (Utility Service).
• Интегрированный сервис (Integrated Service).
• Сервис приложений (Application Service).
• Сервис безопасности (Security Service).

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

• Эти сервисы основываются на бизнес-возможностях и могут развертываться независимо друг от друга с помощью полностью автоматизированного механизма.
• Централизованное управление между сервисами минимально. Они могут быть написаны на разных языках, использовать разные технологии хранения данных.

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

Монолитная и микросервисная архитектуры

Архитектура состоит из изолированных компактных микросервисов, способных расширяться независимо друг от друга. Она включает 5 следующих компонентов:

• сервисы (Services);
• сервисная шина (Service Bus);
• внешняя конфигурация (External configuration);
• шлюз API (API Gateway);
• контейнеры (Containers).

Микросервисная архитектура должна включать следующие характеристики.

• Компонентизация через сервисы.
• Организация вокруг бизнес-возможностей.
• Ориентирована на продукты, а не проекты.
• Умные конечные точки и глупые каналы (Smart endpoints and dumb pipes).
• Децентрализованное управление.
• Децентрализованное управление данными.
• Автоматизация инфраструктуры.
• Защита от сбоев.
• Эволюционное проектирование.

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

Монолитная, сервис-ориентированная и микросервисная архитектуры

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

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