4 типа архитектуры программного обеспечения

Детальный обзор существующих подходов

Зачем нужна архитектура ПО

Первые разработчики создавали программное обеспечение без архитектуры. Сначала это казалось удобным: никаких издержек, связанных с планированием, и ускоренное прототипирование. Но мере усложнения ПО теряло гибкость и управляемость, а каждое новое изменение обходилось все дороже. Это мешало развивать проект за границы, определенные изначально. Такая система получила название Большой комок грязи (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-уровневая системы

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

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

Сервис-ориентированная архитектура (SOA)

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

Она состоит из 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).

Mикросервисная архитектура

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

Читайте также:

• Мы снова написали самый быстрый JS-фреймворк UI
• 3 совета, как стать мастером Йода по JavaScript
• 10 полезных инструментов для фронтенд-разработчика

Читайте нас в Telegram, VK и Яндекс.Дзен

---

Перевод статьи Mohit Malhotra: Everything About Software Architecture