Микросервисы давно стали символом «правильной архитектуры». Про них пишут в блогах, рассказывают на конференциях, упоминают в вакансиях CTO как «обязательный пункт». И часто предлагают как универсальное решение почти для любого проекта — от MVP стартапа до корпоративной модернизации.
На практике микросервисная архитектура — одна из самых часто переоценённых технологий в современной разработке. Она может быть мощным инструментом масштабирования и развития, а может — источником постоянных проблем, перерасхода бюджета и технического долга, который никто не хочет разбирать.
Ключевая ошибка большинства проектов — отвечать на вопрос «нужны ли нам микросервисы?» до того, как понятно, какую задачу вообще решает система, какая команда её строит и куда она движется. Микросервисы — это не цель и не маркер качества. Это инструмент с конкретной зоной применения и конкретной ценой.
В этой статье — честный разбор: когда микросервисы действительно оправданы, когда они начинают вредить бизнесу, что такое модульный монолит как недооценённая альтернатива, и как выглядит зрелый путь от одной архитектуры к другой.
Контекст: High-load системы в России: как готовиться к нагрузке до того, как она случилась — подготовка к нагрузке; Enterprise-архитектура для стартапов: что действительно нужно, а что — лишнее — что действительно нужно из enterprise-подхода.
01 · Почему микросервисы так притягательны
Идея микросервисов звучит очень убедительно. На уровне презентаций она выглядит почти идеальной:
- Каждый сервис отвечает за свою зону. Один сервис — один домен, чёткие границы, понятная ответственность.
- Можно масштабировать части системы отдельно. Платежи нагружены — увеличиваем количество инстансов платежного сервиса. Поиск — наоборот.
- Команды работают независимо. Каждая отвечает за свой набор сервисов, не пересекается с другими.
- Изменения не ломают всё сразу. Обновили один сервис — остальные продолжают работать.
- Разные технологии для разных задач. Один сервис на Java, другой на Go, третий на Python — каждый под свою задачу.
- Независимый деплой. Релиз одного сервиса не требует пересборки всей системы.
Всё это правда — при определённых условиях. И эти условия — не «у нас в проекте есть код». Это конкретный набор требований к команде, процессам, продукту и бизнесу.
Проблема в том, что эти условия есть далеко не у всех проектов. По нашему опыту — у меньшинства проектов, которые в итоге выбирают микросервисную архитектуру. И отсутствие этих условий превращает преимущества микросервисов в недостатки.
02 · Главный миф: микросервисы = масштабируемость
Самое распространённое заблуждение: «нам нужны микросервисы, потому что мы планируем масштабироваться».
Микросервисы сами по себе не делают систему масштабируемой. Масштабируемость определяется совсем другими вещами:
- Архитектурой данных. Партиционирование, read-реплики, шардинг, кэширование. Это можно делать как в монолите, так и в микросервисах.
- Изоляцией ответственности. Чёткие домены, не пересекающиеся ответственности. Это можно делать как модули в монолите, так и как сервисы.
- Асинхронностью. Очереди, фоновые задачи, событийная архитектура. Не зависит от микросервисов — работает в любой архитектуре.
- Наблюдаемостью. Логи, метрики, трейсы. В микросервисах их больше нужно, не меньше.
- Зрелостью процессов. CI/CD, нагрузочное тестирование, capacity planning, runbook на инциденты. Всё это нужно независимо от архитектурного стиля.
Если этого нет, микросервисы:
- Не спасают от нагрузки. Каждый микросервис всё ещё упирается в свою БД, в свои внешние зависимости, в свои узкие места.
- Не упрощают развитие. Изменения, затрагивающие несколько доменов, теперь требуют координации между сервисами и согласования контрактов.
- Не ускоряют команду. Команда тратит больше времени на инфраструктуру и меньше на бизнес-логику.
- Не дают независимости. Любое нетривиальное изменение трогает несколько сервисов одновременно.
Они просто добавляют операционную сложность, не решая исходных проблем масштабируемости. Это самый дорогой урок, который проходят команды, выбравшие микросервисы преждевременно.
03 · Что микросервисы реально добавляют в систему
Важно честно назвать цену. Микросервисная архитектура — это не «бесплатный апгрейд». Она означает целый класс новых задач, которых нет в монолитной архитектуре.
Сетевые вызовы вместо локальных. То, что в монолите было вызовом функции (1 мс), в микросервисах становится HTTP-запросом (10–100 мс) с возможностью сетевого сбоя.
Распределённые транзакции. Когда операция должна одновременно произойти в двух сервисах — это становится отдельной инженерной задачей. Saga-паттерн, event sourcing, two-phase commit — все требуют специфической экспертизы и тщательной реализации.
Service discovery. Сервисы должны находить друг друга. Простой DNS не всегда работает — нужны Consul, etcd, Kubernetes-нативные механизмы.
Централизованная аутентификация. Каждый сервис должен проверять токены и роли. Нужен auth-сервис, нужна синхронизация политик доступа.
Централизованное логирование. Логи раскиданы по 10–30 сервисам. Без агрегации в одном месте отладка превращается в кошмар.
Distributed tracing. Один пользовательский запрос проходит через 5 сервисов. Без OpenTelemetry или аналога невозможно понять, где он застрял.
Мониторинг десятков компонентов. Раньше — один сервис, один дашборд. Теперь — 30 дашбордов, и нужны agregating-уровни.
Сложный CI/CD. Раньше — один pipeline на весь продукт. Теперь — 30 pipeline-ов с зависимостями между ними, версионированием контрактов, координацией релизов.
Управление инфраструктурой. Kubernetes, helm charts, operators, service mesh — это все становится «обязательной программой».
Координация деплоев. Несовместимые изменения в API двух сервисов — это ситуация, в которой нужно либо deploy в правильном порядке, либо backward compatibility в течение нескольких релизов.
Тестирование интеграций. Unit-тесты не покрывают взаимодействие сервисов. Нужны contract tests, end-to-end tests, chaos engineering.
Это всё — операционная сложность, не код. И эта сложность требует:
- Отдельной DevOps/SRE команды (или 1–2 выделенных людей в маленькой компании).
- Инвестиций в инфраструктуру (платформенная команда, инструменты).
- Зрелости разработчиков (нельзя нанять «обычного backend-разработчика» и поставить его на микросервисы — нужны люди с опытом распределённых систем).
Если команда и бизнес к этому не готовы — система начинает деградировать. Микросервисы превращаются в «распределённый монолит»: те же зависимости, что в монолите, но с сетевыми вызовами вместо функций. Это худший из возможных миров.
04 · Когда микросервисы действительно нужны: 4 условия
Микросервисная архитектура оправдана, если совпадают несколько факторов одновременно, не один из них. Один-два — этого недостаточно для перехода.
Условие 1: система уже выросла за пределы модульного монолита.
Это не «мы планируем вырасти», а «у нас уже есть проблемы из-за размера». Конкретные признаки:
- Кодовая база больше 100k строк, работа над ней замедлена из-за объёма.
- Изменения в одном модуле регулярно ломают другой, потому что границы размылись.
- Релизы стали редкими (раз в 2 недели или реже), потому что каждый требует регрессионного тестирования.
- Разные части системы живут в разном ритме: одна меняется ежедневно, другая — раз в полгода.
- CI становится узким местом — сборка и тесты занимают часы.
Если этого нет — модульный монолит ещё работает, и переход к микросервисам преждевременен.
Условие 2: есть независимые домены с разной нагрузкой и SLA.
Микросервисы хорошо работают, когда:
- Есть чёткие доменные границы (выкристаллизовались, не «должны бы быть»).
- Разные части системы нагружаются по-разному (поиск в 10× больше операций, чем платежи).
- Их действительно нужно масштабировать отдельно (поиск — горизонтально, платежи — с жёсткой консистентностью).
- Есть разные требования к доступности (один компонент — 99.95%, другой — 99%).
- Есть разные требования к технологиям (для поиска нужен Elasticsearch, для платежей — реляционная БД).
Если всё крутится вокруг одной сущности (например, заказа) и одной базы — микросервисы не дают выгоды. Они просто разнесут логику по сети, не упростив её.
Условие 3: есть зрелые команды и процессы.
Микросервисы требуют:
- Дисциплины. Контракты соблюдаются, обратная совместимость поддерживается, тесты пишутся.
- Ответственности команд. Каждая команда отвечает за свои сервисы 24/7, включая on-call.
- Автоматизации. CI/CD, observability, infrastructure-as-code — всё под автоматизацией.
- Культуры DevOps. Команды разработки участвуют в эксплуатации, не «бросают через стену».
Без этого:
- Сервисы начинают дублировать логику (потому что «у нас в команде так удобнее»).
- Контракты нарушаются (потому что «срочно надо в прод»).
- Поддержка становится хаотичной (потому что неясно, кто за что отвечает).
Условие 4: есть реальные требования к независимому масштабированию.
Не «может пригодится», а конкретные сценарии:
- High-load финтех с разными требованиями к компонентам.
- Маркетплейсы, где поиск и заказы — это разные классы задач.
- SaaS с разными SLA для разных тарифов и компонентов.
- Сложные интеграционные платформы с разными внешними системами.
- Multi-tenant продукты с разными требованиями к изоляции.
- Платформы, в которых разные клиенты используют разные функции.
Здесь микросервисы часто оправданы — но даже здесь это не автоматически. Нужны 1, 2 и 3 условия в дополнение.
Если все 4 условия выполняются — переход к микросервисам оправдан. Если выполняются 2–3 — стоит подумать о частичном выделении проблемных доменов. Если 0–1 — модульный монолит лучше.
05 · Когда микросервисы чаще всего вредят
Теперь самое важное. Несколько типовых сценариев, в которых микросервисы выбраны неправильно и приводят к проблемам.
Сценарий 1: на старте продукта или MVP.
Для MVP микросервисы почти всегда:
- Замедляют запуск. Вместо «написать backend» команда тратит первые недели на настройку Kubernetes, service mesh, observability stack.
- Усложняют отладку. Что-то не работает — нужно открыть 5 дашбордов, найти трейс, понять, где именно.
- Увеличивают бюджет. Инфраструктурные расходы в облаке выше из-за дублирования базовых компонентов в каждом сервисе.
- Отвлекают от продукта. Команда занимается инфраструктурой, не бизнес-логикой.
- Требуют команды, которой нет. На старте обычно нет DevOps/SRE — приходится нанимать или платить подрядчику.
MVP выигрывает от:
- Простоты — один deployment, один сервис, один лог.
- Скорости — изменения деплоятся за минуты.
- Прозрачности — вся система понятна одному человеку.
Модульный монолит почти всегда лучше для MVP. Микросервисы добавляют 30–50% времени разработки и 100–200% операционной сложности, не давая эквивалентной отдачи.
Читайте о корпоративном MVP: Корпоративный MVP в 2026 году: почему «быстро и дёшево» больше не работает.
Сценарий 2: при отсутствии чётких границ ответственности.
Если в системе:
- Домены размыты — непонятно, где кончается один и начинается другой.
- Бизнес-логика не определена — правила меняются каждые две недели.
- Данные «общие для всех» — несколько систем работают с одной сущностью одновременно.
- Нет владельцев на уровне продукта — каждый делает то, что считает нужным.
микросервисы лишь закрепляют хаос. Вместо системы получается сеть взаимозависимостей, которую сложно понять и изменить. Каждое изменение требует координации нескольких команд, каждый инцидент — это «у вас или у нас?».
В таких случаях нужно сначала навести порядок в доменах и бизнес-логике, и только потом — если останется необходимость — переходить к микросервисам.
Сценарий 3: когда их выбирают «потому что так модно».
Самый опасный и самый частый сценарий:
«Все делают микросервисы — и нам надо». «У нас CTO в новой компании сказал, что монолиты — это устарело». «На конференции рассказывали про микросервисы, давайте сделаем».
В таких проектах:
- Нет реальной необходимости — нагрузка такая, что монолит легко справился бы.
- Нет зрелых процессов — CI/CD на коленке, observability отсутствует.
- Нет понимания, зачем это сделано — команда выполняет «директиву сверху».
Результат почти всегда — возврат назад через 12–18 месяцев или дорогое упрощение. И возврат тоже не быстрый — рассыпать монолит на сервисы можно за квартал, а собрать обратно — это полугодовой проект.
Сценарий 4: для команды младше 10 инженеров.
Микросервисы требуют разделения по командам. Если у вас 5 инженеров, и они должны поддерживать 10 сервисов — это не «независимые команды», это «5 человек жонглируют 10 системами». Накладные расходы доминируют над пользой.
Эмпирическое правило: на каждый микросервис нужно минимум 2 инженера. Команда из 5 человек может вытянуть 2–3 сервиса. Команда из 10 — 4–5 сервисов. Команда из 20 — 8–10. На команде менее 10 — модульный монолит почти всегда лучше.
06 · Модульный монолит: недооценённая альтернатива
Модульный монолит — это архитектура, в которой система живёт в одном развёртываемом артефакте, но внутри чётко разделена на модули с явными границами. Это не «всё свалено в одну кучу», это структурированное решение.
Что входит в модульный монолит:
- Чёткие домены. Auth, Billing, Core, Analytics, Notifications — каждый со своими моделями, сервисами, репозиториями.
- Явные границы. Один модуль не лезет в таблицы другого. Взаимодействие — через явные интерфейсы.
- Слабая связность (loose coupling). Изменение внутренностей одного модуля не требует изменений в других.
- Сильная сплочённость (high cohesion). Всё, что относится к одному домену, лежит в одном модуле.
- Единый CI/CD. Один pipeline, одна сборка, один деплой.
- Единая БД (опционально с отдельными схемами на модуль).
- Простой деплой. Один артефакт, одно развёртывание, одна точка наблюдаемости.
Преимущества:
- Проще в разработке. Новый член команды разбирается за дни, не недели.
- Дешевле в поддержке. Одна инфраструктура, один pipeline, один dashboard.
- Прозрачнее для команды. Все понимают всю систему.
- Легче в отладке. Один лог, один трейс, локальный запуск всей системы.
- Быстрее в разработке. Изменения деплоятся за минуты, не часы.
- Меньше операционных расходов. Меньше инстансов, меньше прокси, меньше сетевого трафика.
При правильной архитектуре модульного монолита:
- Модули изолированы и могут разрабатываться разными командами.
- Зависимости контролируемы — есть граф зависимостей между модулями.
- Переход к микросервисам возможен без переписывания — модуль выносится как отдельный сервис механически.
Это не «устаревший подход» и не «архитектура для бедных». Это осознанный выбор, который выбирают крупные продуктовые команды (Shopify, Basecamp, GitHub) даже после многократного роста.
Подробнее: Enterprise-архитектура для стартапов: что действительно нужно, а что — лишнее.
07 · Зрелый путь: не «или», а «когда»
В реальных успешных проектах путь к микросервисам редко выглядит как «решили на старте — сделали с самого начала». Обычно это эволюционный процесс:
Фаза 1: модульный монолит (0–18 месяцев).
- Один сервис, чёткие модули, явные границы.
- Команда 3–10 человек.
- Фокус на продукте и бизнес-логике.
- Инфраструктура — простая, понятная одному человеку.
Фаза 2: рост нагрузки и сложности (18–30 месяцев).
- Команда выросла до 10–20 человек.
- Появились конкретные узкие места.
- Релизы стали медленнее из-за объёма кода.
- Один-два модуля явно живут в другом ритме.
Фаза 3: выделение узких мест (30–48 месяцев).
- Выделяются конкретные сервисы под конкретные проблемы (поиск, обработка платежей, аналитика).
- Не «давайте всё разнесём», а «вот этот компонент нужно отделить».
- Остальная система остаётся монолитом.
Фаза 4: гибридная архитектура (48+ месяцев).
- Монолит + 3–10 выделенных сервисов.
- Каждый выделенный сервис имеет конкретную причину существования.
- Команды стали зрелыми, есть DevOps-практики.
Фаза 5: полные микросервисы (опционально).
- Только если команда выросла до 50+ инженеров и есть устойчивая потребность.
- Никогда не «потому что это конечная цель».
Так микросервисы:
- Решают реальные проблемы — каждый выделенный сервис существует с причиной.
- Не создают новых — потому что выделяются по мере зрелости.
- Появляются тогда, когда они действительно нужны — а не «на всякий случай».
Это занимает 2–4 года для типового SaaS-продукта. Это много, но это реальное время жизненного цикла продукта, не «давайте сделаем правильно сразу».
08 · Самая частая ошибка бизнеса
Ошибка звучит так: «Архитектура должна быть сразу на вырост». И эта фраза, повторяемая на собеседованиях и в обсуждениях, привела к огромному количеству перерасходов.
На практике «на вырост» означает совсем другое:
- Заложить границы. Чёткие домены, явные интерфейсы, разделение ответственности.
- Не блокировать развитие. Не принять решений, из которых дорого выходить.
- Не загонять систему в тупик. Оставить пространство для роста, не активируя его сразу.
Это не означает усложнять всё заранее:
- Не означает делать 20 микросервисов на старте.
- Не означает развёртывать Kubernetes для команды из 3 человек.
- Не означает копировать архитектуру Netflix для продукта с 100 пользователями.
- Не означает «строить как в банке», когда у вас стартап.
«На вырост» в зрелой практике — это:
- Модульный монолит с чёткими границами.
- API-first подход.
- Готовность БД к партиционированию и read-репликам.
- CI/CD с первого дня.
- Наблюдаемость на базовом уровне.
- Документированная архитектура.
- Возможность выделить модуль в сервис в будущем без переписывания.
Это «на вырост». Это возможности, заложенные в архитектуру, не их преждевременная активация.
09 · Конкретные признаки, что пора выделять сервис
Иногда переход к микросервисам действительно нужен. Как понять, что момент настал?
Признак 1: конкретный модуль становится узким местом по нагрузке.
Например, поиск генерирует 60% БД-запросов и тормозит остальные операции. Если выделить его в отдельный сервис со своим хранилищем (Elasticsearch), он перестанет влиять на основную систему.
Признак 2: разные требования к технологиям.
Например, основной backend на Java, но появилась задача с ML-моделями, для которых удобнее Python. Выделение ML-сервиса оправдано.
Признак 3: разные SLA.
Например, основной продукт имеет SLA 99.5%, но платежи требуют 99.95%. Выделение платежного сервиса с отдельной инфраструктурой оправдано.
Признак 4: разные команды с независимым релизным циклом.
Например, есть команда платежей, которая хочет деплоить раз в день, и команда основного продукта, которая релизит раз в две недели. Выделение оправдано.
Признак 5: разные требования к compliance.
Например, платежный модуль требует особого режима compliance (PCI DSS, например), а остальная часть — нет. Выделение помогает изолировать compliance-зону.
Признак 6: масштабирование команды.
Команда выросла за пределы того, что может работать в одном монолите без конфликтов. Это обычно 30–50 инженеров.
Если есть один из этих признаков — стоит подумать о выделении конкретного компонента. Если ни одного — модульный монолит ещё работает.
10 · Как реализуется правильное выделение сервиса
Допустим, есть признак — например, поиск стал узким местом. Как правильно выделить его в сервис?
Шаг 1: формализация границы. Описать, какие операции остаются в core, какие уходят в новый сервис. Какой контракт между ними.
Шаг 2: выделение модуля в монолите. Сделать модуль поиска явно изолированным внутри монолита. Все обращения к нему — только через явный API.
Шаг 3: тестирование границы. Убедиться, что в монолите модуль работает через API. Никто не лезет внутрь напрямую.
Шаг 4: вынос инфраструктуры. Поднять Elasticsearch (или что выбрано для нового сервиса). Настроить наблюдаемость.
Шаг 5: вынос сервиса. Физически выделить модуль в отдельный сервис. Запустить параллельно с монолитом, обращающимся к нему по сети.
Шаг 6: миграция данных. Перенести данные поиска в новое хранилище. Backfill, проверка консистентности.
Шаг 7: переключение трафика. Постепенно перевести запросы на новый сервис. Сначала 10%, потом 50%, потом 100%.
Шаг 8: удаление старого кода. Только после успешного переключения.
Этот путь занимает 2–4 месяца на один сервис. Это долго — и именно поэтому выделение должно быть оправдано конкретной проблемой, не «давайте на всякий случай».
11 · Закон Конвея: команды формируют архитектуру
Один из самых недооценённых факторов выбора архитектуры — это закон Конвея: «Организации проектируют системы, которые копируют структуру коммуникаций самой организации».
Что это значит на практике:
- Если у вас одна команда — у вас будет монолит, даже если попытаетесь сделать микросервисы. Команда коммуницирует синхронно, делает совместные решения, всегда «договаривается». Это монолит, физически разнесённый по сервисам.
- Если у вас две команды — у вас получится монолит с одной точкой разрыва. Не микросервисы.
- Если у вас 5+ независимых команд — у вас получится 5+ сервисов, потому что каждая команда хочет автономии.
Поэтому архитектура должна следовать за структурой команды, не наоборот. Если вы хотите микросервисы — вам нужны команды, которые работают независимо. Если у вас одна команда — даже самые тщательные микросервисы превратятся в распределённый монолит.
Это объясняет, почему «правильные» микросервисы на одной команде из 5 человек — это утопия. Не из-за качества инженеров, а из-за структуры коммуникаций.
И обратное: модульный монолит на команде из 30 человек — это очень больно. Люди мешают друг другу в одной кодовой базе. В этот момент микросервисы становятся не «техническим выбором», а организационным.
12 · Чек-лист: 12 вопросов до перехода на микросервисы
Прежде чем выбирать микросервисную архитектуру, ответьте на эти 12 вопросов. Если на половину ответ «не знаем» — переход преждевременен.
- Сколько у нас инженеров сейчас и через 24 месяца?
- Какая структура команд? Есть ли реальные независимые команды?
- Какие конкретные модули сейчас являются узкими местами?
- Какие модули имеют разные требования к нагрузке и SLA?
- Есть ли DevOps/SRE-экспертиза или ресурсы её нанять?
- Какой у нас CI/CD сейчас? Готов ли он к нескольким сервисам?
- Какая наблюдаемость? Есть ли distributed tracing?
- Готовы ли мы инвестировать 6–12 месяцев в миграцию?
- Какова цена ошибки выбора?
- Что произойдёт, если мы останемся на монолите ещё 18 месяцев?
- Какие конкретные проблемы решит переход?
- Кто отвечает за архитектурное решение?
Команда с внятными ответами на эти вопросы обычно понимает, нужны ли ей микросервисы. Команда, которая отвечает «давайте попробуем» — обычно через 18 месяцев откатывается обратно или признаёт, что переход был ошибкой.
Источники и что читать дальше
- Enterprise-архитектура для стартапов: что действительно нужно, а что — лишнее — какие принципы enterprise работают для стартапа.
- Как запустить MVP, который выдержит рост ×10 — без переписывания архитектуры — рост ×10 без переписывания.
- High-load системы в России: как готовиться к нагрузке до того, как она случилась — подготовка к нагрузке.
- Корпоративный MVP в 2026 году: почему «быстро и дёшево» больше не работает — корпоративный MVP и модульный подход.
- CI/CD и DevOps для бизнеса: зачем это нужно, если «и так работает» — CI/CD как фундамент любой архитектуры.
- Почему системы без мониторинга и логирования обречены ломаться — наблюдаемость в распределённых системах.
- Java или Node.js для корпоративных систем в России: что выбирают в 2026 году — выбор стека.
- backend development — backend-фундамент.
- custom software — кастомная разработка с правильной архитектурой.
Микросервисная архитектура — не цель и не признак качества. Это инструмент, который работает в правильном контексте и вреден в неправильном. Эта статья даёт фреймворк для принятия решения. Если у вас конкретный вопрос — переходить ли на микросервисы, как это правильно сделать — мы делаем такие архитектурные оценки отдельно.