На собеседованиях не обойтись без знаний о микросервисной архитектуре. В сети много информации, но для ответа на собеседовании не нужно знать всё.
Разберёмся, как отвечать на вопрос: "Какие преимущества и недостатки у микросервисной архитектуры?" или "Расскажите про микросервисную архитектуру?".
Сравнивать будем с монолитной архитектурой.
Микросервисная архитектура — это архитектура, при которой программное обеспечение разбивается на небольшие, слабо связанные модули. В противовес монолитной архитектуре, когда ПО функционирует в одном модуле.
✅ Преимущества
🚀 Независимость разработки и развёртывания
Команда работает над микросервисами автономно. Это позволяет выкатывать релизы независимо, что является плюсом для бизнеса.
В монолите приходится деплоить функциональность одновременно. Это может вызывать конфликты между командами из-за несостыковок в релизном цикле.
🛡 Изоляция отказов
Падение одного микросервиса не останавливает работу системы, потому что компоненты изолированы.
В монолите нарушение логики одного модуля приводит к падению приложения.
📈 Независимое масштабирование
Каждый микросервис масштабируется независимо, что позволяет гибко настроить количество экземпляров исходя из нагрузки.
Монолит масштабируется целиком. Нельзя масштабировать только критичные компоненты. Это приводит к неэффективному расходованию ресурсов.
❌ Недостатки
🐛 Сложность отладки
Отладка бага затрагивает цепочку из нескольких сервисов с разными логами, БД, а также каскадными вызовами, что может превратить получасовую задачу в многодневное расследование. Воспроизведение багов локально может быть невозможным из-за необходимости поднимать несколько сервисов. Даже с системами наблюдаемости, которые включают централизованное логирование, мониторинг и распределённую трассировку, не всегда удаётся быстро локализовать проблему.
В монолите код располагается в одном месте, что упрощает анализ сбоев и сокращает трудозатраты.
💾 Консистентность данных
Каждый микросервис использует отдельную базу данных. Это архитектурный паттерн database per service. Из-за этого об ACID-транзакциях между микросервисами можно забыть. Разработчики руководствуются принципом согласованности в конечном счёте, Eventual Consistency. Это значит, что система может быть неконсистентной в конкретный момент времени и придёт в согласованное состояние когда-нибудь. Консистентность данных обеспечивается передачей асинхронных сообщений между микросервисами, созданием SAGA и компенсирующих транзакций. Это сложно проектировать и ещё сложнее отлаживать.
В монолите бизнес-сценарии выполняются в одной транзакции, что обеспечивает полную консистентность данных.
💰 Накладные расходы на инфраструктуру
Необходимо вкладываться в CI/CD и наблюдаемость системы. Без них поставка и решение сбоев будет занимать много времени, потому что в распределённой системе сложнее искать причины и места сбоев. Этот вклад требует существенных затрат на инфраструктуру и опытных DevOps и SRE инженеров.
В монолите проще находить причину сбоев, поэтому можно не вкладываться в инфраструктуру.
🏢 Когда использовать монолит
Монолит идеален для стартапов и небольших команд, где нужно быстро валидировать бизнес-гипотезы и выходить на рынок. Отладка и разработка происходят быстрее. Затраты на сопровождение минимальны.
Используй монолит для новых проектов и проверки гипотез.
🔗 Когда использовать микросервисы
Микросервисы подходят компаниям с зрелыми командами, где направления бизнеса развиваются независимо и с разной скоростью.
Используй микросервисы для проектов, в которых важна отказоустойчивость и гибкое масштабирование, а также достаточно ресурсов для поддержания инфраструктуры.
📚 Выводы
Рекомендую ознакомиться с книгой Криса Ричардсона «Микросервисы». Это — база знаний для старта.
Ты узнал больше о микросервисной архитектуре. Напиши в комментариях, какие ещё преимущества и недостатки ты видишь!
#техничка #backend