Монолит
Это классический подход к архитектуре приложений, при котором вся логика приложения упаковывается в одну большую программу. Все компоненты связаны тесной зависимостью и развертываются единым блоком. Хотя такая архитектура проста в начальной стадии разработки, она становится проблематичной при росте проекта, усложняя поддержку, развитие и масштабирование.
Service-Oriented Architecture (SOA)
Сервис-ориентированная архитектура представляет собой подход, при котором приложение состоит из набора слабо связанных сервисов, взаимодействующих друг с другом через стандартные интерфейсы (например, веб-сервисы). SOA облегчает масштабирование и повторное использование функциональности, но увеличивает сложность настройки и поддержания взаимодействия между компонентами.
Service-Based Architecture
Подход, похожий на SOA, но акцент смещён на предоставление высокоспециализированных сервисов, минимизирующих зависимости и обеспечивающих чёткую границу ответственности каждого сервиса. Такой подход повышает управляемость и масштабируемость приложения, облегчая независимую разработку и изменение отдельных компонентов.
Space-Based Architecture
Архитектурный подход, оптимизированный для достижения высокой доступности и низкой задержки запросов путём распределения данных и вычислений по пространству кластера серверов. Основная идея заключается в размещении данных рядом с местом их обработки, уменьшая нагрузку на сеть и повышая скорость отклика системы.
Event-Driven Architecture
Модель построения программного обеспечения, при которой система построена на обработке событий, генерируемых различными источниками. Каждое событие запускает реакцию одного или нескольких обработчиков, обеспечивая асинхронность и децентрализацию процессов. Такая архитектура обеспечивает высокий уровень гибкости и адаптируемости к изменению потоков данных.
Microservices
Микросервисная архитектура подразумевает декомпозицию приложения на набор небольших, специализированных служб, каждая из которых реализует отдельную область функционала. Каждая служба работает самостоятельно, управляется отдельно и может развиваться независимо от остальных. Это способствует улучшению масштабируемости, отказоустойчивости и развитию каждой службы командой экспертов конкретной области.
Модульный монолит
Промежуточный вариант между монолитной и сервис-ориентированной архитектурой. Приложение разбито на модули, которые являются внутренними единицами структуры, сохраняя единую базу исходников и единый процесс сборки и развёртывания. Несмотря на улучшение внутренней организации, модульный монолит сохраняет большинство недостатков классической монолитной архитектуры.
Оценка архитектурных стилей:
Ниже представлена таблица, сравнивающая различные архитектурные стили по ряду ключевых характеристик. Каждый стиль оценивается по пятибалльной шкале (1 — минимальная степень реализации характеристики, 5 — максимальная).
Комментарии по оценкам по сравнительной таблице ниже:
Монолит
– Гибкость низкая, так как изменения требуют полной сборки и тестирования приложения.
– Абстрагированность слабая, так как кодовая база тесно связана между собой.
– Конфигурируемость ограниченная возможность изменять отдельные компоненты без влияния на всю систему.
– Высокая стоимость изменений и масштабирования.
– Сложное развертывание, одна большая сборка.
– Деление доменов: минимальное разделение бизнес-задач внутри одной системы.
– Эластичность плохая, тяжело адаптироваться к изменениям нагрузки.
– Развитие: сложно эволюционировать отдельными частями.
– Низкий уровень отказоустойчивости, проблемы влияют на весь продукт.
– Интеграция: высокая интеграция внутри самого продукта.
– Совместимость: полная совместимость внутри одного процесса.
– Производительность: высокие показатели производительности благодаря отсутствию сетевых задержек.
– Масштабируемость: низкая масштабируемость отдельных частей.
– Простота: простая структура проекта, легко начать разработку.
– Тестируемость: сложная тестируемость больших модулей вместе.
Сервис-Ориентированная Архитектура (SOA)
– Более гибкая, чем монолит, однако менее гибкая, чем современные микросервисы.
– Среднее значение абстрагируемости компонентов и простоты конфигурации.
– Высокая стоимость инфраструктуры SOA-решений.
– Улучшенная изоляция сервисов и способность реагировать на события, но менее независимая инфраструктура.
– Интеграционные возможности хорошие, особенно в крупных корпоративных системах.
Service-Based Architecture
– Близкий родственник SOA, однако ориентированный больше на независимость сервисов друг от друга.
– Хороший баланс между гибкостью и интеграционными возможностями.
– Конкретизация границ сервисов помогает разделить ответственность и обеспечить улучшенную производительность и тестирование.
Space-Based Architecture
– Ориентация на высокую пропускную способность и низкую латентность за счёт размещения данных близко к вычислительным узлам.
– Отличается высокой эластичностью и масштабируемостью, но требует значительных ресурсов.
– Уровень интеграции ниже, так как сервисы работают автономно, обмениваясь сообщениями через общую инфраструктуру.
Event-Driven Architecture
– Высокоэластичная архитектура, основанная на событиях.
– Легкость реагирования на внешние изменения, хорошая поддержка agile-разработки.
– Высокие затраты на создание устойчивых систем обработки событий и обеспечение надежности передачи сообщений.
– Тестирование сложнее, поскольку многие процессы зависят от последовательности событий.
Микросервисы
– Максимальная степень разделения ответственности и независимости сервисов.
– Низкое влияние на общий проект при изменении отдельной части.
– Развёртываются независимо друг от друга, обеспечивая отличную масштабируемость и устойчивость к сбоям.
– Очень высокая стоимость поддержки инфраструктурных решений.
– Сложность управления и интеграции большого количества независимых сервисов.
Модульный монолит
– Промежуточная форма между классическим монолитом и сервис-ориентированными архитектурами.
– Достоинства классического подхода к разработке (простота начала разработки), плюс небольшая структурированность на уровне модулей.
– Недостаточная гибкость, отсутствие преимуществ современных распределённых подходов.
Таким образом, каждый стиль имеет свои сильные стороны и ограничения, выбор зависит от конкретных требований бизнеса и команды разработчиков.
| Characteristics | Monolith | Service-Oriented | Service-Based | Space-Based | Event-Driven | Microservices | ModularMonolith | Microkernel |
| Agility | 2 | 3 | 4 | 3 | 4 | 5 | 3 | 4 |
| Abstraction level | 1 | 3 | 4 | 4 | 4 | 5 | 2 | 4 |
| Configurability | 2 | 3 | 4 | 4 | 4 | 5 | 3 | 4 |
| Cost | 1 | 3 | 4 | 4 | 4 | 5 | 2 | 4 |
| Deployability | 1 | 3 | 4 | 4 | 4 | 5 | 2 | 4 |
| Domain partitioning | 1 | 3 | 4 | 4 | 4 | 5 | 2 | 4 |
| Elasticity | 1 | 3 | 4 | 4 | 4 | 5 | 2 | 4 |
| Evolvability | 2 | 3 | 4 | 4 | 4 | 5 | 3 | 4 |
| Fault Tolerance | 1 | 3 | 4 | 4 | 4 | 5 | 2 | 4 |
| Integration | 5 | 4 | 3 | 3 | 3 | 2 | 4 | 3 |
| Interoperability | 5 | 4 | 3 | 3 | 3 | 2 | 4 | 3 |
| Performance | 4 | 3 | 3 | 3 | 3 | 3 | 4 | 3 |
| Scalability | 1 | 3 | 4 | 4 | 4 | 5 | 2 | 4 |
| Simplicity | 5 | 3 | 3 | 3 | 3 | 2 | 4 | 3 |
| Testability | 2 | 3 | 4 | 4 | 4 | 5 | 3 | 4 |