Микросервисы (microservices): что это, когда нужны и чем отличаются от монолита

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

Монолит собирают и выпускают как одну систему. В микросервисах части продукта живут отдельными процессами и общаются по сети. Это даёт независимость, но приносит контракты, таймауты, трассировку и более сложную диагностику. То есть свобода здесь всегда идёт рядом с новой ценой.

Контракт — это граница доверия между сервисами. Если команда меняет поле или смысл ответа без согласования, ломается не один вызов, а цепочка зависимых систем. Поэтому здесь важны версии, обратная совместимость и понятные правила изменения API. Без этого независимый выпуск быстро становится хаотичным.

Запрос пользователя часто проходит через несколько сервисов подряд. Без журналов и трассировки команда видит только общий сбой на входе. Наблюдаемость нужна не для красоты, а чтобы быстро понять, где именно сломалась цепочка. И кто должен чинить её первым.

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

Чаще всего сервисы выделяют слишком рано и режут не по границе домена, а по слоям или командам. В итоге код разъезжается по процессам, а зависимость между частями остаётся прежней. Такой распределённый монолит дороже, но почти не даёт реальной свободы.

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

В монолите весь код живёт одним куском и выпускается общим релизом. Микросервисы разбивают его на независимые части: каждую команда деплоит отдельно, но за независимость платит сетью, контрактами и распределёнными данными.

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

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

Двумя способами: синхронно через REST или gRPC — запрос-ответ здесь и сейчас; и асинхронно через брокер сообщений вроде Kafka — сервис публикует событие, а получатель обрабатывает его позже. В вакансиях оба подхода встречаются одинаково часто.

Единая точка входа для внешних запросов: принимает вызов клиента, маршрутизирует его в нужный сервис, собирает ответ и берёт на себя авторизацию, лимиты и логирование. Клиент не знает, сколько сервисов внутри.

Канонический подход — database per service: каждый сервис владеет своими данными, а соседи ходят к ним только через API. Это даёт независимость схемы и деплоя, но убирает общие транзакции — согласованность строят иначе.

Способ провести бизнес-операцию через несколько сервисов без общей транзакции. Шаги выполняются по цепочке, а при сбое запускаются компенсирующие действия, которые откатывают уже сделанное и возвращают систему в согласованное состояние.

Kafka стоит рядом с микросервисами в заметной доле вакансий: через неё сервисы обмениваются событиями асинхронно. Отправитель не ждёт получателя, пиковую нагрузку сглаживает очередь, а история событий позволяет пересобрать состояние.

Kubernetes — постоянный сосед микросервисов в вакансиях: он запускает десятки сервисов, следит за их живучестью, перезапускает упавшие и масштабирует нагруженные. Микросервисы дробят приложение, а Kubernetes управляет этим парком в проде.

Зарплату определяет роль и грейд, а не сам навык; медиана по микросервисам — одна из самых высоких на рынке, актуальные цифры — в рыночном блоке этой страницы. Связки с gRPC и ClickHouse поднимают вилку ещё выше.

Как первый навык — нет: junior-позиций здесь мало, рынок смещён к senior. Сначала берут язык, SQL, REST API и одну базу, и уже поверх крепкой основы разбираются с распределёнными системами.

Слой, который управляет трафиком между сервисами внутри кластера: берёт на себя ретраи, таймауты, шифрование и метрики, вынося эту логику из кода сервисов. Нужен, когда сервисов становятся десятки.

Сложность не в отдельном сервисе, а в связях между ними: сетевые сбои, распределённые данные, отладка запроса через пять сервисов. Skew к senior (8.4) и порог входа отражают именно эту эксплуатационную цену.

По границам предметной области (bounded context), а не по слоям кода. Обычно применяют Strangler Fig: рядом с монолитом растёт новый сервис, трафик на него переводят постепенно, а старую часть выключают.

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

Системный аналитик — главная роль по этому навыку в московских вакансиях. Он описывает границы сервисов, контракты API и события между ними, поэтому язык микросервисов нужен ему не меньше, чем разработчику.

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

Точного числа нет: смысл не в количестве, а в том, что каждый сервис отвечает за одну понятную область и выпускается независимо. Два-три сервиса с чёткими границами — уже микросервисы, сотня склеенных — нет.