Архитектура приложений
29) Чем монолитная архитектура отличается от микросервисной? В каких случаях микросервисы действительно нужны?
Монолитная архитектура - архитектура, при которой все приложение собрано в одном большом модуле. Все функции работают вместе как единая система и обычно используют одну общую базу данных.
Плюсы:
Простая структура: вся система собрана в одном приложении
Легче начать разработку: удобно для небольших проектов
Проще развернуть: запускается как один сервис
Удобно тестировать на старте: меньше распределенных компонентов.
Минусы:
Сбой в одном модуле может повлиять на все приложение
Труднее масштабировать: часто приходится усиливать всю систему целиком
Сложнее вносить изменения: модули сильно связаны между собой
При росте проекта поддержка становится тяжелее
Микросервисы - подход к разработке, при котором приложение состоит из набора небольших независимых сервисов. Каждый сервис выполняет свою функцию, может разворачиваться отдельно и взаимодействует с другими через API. Нужны для того, чтобы сложное приложение разделить на независимые части. Каждая часть отвечает за свою задачу, может разрабатываться, обновляться и масштабироваться отдельно. Это делает систему более гибкой, удобной в сопровождении и устойчивой к сбоям.
Микросервисная архитектура оправдана когда система достигает такой сложности, при которой независимое разбиение на сервисы снижает технические и организационные ограничения монолита
Рост предметной области: в системы появляются устойчивые bounded contexts (каталог, заказы, платежи, доставка, пользователи). Модули имеют собственные правила, жизненный цикл и API-контракты
Несколько команд разработки: над системой работыют несколько команд. Требуется разделить ownership по сервисам, уменьшить число конфликтов в codebase и обеспечить независимые release cycles
Неравномерная нагрузка: разные части системы нагружаются по-разному. Например, поиск, каталог или уведомления требуют отдельного масштабирования. Важна возможность scale-out только нужных компонентов
Независимый деплой и частые изменения: если отдельные подсистемы обновляются часто, полезно деплоить их отдельно без пересборки и перезапуска всего приложения. Это особенно важно при CI/CD и коротких итерациях релизов
Требования к отказоустойчивости: если отказ одного модуля не должен останавливать всю систему, сервисная декомпозиция упрощают fault isolation, retries, очереди сообщений и деградацию функциональности.
Domain-Driven Design - подход к проектированию программных систем, при котором структура приложения строится вокруг предметной области (домена) и бизнес-логики, а не вокруг технических слоев, файлов или таблиц баз данных.
Пример:
30) Какие основные проблемы возникают в микросервисной архитектуре: взаимодействие сервисов, согласованность данных, API Gateway, логирование и мониторинг?
Проблемы:
Сетевые задержки(В монолите это обычно метод в памяти, в микросерсах сетевой запрос)
Синхронные вызовы (Если вызываемый сервис недоступен или отвечает слишком долго,вызывающий сервис может зависнуть, получить timeout или вернуть ошибку клиенту.)
Согласованность данных(В микросервисах данные могут обновляться не мгновенно, а постепенно)
API Gateway(Весь трафик проходит через gateway и если он падает то падает вся система)
Логирование и мониторинг(Если логи работают некорректно то разработчикам и DevOps-инженерам становится крайне сложно поддерживать систему и искать проблемы.)
Сложно находить ошибки
Долгий debugging
Невозможно отследить путь запроса
Нельзя анализировать производительность
