Построение архитектуры web приложения — это комплекс мероприятий, направленных на то, чтобы четко определить, как будет построена система. Сегодня я расскажу только о верхнем уровне определения архитектуры: то есть о том, что может быть определено при наличии ограниченного количества информации.
Важно понимать, что нет идеального решения при построении архитектуры, мы не можем сказать, что этот архитектурный паттерн подходит под любую задачу и использовать следует только его. Все зависит от конкретного проекта, его задач и от того, как работает веб приложение.
Но вы можете построить все, что угодно на любой архитектуре, но будет ли это оправдано? Вряд ли.
Итак, что нам нужно для определения архитектуры проекта:
- Техническое задание
- Архитектор или человек с богатым опытом разработки
- Понимание дедлайнов
- Понимание жизненного цикла проекта
- Понимание нагрузки
Как видим, это очень много информации, которую нужно проанализировать для того, чтобы определиться с полной архитектурой проекта. Но для ВЕРХУРОВНЕВОЙ архитектуры иногда нам хватит только идеи проекта.
В общей сложности отделяют три вида архитектуры веб-приложений:
- Монолит
- Микросервисы
- Серверлес
Монолит
Монолит — это архитектурное решение, в котором все компоненты и модули тесно связаны между собой и зависят друг от друга, подробнее проиллюстрировано на изображении.
В общем, считается, что это устаревшее архитектурное решение, но я с этим не согласен, потому что у такого решения есть свои преимущества, и оно очень хорошо подходит при построении некоторых проектов.
Достоинства:
- Простота развертывания. Монолиты очень быстро и относительно просто развертывать, благодаря тому что у монолита обычно единая точка входа
- Разработка. Разработка монолита обычно происходит быстро, потому что все компоненты и модули находятся в одной кодовой базе и всегда под рукой
- Отладка. Отладка монолита очень упрощена за счет того, что все рядом, и есть возможность отследить все звенья выполнения кода
Недостатки:
- Масштабирование. Монолиты масштабируются только целиком, то есть если нагрузка растет только на один модуль, мы не можем масштабировать только этот модуль, мы должны масштабировать весь монолит
- Надежность. Если монолит выходит из строя, то выходит весь целиком
- Изменение и обновление технологий. В монолите это почти невозможно
- Недостаточная упругость. Монолиты негибкие, то есть смена одного модуля в монолите почти всегда будет влиять на другой модуль
Микросервисы
Микросервисы — это архитектурное решение, которое базируется на распределении модулей на отдельные системы, которые общаются между собой посредством сообщений.
Вся система — это набор маленьких систем, которые связаны между собой, подробнее проиллюстрировано на изображении.
Это очень модная и популярная архитектура, но у нее есть свои недостатки и, на мой взгляд, она совсем не подходит для маленьких и средних проектов.
Достоинства:
- Гибкость. Микросервисы очень гибки за счет того, что каждый сервис является самостоятельной системой, поэтому изменения в ней могут повлиять только на нее
- Масштабирование. В отличие от монолита, мы можем масштабировать только определенную часть системы потому, что она самостоятельна
- Гибкость технологий. В микросервисах каждая из подсистем может быть реализована на любом языке программирования и с помощью любых технологий
- Надежность. Обычный выход из строя одной из подсистем не ломает всю систему в целом
Недостатки:
- Процесс разработки. Микросервисы очень непросто разрабатывать, потому что вам нужно производить несколько подсистем и наладить взаимодействие между ними
- Коммуникация команд. Очень часто бывает так, что одна команда разрабатывает одну подсистему, поэтому нужно наладить коммуникации между командами, чтобы наладить взаимодействие между подсистемами
- Отладка. Микросервисы очень сложно отлаживать, потому что нужно найти, какой сервис сломался, и почему
- Развертывание. Начальное развертывание очень непростое, и добавление новых сервисов требует настройки ключевых частей проекта
Рекомендуем публикацию по теме
Серверлесс
Серверлесс — это архитектурное решение, которое фокусируется на разработке вместо развертывания и взаимодействия между сервисами.
Сервверлес — это альтернатива микросервисам, которая автоматизирует все развертывание благодаря облачным технологиям. Более подробно проиллюстрировано на изображении. Из названия можно подумать, что здесь отсутствует серверная часть, но это не так, здесь отсутствует работа с сервером как со средой.
Достоинства:
- Гибкость. Серверлес очень гибок за счет обособленности одного модуля от другого
- Абстракция от операционной системы. Облако само решит, какая ОС нужна и как ее нужно настроить
- Легкий порог входа. Обычно серверлес это очень простой, обособленный код, поэтому разобраться с проектом несложно
- Надежность. При правильном построении проекта надежность так же, как и у микросервисов
Недостатки:
- Гибкость. Да, это тоже минус, потому что у разработчика ограничено влияние на масштабирование, все решает облако
- Отладка. Так же, как в микросервисах, отладка усложнена взаимодействием между компонентами
- Vendor Lock. Каждое облако работает по собственным правилам, поэтому переезд с одного облака на другое почти невозможен
- Cascade Failur. При неправильном построении проекта компоненты могут сильно влиять на другие компоненты, что приводит к падению всего проекта
Вывод
Поняв все преимущества и недостатки той или иной архитектуры, мы смело можем выбрать верхнеуровневую архитектуру, если у нас есть ограниченная информация по проекту.
Еще раз подчеркиваю, что любой проект можно выполнить на любой архитектуре, но это может быть неэффективным либо в плане разработки, либо в плане эксплуатации проекта.
