Все архитектурные стили в одном месте

Доброго дня, небольшой перерыв в статьях про event storming, скоро допишу этот роман )).

Все же в курсе, что есть не только микросервисная архитектура и монолит, есть еще куча стилей построения систем и решений?

Зачем их нужно знать? Необходимо уметь использовать лучшие решения из популярных стилей для большей гибкости и эффективности информационной системы или решения. При этом на 100% следовать паттернам не обязательно и даже желательно.

В рамках подготовки курса для одного корп. университета свел все в одну статью. Оставлю тут как справочник.

Fundamentals of Software Architecture

Layered Architecture

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

Основные характеристики:

1. Разделение на слои

Каждый слой выполняет строго определённые задачи.

Слои взаимодействуют последовательно: верхние используют функционал нижних.

2. Чёткая модульность

Код упорядочен по уровням ответственности (UI, бизнес-логика, доступ к данным).

Облегчает поддержку и тестирование.

3. Слабая связанность (Low Coupling)

Каждый слой скрывает детали реализации нижележащего слоя.

Можно изменять один слой, не затрагивая остальные.

Типичная структура Layered Architecture:

1. Presentation Layer (Уровень представления)

Отвечает за пользовательский интерфейс (UI).

Примеры: веб-приложения, мобильные интерфейсы.

2. Application Layer (Уровень приложения, сервисный уровень)

Управляет бизнес-логикой и обработкой данных.

Оркестрирует вызовы между слоями.

3. Domain/Business Logic Layer (Слой бизнес-логики)

Реализует основную логику работы системы.

Определяет правила, процессы и вычисления.

4. Data Access Layer (Слой доступа к данным)

Обеспечивает связь с базами данных, API, файловыми системами.

Инкапсулирует SQL-запросы или ORM (например, Hibernate, Entity Framework).

5. Infrastructure Layer (Инфраструктурный слой, опционально)

Содержит вспомогательные сервисы (аутентификация, логирование, кэширование).

Преимущества Layered Architecture:

Простота разработки и поддержки.
Чёткое разделение ответственности.
Повышенная переиспользуемость кода.
Лёгкость тестирования (можно тестировать каждый слой отдельно).

Недостатки:

Возможны потери производительности из-за большого количества слоёв.
Жёсткое следование иерархии может усложнять изменения.
Сложность в масштабировании при больших нагрузках.

Применение:

Веб-приложения (MVC, MVVM).

Корпоративные системы (ERP, CRM).

Классические клиент-серверные приложения.

Layered Architecture — это один из самых популярных архитектурных стилей, который обеспечивает структурированность, удобство поддержки и тестируемость, но требует грамотного проектирования, чтобы избежать излишней сложности и падения производительности. Паттерн MVC является частной реализацией Layered architecture.

Modular Monolith Architecture

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

Основные характеристики Modular Monolith Architecture

1. Разделение системы на независимые модули
   Система остается единым приложением, но логически разделяется на модули, каждый из которых отвечает за свою бизнес-функцию, например, модуль заказов, модуль пользователей, модуль платежей.
2. Внутренние границы модулей
   Каждый модуль имеет четкие границы и может содержать свои модели данных, бизнес-логику и сервисы. Взаимодействие между модулями происходит через четко определенные интерфейсы, а не через прямой доступ к данным.
3. Единая кодовая база и база данных
   В отличие от микросервисной архитектуры, вся система разрабатывается и развертывается как единое приложение. Однако модули могут использовать отдельные схемы в базе данных или ограничивать доступ к данным других модулей.
4. Четкое управление зависимостями
   Модули взаимодействуют друг с другом через интерфейсы, фасады или события, что минимизирует тесные зависимости и делает систему более гибкой.
5. Возможность постепенного перехода к микросервисам
   Благодаря четкому разделению модулей, в будущем их можно вынести в отдельные сервисы, что упрощает миграцию к микросервисной архитектуре при необходимости.

Преимущества Modular Monolith Architecture

· Проще разрабатывать и поддерживать по сравнению с микросервисами

· Лучше структурирован, чем классический монолит, благодаря изоляции модулей

· Легче тестировать и отлаживать, так как вся система развертывается как единое приложение

· Обновления проще, так как не требуется сложная инфраструктура для развертывания множества сервисов

Недостатки

· Ограниченная масштабируемость – вся система работает в одном процессе
Единое развертывание – обновление одного модуля требует развертывания всей системы

· Необходим строгий контроль зависимостей, иначе может превратиться в «спагетти-монолит»

Применение Modular Monolith Architecture

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

· Проекты, которые могут в будущем перейти на микросервисы, но пока не требуют сложной распределенной архитектуры

· Стартапы и бизнес-приложения, которым нужна гибкость, но без дополнительных затрат на сложную инфраструктуру

Modular Monolith Architecture – это удобный компромисс между традиционным монолитом и микросервисами. Он обеспечивает структурированность и гибкость кода, сохраняя простоту развертывания и управления системой. Это хороший выбор для большинства проектов, особенно на ранних этапах развития.

Micro-Kernel Architecture

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

6. Минимальное ядро (Micro-Kernel)

Содержит базовый функционал системы.

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

7. Расширяемые плагины (Extensions, Plugins)

Независимые модули, добавляющие новый функционал.

Могут быть подключены или отключены без изменения ядра.

Взаимодействуют с ядром через стандартизированные API.

8. Гибкость и адаптивность

Новые функции могут быть добавлены без изменения основной архитектуры.

Легко адаптируется под разные сценарии использования.

9. Модульность и лёгкость обновления

Разработчики могут обновлять или заменять плагины без остановки системы.

Примеры применения Micro-Kernel Architecture

Операционные системы:

· Windows (системные службы как модули)

· macOS (XNU Kernel)

· Minix, QNX (чистый микроядровый подход)

Различные платформы и инструменты:

· Eclipse (IDE с поддержкой плагинов)

· Web-серверы (например, Apache, Nginx с модулями)

· JIRA (основное ядро + плагины для расширения функционала)

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

· Гибкость — можно легко добавлять и удалять модули.

· Упрощённое тестирование — модули можно разрабатывать и тестировать независимо.

· Меньшая вероятность критических ошибок — сбой в одном модуле не приводит к падению всей системы.

· Обновляемость — можно обновлять модули без изменения ядра.

Недостатки:

· Сложность взаимодействия между модулями — требует хорошо продуманных API.

· Накладные расходы на межпроцессное взаимодействие — при использовании микроядра в ОС обмен сообщениями может замедлять работу.

· Потенциальные проблемы совместимости — разные версии модулей могут конфликтовать.

Micro-Kernel Architecture хорошо подходит для систем, которые должны быть гибкими и расширяемыми. Она широко используется в операционных системах, плагинных платформах, серверах и других системах, где важно динамически добавлять или изменять функциональность без значительных изменений в коде.

Microservices Architecture

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

Основные характеристики Microservices:

1. Разделение системы на независимые сервисы

Каждый микросервис выполняет отдельную бизнес-функцию (например, сервис заказов, сервис платежей).

Можно разрабатывать, развёртывать и масштабировать сервисы независимо друг от друга.

2. Изоляция и автономность сервисов

Каждый сервис имеет собственную базу данных (или управляет своей областью данных).

Нет прямого доступа к данным других сервисов — только через API или события.

3. Разные технологии и языки программирования

Микросервисы могут быть написаны на разных языках и использовать разные технологии.

Например, один сервис на Java, другой на Node.js, третий на Python.

4. Коммуникация через API или сообщения

Сервисы взаимодействуют через HTTP (REST, GraphQL, gRPC) или асинхронные очереди (Kafka, RabbitMQ).

Асинхронное взаимодействие помогает снизить нагрузку и повысить отказоустойчивость.

5. Независимое развертывание и масштабирование

Можно обновлять и развертывать сервисы независимо, без влияния на другие части системы.

Можно масштабировать только нужные сервисы (например, при росте заказов увеличивать только сервис заказов).

Структура Microservices Architecture:

1. API Gateway (Шлюз API)

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

Выполняет маршрутизацию, аутентификацию, кэширование и балансировку нагрузки.

2. Отдельные микросервисы

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

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

3. Messaging System (Очереди сообщений)

Используется для асинхронного обмена данными между сервисами (например, Kafka, RabbitMQ, SQS).

4. Отдельные базы данных

Каждый сервис работает со своей базой (например, PostgreSQL для одного сервиса, MongoDB для другого).

Преимущества Microservices Architecture:

· Гибкость разработки — команды могут разрабатывать сервисы независимо.

· Лучшее масштабирование — можно увеличивать только те части системы, которые перегружены.

· Отказоустойчивость — сбой в одном сервисе не приводит к падению всей системы.

· Технологическая свобода — можно использовать разные языки программирования и базы данных.

· Легкость обновлений — можно обновлять или заменять сервисы без остановки всей системы.

Недостатки:

· Сложность разработки — управление несколькими сервисами требует продуманной архитектуры.

· Коммуникационные задержки — взаимодействие сервисов по сети медленнее, чем в монолите.

· DevOps сложность — нужна автоматизация развертывания, мониторинга, логирования (CI/CD, Kubernetes, Docker).

· Репликация данных — одни и те же данные могут храниться в нескольких сервисах, что усложняет консистентность.

Применение Microservices Architecture:

· Высоконагруженные системы (Netflix, Amazon, Uber).

· Платформы с частыми изменениями и разными командами разработки.

· Проекты, где критична масштабируемость и отказоустойчивость.

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

Service-Based Architecture

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

Основные характеристики Service-Based Architecture

1. Разделение системы на сервисы
   Система разделена на несколько сервисов, каждый из которых отвечает за определенную область бизнеса, например, сервис заказов, сервис пользователей, сервис платежей. В отличие от микросервисной архитектуры, здесь сервисы могут разделять общую базу данных.
2. Взаимодействие через API
   Сервисы взаимодействуют через REST, gRPC или SOAP API. Однако в отличие от микросервисного подхода, в service-based архитектуре чаще используется централизованный API Gateway для маршрутизации запросов.
3. Общая база данных
   Несколько сервисов могут использовать одну и ту же базу данных, что упрощает управление данными, но создает зависимость между сервисами и снижает степень их изоляции.
4. Централизованный API Gateway
   Часто используется единый API Gateway, который управляет запросами от клиентов и направляет их к соответствующим сервисам. Он может выполнять аутентификацию, кэширование, балансировку нагрузки.
5. Простота управления
   По сравнению с микросервисной архитектурой, здесь меньшее количество сервисов, их легче разрабатывать, тестировать и развертывать.

Преимущества Service-Based Architecture

· Проще в разработке и управлении по сравнению с микросервисами

· Гибкость – можно изменять или заменять отдельные сервисы без значительных изменений в системе

· Более эффективное использование ресурсов – меньше накладных расходов, чем у микросервисов

· Можно постепенно разделять систему на более мелкие сервисы, переходя к микросервисной архитектуре

Недостатки

· Слабее изолированы сервисы – возможны тесные зависимости между ними

· Совместное использование базы данных может привести к проблемам с масштабируемостью

· Централизованный API Gateway может стать узким местом системы

Применение Service-Based Architecture

· Подходит для средних по размеру систем, которым важна модульность, но где микросервисы слишком сложны

· Для корпоративных приложений, где требуется определенная степень разделения, но нет необходимости в полной независимости сервисов

· Для систем, которые в будущем могут быть разбиты на микросервисы, но пока не требуют высокой сложности управления

Service-Based Architecture – это компромисс между монолитной и микросервисной архитектурой. Она позволяет разбить систему на части, сохраняя простоту управления, но при этом не требует сложной инфраструктуры, как микросервисы. Этот подход особенно полезен для организаций, которые хотят повысить модульность своих систем, но не готовы к полной децентрализации.

Service-Oriented Architecture (SOA)

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

Основные характеристики Service-Oriented Architecture

1. Разделение системы на сервисы
   Каждый сервис выполняет определенную бизнес-функцию и взаимодействует с другими сервисами через стандартизированные интерфейсы. Сервисы могут быть крупными и охватывать целые бизнес-процессы.
2. Использование стандартизованных протоколов взаимодействия
   Сервисы взаимодействуют через протоколы, такие как SOAP, REST, gRPC или AMQP. Чаще всего используются web-сервисы с XML или JSON в качестве форматов данных.
3. Слабая связанность
   Сервисы проектируются так, чтобы быть независимыми и слабо связанными друг с другом. Они могут взаимодействовать через шину сообщений (ESB) или API Gateway, что уменьшает жесткие зависимости.
4. Повторное использование сервисов
   Сервисы разрабатываются так, чтобы их можно было повторно использовать в разных приложениях и процессах, что снижает дублирование кода.
5. Централизованное управление через ESB
   Enterprise Service Bus (ESB) – это централизованная шина сервисов, которая управляет маршрутизацией, преобразованием данных, оркестрацией сервисов и безопасностью.

Преимущества Service-Oriented Architecture

· Гибкость и повторное использование сервисов в разных системах

· Слабая связанность упрощает замену или модернизацию отдельных сервисов

· Упрощенное масштабирование и адаптация к изменяющимся бизнес-требованиям

· Возможность интеграции с устаревшими системами и внешними сервисами

Недостатки

· Сложность инфраструктуры, особенно при использовании ESB

· Высокие накладные расходы на межсервисное взаимодействие из-за XML и SOAP

· Трудности с обеспечением высокой производительности и отказоустойчивости при большом количестве сервисов

Применение Service-Oriented Architecture

· Корпоративные системы с множеством взаимосвязанных сервисов

· Интеграционные платформы, соединяющие старые и новые системы

· Государственные и банковские системы, где важна стандартизация взаимодействия между сервисами

Заключение

Service-Oriented Architecture – это мощный подход к построению распределенных систем, особенно в корпоративных средах. Он предоставляет гибкость и возможность интеграции с разными системами, но требует сложной инфраструктуры для управления сервисами. В современных системах SOA постепенно заменяется микросервисной архитектурой, которая предлагает более легковесный и гибкий подход.

Event-Driven Architecture (EDA)

это архитектурный стиль, в котором взаимодействие между компонентами системы происходит через события, а не через прямые вызовы API.

Основные характеристики Event-Driven Architecture

1. Асинхронное взаимодействие
   Компоненты системы реагируют на события в режиме реального времени, не дожидаясь отклика от других частей системы. Это снижает задержки и улучшает масштабируемость.
2. Использование событий как основного механизма связи
   События представляют собой изменения состояния системы, например, создание заказа или успешный платеж. Они публикуются одним сервисом и могут обрабатываться несколькими потребителями.
3. Два основных типа моделей взаимодействия
   Модель pub/sub (publish-subscribe) – один сервис публикует событие, а несколько других сервисов подписаны на его обработку.
   Модель event sourcing – все изменения состояния системы хранятся как последовательность событий, что позволяет восстанавливать состояние системы в любой момент.
4. Использование брокеров сообщений
   Для передачи событий часто используются брокеры сообщений, такие как Apache Kafka, RabbitMQ, Amazon SQS, Google Pub/Sub.
5. Слабая связанность компонентов
   Компоненты взаимодействуют только через события, а не через синхронные вызовы, что делает их более автономными и независимыми.

Преимущества Event-Driven Architecture

· Высокая масштабируемость – компоненты могут независимо обрабатывать события

· Гибкость – легко добавлять новые потребители событий без изменения существующих сервисов

· Устойчивость к сбоям – если один сервис временно недоступен, он может обработать события позже

· Историчность – при использовании event sourcing можно воспроизвести состояние системы в любой момент времени

Недостатки

· Сложность отладки и мониторинга – сложно отслеживать поток событий и выявлять ошибки

· Потенциальная избыточность данных – система может генерировать множество событий, которые нужно хранить

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

Применение Event-Driven Architecture

· Высоконагруженные системы, такие как финансовые платформы, интернет-магазины, IoT-системы

· Обработка транзакций и аналитики в реальном времени

· Системы, где важно реагирование на события, например, оповещения, мониторинг, автоматизация бизнес-процессов

Event-Driven Architecture – это мощный подход для построения масштабируемых, отказоустойчивых и гибких систем. Однако он требует хорошей инфраструктуры для работы с событиями и грамотного проектирования для управления сложностью взаимодействий.

Space-Based Architecture (SBA)

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

Основные характеристики SBA:

1. Разделение системы на узлы (Processing Units)

Приложение разбивается на независимые узлы, работающие параллельно.

Узлы могут динамически добавляться или удаляться для масштабирования.

Использование in-memory хранилищ

2. В отличие от традиционных систем, в SBA данные хранятся в оперативной памяти (RAM), что значительно ускоряет доступ к ним.

Применяются распределенные кэши (например, Hazelcast, Redis, Apache Ignite).

Минимизация использования центральной базы данных

3. SBA избегает узких мест, связанных с нагрузкой на БД, перераспределяя обработку данных по узлам.

База данных может использоваться только для долгосрочного хранения (event sourcing, асинхронная запись).

4. Event-Driven и Asynchronous Processing

Компоненты взаимодействуют через асинхронные события и очереди сообщений (например, Kafka, RabbitMQ).

Это повышает отказоустойчивость и снижает нагрузку на центральные сервисы.

5. Автоматическое масштабирование (Auto-Scaling)

Система автоматически добавляет новые узлы при увеличении нагрузки и удаляет лишние при снижении.

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

· Высокая производительность за счет работы в RAM.

· Хорошая масштабируемость без централизованных узких мест.

· Высокая отказоустойчивость благодаря распределенной архитектуре.

Недостатки:

· Сложность реализации и поддержки.

· Необходимость грамотного управления распределенной памятью.

· Потенциальные проблемы с консистентностью данных.

Применение SBA:

· Высоконагруженные веб-приложения (e-commerce, онлайн-банкинг).

· Системы реального времени (биржевые платформы, IoT, игровые серверы).

· Big Data и аналитические платформы.

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