Что такое гранулирование микросервисов: как выбрать правильный размер сервиса и не утонуть в сложности

Что на повестке дня: практический разбор гранулирования микросервисов: DDD-границы, синхронные и асинхронные вызовы, саги, outbox, SLO и метрики, которые помогают выбрать правильный размер сервиса.

В мире микросервисов есть соблазн упростить правило до одной фразы: «чем меньше сервис, тем лучше». Звучит эффектно, но на боевой системе это обычно работает до первого инцидента. Слишком крупный сервис быстро превращается в мини-монолит, а слишком мелкие сервисы начинают «шуметь» сетью, ретраями, таймаутами и каскадными отказами.

Гранулирование — это не про размер репозитория и не про количество контейнеров в кластере. Это про корректные границы ответственности: где заканчивается одна бизнес-операция и начинается другая, где допустима конечная согласованность, а где нужна строгая транзакционность. На этом этапе архитектура либо помогает выпускать фичи, либо превращается в дорогой распределенный лабиринт.

Если смотреть прагматично, гранулярность напрямую влияет на ведущее время изменений, MTTR, стоимость эксплуатации и когнитивную нагрузку команды. Ирония в том, что «микро» без инженерной дисциплины легко становится «макро-проблемой». Поэтому главный вопрос звучит так: не «насколько маленький сервис», а «насколько независимый и управляемый сервис».

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

Технически это проверяется очень просто. Если сервис владеет своей схемой данных (database-per-service), публикует версионируемый контракт (/v1, эволюция схемы для событий) и может деплоиться без синхронного релиза соседей — гранулярность близка к рабочей. Если же каждый релиз требует «договориться с тремя командами и пятью таблицами», границы выбраны неудачно.

Еще один важный маркер — профиль взаимодействия. Синхронные вызовы через HTTP/gRPC хороши для коротких запросов с жесткими SLA, но при длинных бизнес-процессах лучше переходить к событийной модели через брокер (Kafka/RabbitMQ) и оркестрацию/хореографию саг. Это снижает связанность и помогает переживать частичные отказы без глобальных блокировок.

Начинать лучше с карты бизнес-капабилити и change-frequency анализа. Если два модуля почти всегда меняются вместе, их разделили рано. Если один требует независимого масштабирования (например, search или recommendation), а второй стабилен, выделение оправдано и экономически, и технически.

Дальше включается проверка на транзакции и консистентность. Если сценарий требует атомарности в рамках одной предметной операции, не стоит насильно «разрезать» его на несколько сервисов без компенсаций. В распределенной архитектуре ACID между сервисами заменяется паттернами: saga для бизнес-транзакций, outbox/inbox для надежной доставки, idempotency key для безопасных повторов.

После этого границы валидируются наблюдаемостью. У каждого сервиса должны быть SLI/SLO: latency (p95/p99), error rate, saturation, throughput. Если после декомпозиции растут p99, число межсервисных инцидентов и время диагностики, значит выиграли «красоту схемы», но проиграли эксплуатацию. Хорошая гранулярность — та, что улучшает реальные метрики, а не только диаграмму в Miro.

Самая частая ошибка — дробление по техническим слоям (user-controller-service-repo как отдельные сервисы), а не по бизнес-возможностям. В итоге получаются сотни сетевых вызовов на один пользовательский сценарий, хрупкие зависимости и сложная трассировка. Это и есть распределенный монолит, только с более дорогим продакшеном.

Вторая ошибка — отсутствие контрактной дисциплины. Без реестра схем, версионирования событий и обратной совместимости любой релиз начинает ломать соседей. Добавьте к этому отсутствие идентификатора корреляции, и инцидент превращается в квест «кто сломал цепочку». Техническая зрелость здесь важнее «модности» архитектуры.

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

Гранулирование — это управленческо-технический баланс: границы предметной области, независимость релизов, автономность данных и контроль сложности взаимодействий. Нет универсального «идеального размера» сервиса, есть измеримый эффект от выбранной декомпозиции.

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

И да, самый трезвый критерий всегда один: после очередного «улучшения архитектуры» команде стало быстрее и надежнее работать — или просто стало больше диаграмм. Если второе, гранулирование нужно пересматривать.