Год назад термин «микросервисы» ещё спорил за внимание с «SOA» и казался очередным словом из презентаций. За двенадцать месяцев мы провели несколько внедрений – от учётной системы крупного ритейлера до ведомственного портала и накопили достаточно шишек, чтобы говорить предметно. Ниже – без рекламы архитектурного стиля, только то, что подтвердилось на боевых проектах.

Где разбиение действительно окупилось

Микросервисы выигрывают там, где у частей системы разная скорость изменений и разная нагрузка. На проекте для розничной сети модуль расчёта цен и акций менялся еженедельно, а каталог товаров – раз в квартал. Раздельный деплой снял главную боль: правку в ценообразовании выкатывали за полчаса, не пересобирая монолит и не останавливая остальные функции.

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

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

Что оказалось дороже, чем обещали статьи

Распределённая система – это распределённые отказы. Там, где в монолите был один стектрейс, теперь цепочка из шести вызовов между сервисами, и упавший запрос приходится собирать по кускам. Без сквозной трассировки и единого сбора логов отладка превращалась в археологию. Спасло то, что мы заранее поставили централизованное логирование на ELK: без него команда поддержки утонула бы в первый же месяц промышленной эксплуатации.

Второй счёт – за данные. Идея «у каждого сервиса своя база» красива на схеме, но согласованность между ними приходится обеспечивать руками: компенсирующие транзакции, идемпотентность, обработка частичных сбоев. В госсекторе, где требования к целостности учётных данных жёсткие, мы сознательно оставили часть модулей на общей СУБД. Это не «неправильно» – это трезвый расчёт.

Третье – инфраструктура и люди. Микросервисы требуют зрелого CI/CD, мониторинга и инженеров, которые понимают сеть, а не только код. Без этой базы разбиение монолита просто меняет одну большую проблему на пятнадцать маленьких, но связанных.

Как мы теперь подходим к выбору

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

Поэтому архитектуру корпоративной системы мы подбираем под задачу, а не под моду: для одних заказчиков это распределённый ландшафт с десятками сервисов, для других – аккуратный монолит, который проживёт ещё пять лет без переусложнения.

Вывод

Год практики подтвердил простое: микросервисы – инструмент под конкретные ограничения, а не цель. Они окупаются при разной динамике модулей, высокой нагрузке и зрелой инженерной культуре. Везде остальное честный монолит дешевле в разработке и эксплуатации. Решает не модный термин, а структура вашей задачи.