Микросервисы часто продают компании как способ дать командам свободу: каждая отвечает за свою часть продукта и выпускает её, не ожидая остальных. Звучит убедительно. Но если после разделения любое изменение по-прежнему требует пяти согласований, архитектура не дала независимости. Она лишь добавила больше процессов и серверов.
Поэтому я бы начинал не с вопроса, сколько сервисов нужно, а с другого: какая зависимость сегодня мешает бизнесу работать и действительно ли сервисная граница её устранит?
Независимость появляется не от количества приложений
Представим интернет-магазин. Каталог обновляется часто, платежи требуют осторожных изменений, а уведомления живут своим ритмом. Когда эти области связаны единым релизом, одна команда может ждать другую.
Выделение самостоятельных сервисов может позволить командам выпускать изменения отдельно, выбирать подходящую инфраструктуру и масштабировать ту нагрузку, которая выросла. Не обязательно увеличивать весь продукт только потому, что резко подорожал расчёт рекомендаций.
Но это сработает лишь при понятном владении и достаточно стабильных контрактах. Если сервис каталога напрямую читает таблицы платежей, никакой независимости у них нет. Базы могут работать на разных серверах — зависимость от этого не исчезнет.
Что происходит с обычным заказом
Покупатель нажимает «Оформить». В монолите часть шагов иногда можно провести одной транзакцией: либо изменения сохранились вместе, либо нет. В сервисной архитектуре заказ, остатки и оплата могут принадлежать разным системам.
Предположим, заказ уже создан, а платёжный сервис не ответил. Что показываем клиенту? Можно ли повторить запрос, не списав деньги дважды? Когда освобождать зарезервированный товар? Здесь потребуется явная модель состояний, повторная обработка сообщений, защита от дубликатов и, возможно, компенсационные операции.
Это не аргумент против микросервисов. Это часть их стоимости, которую удобно забывать при обсуждении «независимых команд». Пользователь взаимодействует с одним продуктом, а не с набором внутренних сервисов, и не обязан разбираться, на каком шаге они перестали договариваться.
Один сбой больше не означает один понятный сбой
Когда запрос пересекает несколько сервисов, ошибка может быть где угодно: сеть, недоступный компонент, несовместимая версия интерфейса, задержка очереди, истёкший таймаут. По отдельности всё может работать, а покупка так и не завершится.
Понадобятся сквозная диагностика, работа с ограничениями нагрузки, таймаутами, повторными запросами и безопасными отказами. Отдельное развёртывание также не гарантирует изоляции сбоя: если сервисы постоянно ждут друг друга синхронно, один перегруженный компонент способен затормозить цепочку.
И ещё появляются постоянные организационные расходы: кто владеет контрактами, кто реагирует ночью, как согласуются изменения, где заканчивается ответственность одной команды и начинается другой. Произвольное дробление функциональности только увеличивает число таких границ.
Где бизнес действительно выигрывает
Хороший сценарий — у компании несколько команд с самостоятельными продуктовыми областями, достаточно разных нагрузок и релизных циклов, а общая система уже заставляет их ждать. Тогда сервисная архитектура может уменьшить зависимость поставки и позволить менять отдельные части без пересборки всего приложения.
Проверять выгоду стоит по последствиям: стали ли быстрее проходить изменения, сократилось ли ожидание между командами, удалось ли ограничить влияние отказов, не выросло ли время расследования инцидентов больше, чем выигрыш от отдельных релизов.
Если же команда небольшая, область ответственности ещё постоянно меняется, а поставка и так быстрая, дополнительные сетевые границы обычно не главный кандидат на инвестиции.
Сначала договориться о границах
Я бы не стал разделять связанную систему сразу на десятки сервисов. Сначала полезно выяснить, кто владеет данными и бизнес-операциями, убрать случайные зависимости и проверить, можно ли добиться эффекта внутри модульного монолита.
Если есть отдельная функция, которая действительно требует своего режима эксплуатации, её можно выделять постепенно. На этом шаге появятся реальные требования к удалённому интерфейсу, диагностике и поведению при отказах — не абстрактная архитектура на будущее, а конкретные ограничения.
Микросервисы имеют смысл, когда организация готова использовать независимость. И готова платить за то, что эта независимость перестаёт быть бесплатной.