Привет Всем , вы на канале Системный Пазл, тут все о системном и бизнес анализе без воды.
Сегодня поговорим про выбор архитектуры приложения, на какие вопросы должен ответить аналитик. Разберем две основные архитектуры.
Ранее, в статье про основные архитектуры, мы разбирали, какие они бывают:
Теперь рассмотрим две часто используемые архитектуры и ответим на вопросы, чтобы облегчить себе выбор и правильно спроектировать систему.
Ниже приведены рекомендации по выбору между монолитной архитектурой и архитектурой SOA (Service-Oriented Architecture) в зависимости от ключевых факторов. Опять же, есть микросервисная архитектура, которая очень похожа на SOA. Ключевое отличие SOA, она имеет в классическом исполнение одну БД и шину данных ESB, в микросервисах, может быть на один сервис своя БД. Обычно таким отличием пренебрегают и используют в основном SOA c различными БД и ESB или KAFKA ( Rabbit). О которых мы поговорим в других статьях.
1. Функциональные Требования
Если требуется высокая модульность и независимость компонентов:
SOA: Подходит для ситуаций, когда функции системы могут быть разделены на отдельные сервисы с чётко определёнными интерфейсами.
Если приложение небольшое и не требует сложного разделения функциональности:
Монолит: Подходит для меньших приложений с ограниченным функционалом и простыми интеграциями.
2. Масштабируемость и Производительность
Если ожидается высокий рост нагрузки и необходимость горизонтального масштабирования:
SOA: Подходит, так как отдельные сервисы могут масштабироваться независимо, что позволяет более гибко управлять ресурсами.
Если приложение рассчитано на умеренную нагрузку и не требует масштабирования:
Монолит: Подходит, так как все компоненты работают как единое целое, и масштабирование достигается путём вертикального увеличения ресурсов.
3. Модульность и Развитие
Если требуется частое изменение и развертывание отдельных компонентов:
SOA: Позволяет разворачивать и обновлять отдельные сервисы независимо, что упрощает управление изменениями.
Если приложение разрабатывается и обновляется как единое целое:
Монолит: Подходит, так как обновления вносятся в одном месте, но может усложнить управление изменениями.
4. Интеграция и Взаимодействие
Если необходимо интегрировать с множеством внешних систем и сервисов:
SOA: Обеспечивает гибкость для интеграции с различными системами через стандартизированные интерфейсы и протоколы.
Если интеграция с внешними системами минимальна:
Монолит: Подходит для приложений с ограниченными интеграционными потребностями.
5. Управление и Обслуживание
Если требуется сложное управление конфигурацией и обслуживание множества независимых компонентов:
SOA: Позволяет централизованно управлять и мониторить различные сервисы.
Если система имеет небольшое количество компонентов и управление ими не требует сложных процессов:
Монолит: Управление конфигурацией и обслуживанием проще, так как все компоненты находятся в одном приложении.
6. Разработка и Поддержка
Если команда разработчиков большая и распределенная, или требуются разные технологии и языки:
SOA: Подходит для распределенных команд и многогранных проектов.
Если команда небольшая и работа сосредоточена на одном приложении:
Монолит: Подходит для небольших команд и менее сложных проектов.
7. Безопасность
Если требуется высокая изоляция между компонентами и строгий контроль доступа:
SOA: Обеспечивает изоляцию и контроль безопасности на уровне отдельных сервисов.
Если система имеет меньше компонентов и требуется меньшая изоляция:
Монолит: Подходит для менее критичных приложений, где безопасность может быть менее сложной.
8. Бюджет и Ресурсы
Если бюджет ограничен и требуются более простые решения:
Монолит: Может быть более экономичным решением, так как требует меньше ресурсов для разработки и поддержки.
Если бюджет позволяет инвестировать в сложную архитектуру и требуется гибкость:
SOA: Обеспечивает более гибкое решение, но может потребовать дополнительных ресурсов и затрат на разработку и поддержку.
9. Время и Риски
Если проект требует быстрой реализации с минимальными рисками:
Монолит: Быстрее разрабатывать и развертывать, так как все компоненты находятся в одном приложении.
Если проект имеет длинные сроки и требует тщательного планирования и управления рисками:
SOA: Позволяет управлять изменениями по частям, но может быть более сложным в плане проектирования и внедрения.
10. Гибкость и Адаптируемость
Если нужно обеспечить высокую адаптируемость к изменениям бизнес-требований:
SOA: Обеспечивает гибкость и возможность независимого изменения и развертывания компонентов.
Если система менее подвержена частым изменениям и обновлениям: Монолит: Подходит для приложений с более стабильными требованиями и изменениями.
Заключение
Выбор SOA предпочтителен, если система требует высокой модульности, независимости компонентов, масштабируемости, гибкости в интеграции и частых обновлений.
Выбор монолитной архитектуры подходит, если система небольшая, с ограниченными интеграционными потребностями, требует меньше ресурсов и более простой модели разработки и развертывания.
Этот подход помогает сделать обоснованный выбор архитектуры, соответствующий требованиям и ограничениям вашего проекта.
Если вам понравилась статья, ставьте лайк и пишите комментарии, какие вопросы нужно еще учесть при выборе архитектуры?
Если нужен доп. разбор и сравнение архитектуры микро-сервисов, то также напишите в комментариях!