В последние годы стало чуть ли не главным трендом в backend-разработке - микросервисной архитектуре. Если вы хоть раз слышали фразы вроде «у нас всё на микросервисах» или «мы уходим от монолита», то мои умозаключения как раз для вас. Я постараюсь объяснить все максимально человечно, без заумных терминов, но с пользой.

Что вообще такое микросервисы?

Представим себе ассоциацию помойного ведра. Один. Цельный. Все в нем: пластик, органика и прочее - все перемешано и держится вместе.

Это и есть монолитное приложение. Всё работает в одном процессе, одна база данных, один деплой, одна команда (или одна помойка ).

А теперь представим, что мы эту помойку разделили на разные контейнера, одна для пластика, другая для органики и так далее. Каждый мусор можно выкидывать отдельно, не скидывая все одну помойку. Вот это и есть микросервисы - небольшие, независимые сервисы, каждый из которых отвечает за свою конкретную задачу.

Например:

• один сервис отвечает за аутентификацию,
• другой - за каталог товаров,
• третий - за оплату,
• четвёртый - за уведомления.

Каждый из них — это отдельное приложение со своей логикой, своей базой данных (иногда), своим API и своей жизнью.

Почему вообще перешли на микросервисы?

Все просто: монолиты - это удобно в начале, но когда проект растёт, они становятся монстром.

Мы хотим исправить баг в модуле оплаты, но чтобы выкатить фикс - нужно пересобирать и перезапускать ВСЁ приложение. Или мы хотим масштабировать только модуль чата - но масштабируете всё, потому что оно все в одном. Или у нас 50 разработчиков, и все правят один и тот же код - конфликты, задержки, хаос.

Микросервисы решают эти проблемы:
Независимость - можно менять, тестировать и деплоить каждый сервис отдельно.
Масштабируемость - можно масштабировать только то, что реально нагружено.
Технологическая свобода - каждый сервис может быть написан на своем стеке (Python, Go, Node.js - да что угодно).
Устойчивость - если упал один сервис, не обязательно падает всё приложение.
Командная автономия - разные команды могут работать над разными сервисами без постоянных конфликтов.

Но… всё ли так радужно?

Конечно, нет

Микросервисы - это не волшебная таблетка, а скорее обмен одних проблем на другие. Если монолит - это один большой камень, который тяжело двигать, то микросервисы - это мешок с мелкими камнями, которые более менее можно перетаскивать.

А теперь о плохом подробнее:

• Сложность системы в целом - сервисов много, связи между ними, нужно следить за тем, чтобы всё работало вместе.
• Сетевые вызовы - вместо быстрых вызовов внутри процесса - HTTP/gRPC/RPC между сервисами. Задержки, ошибки сети, таймауты.
• Согласованность данных - если у каждого сервиса своя БД, как обеспечить целостность? Транзакции между сервисами - это боль.
• Логирование и мониторинг - где искать ошибку, если запрос прошёл через 5 сервисов? Нужны распределённые трейсы (например, Jaeger, Zipkin).
• DevOps-нагрузка - деплой, CI/CD, оркестрация (Kubernetes, Docker Swarm), конфигурация, сервис-дискавери - всего этого в монолите почти не было.

Щас сюда должен прийти @Jspi и закидать меня х*ями в панамку сказав используй FSD

Когда переходить на микросервисы?

По моему личному опыту: не начинайте с микросервисов!

Если вы делаете MVP, стартап или небольшой проект монолит полюбому ваш друг. Он проще, быстрее, дешевле в поддержке. Микросервисы - это инвестиция, которая окупается, когда проект уже вырос и стал сложным, тогда есть смысл разбивать код на части.

Правило большого пальца: если у вас больше 3-5 команд, которые постоянно сталкиваются в коде, или если часть системы явно требует отдельного масштабирования - тогда можно задуматься о разделении. Если же Вы пилите в несколько разрабов то микросервисы точно не нужны.

И когда ваш проект уже подрос и справляться с архитектурой становится сложно, вот тогда начинайте к подходу через микросервисы. Начните с одного-двух сервисов. Постепенно, иначе рискуете утонуть.

Вместо вывода

Микросервисы - это мощный инструмент, но не для всех и не всегда. Они дают свободу, гибкость и масштабируемость, но требуют зрелости команды, инфраструктуры и всех. прочих процессов.

Не гонитесь за модой. Сначала решайте бизнес-задачу. А потом уже думайте, как ее лучше поддерживать и развивать.