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

Микросервисная архитектура собирает приложение как набор таких служб, а не как один большой исполняемый файл. Каждая служба имеет собственный цикл релизов, часто собственное хранилище данных и команду, которая её создаёт и эксплуатирует. Связь между ними намеренно «тонкая»: контракт API, очередь сообщений, событие — и никакого общего объекта в памяти.

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

Как микросервис работает изнутри

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

Типичный жизненный цикл выглядит так. Клиент обращается к шлюзу API. Шлюз аутентифицирует запрос, маршрутизирует его к нужной службе, иногда агрегирует ответы нескольких сервисов. Служба обрабатывает команду, записывает данные в собственную базу и при необходимости публикует событие в брокер — Kafka, RabbitMQ или другой. Другие сервисы реагируют на событие уже в своём темпе. Транзакции между базами заменяют саги: цепочка локальных шагов с компенсирующими действиями, если какой-то шаг не удался.

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

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

Вокруг этого ядра нарастает инфраструктура, без которой распределённая система быстро становится хаосом. Service discovery находит живые экземпляры. Балансировщик распределяет нагрузку. Выключатель (circuit breaker) прекращает слать запросы к службе, которая уже не отвечает, чтобы каскад отказов не обрушил всё. Трассировка, метрики и структурированные логи собирают картину запроса, который прошёл через пять процессов. Без этой наблюдаемости отладка превращается в гадание.

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

От мастерской под Венецией до облачных кластеров

Само слово закрепилось не в маркетинговом отделе облачного гиганта, а на встрече архитекторов близ Венеции в мае 2011 года. В мае 2012-го та же группа выбрала название «microservices». Джеймс Льюис тогда уже показывал «микросервисы — Java на Unix-путях», Фред Джордж говорил о мелких службах с минимумом церемоний, а Адриан Коккрофт в Netflix описывал подход как мелкозернистую SOA. Каноническая формулировка появилась в статье Льюиса и Мартина Фаулера на martinfowler.com в марте 2014-го: одно приложение как набор малых служб, каждая в собственном процессе, с общением через лёгкие протоколы и почти без централизованного дирижёра.

Корни глубже названия. Философия Unix — «делай одну вещь и делай её хорошо» — прямо читается в идее узкой службы. Закон Конвея 1968 года объясняет организационную сторону: система копирует структуру коммуникаций компании. Amazon превратил это в практику «two-pizza teams» и принцип «you build it, you run it»: команда, которую можно накормить двумя пиццами, владеет сервисом от кода до ночного дежурства. Netflix пошёл дальше в инженерию отказов: Chaos Monkey намеренно убивал инстансы в проде, библиотека Hystrix изолировала каскадные падения. Сотни служб, миллиарды вызовов API в сутки — не рекламный слоган, а следствие того, что монолит эпохи DVD физически не выдерживал темпа изменений.

К 2026 году микросервисы перестали быть модной ставкой «на вырост» и стали одной из нескольких рабочих норм. По отчёту Cloud Native Computing Foundation совместно со SlashData (State of Cloud Native Development, ноябрь 2025) микросервисный подход используют 46% бэкенд-разработчиков, шлюзы API — 50%. Облачно-нативных разработчиков в мире насчитывают около 15,6 млн. В то же время рынок остыл от лозунга «всё в микросервисы». Модульный монолит, event-driven связка и выборочное вынесение «горячих» контуров чаще выигрывают у команд до нескольких десятков инженеров, чем полное разрезание системы на старте.

Монолит, SOA и микросервис: что на самом деле отличается

Спор «монолит против микросервисов» часто подменяет более точный вопрос: где проходит граница развёртывания. Монолит — одна сборка, один процесс, одна база. Модульный монолит сохраняет эту границу, но жёстко режет код на модули с чёткими API внутри процесса. SOA исторически строила корпоративную шину с тяжёлыми контрактами и центральным оркестратором. Микросервис мельче, автономнее и намеренно избегает «умной трубы» вроде ESB: логика сидит в конечных точках, канал лишь доставляет сообщения.

Источники сравнительных критериев: статья James Lewis и Martin Fowler на martinfowler.com (2014); отчёт CNCF / SlashData State of Cloud Native Development, ноябрь 2025.

SOA иногда путают с микросервисами из-за общего слова «сервис». Разница практическая. Классическая SOA ориентирована на интеграцию многих корпоративных систем через тяжёлые протоколы и центральную шину. Микросервисная архитектура строит один продукт как набор мелких единиц развёртывания. Там, где SOA ставила оркестратор, микросервисы чаще выбирают хореографию: службы танцуют по событиям, а не ждут команды дирижёра.

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

Распространённые ошибки, которые превращают сервисы в распределённый монолит

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

• Резать по слоям, а не по бизнесу. Отдельный «сервис базы», отдельный «сервис UI», отдельный «сервис бизнес-логики» воспроизводят трёхслойную схему монолита в сети. Граница должна проходить по способности: «каталог», «корзина», «оплата», «доставка». Иначе любая фича затрагивает три репозитория и три пайплайна.
• Оставить одну общую базу «на время перехода». Временное часто становится постоянным. Как только два сервиса пишут в те же таблицы, независимое развёртывание исчезает: миграция схемы блокирует всех. Лучше дублировать нужные данные через события, чем делиться строками.
• Сделать микросервис на каждый эндпоинт. /products и /products/{id}/related как две службы — это не архитектура, а осколки. Служба должна закрывать сценарий пользователя, а не строку в спецификации OpenAPI.
• Синхронная цепочка без бюджета задержки. Если оформление заказа ждёт каталог, скидки, склад, антифрод и оплату последовательно, p99 латентность складывается, а падение любого звена останавливает checkout. Часть шагов выносят в события, часть — за выключатель с деградированным ответом.
• Распределённые транзакции «как в монолите». Двухфазный коммит между службами хрупок и медленен. Сага, идемпотентные обработчики и явные компенсации («отменить резерв», «вернуть средства») сложнее концептуально, но соответствуют природе сети.
• Игнорировать организацию. Пять сервисов на двух разработчиков означают, что ночи уйдут на пайплайны, а не на продукт. Микросервис окупается, когда команда может нести его полный цикл. Иначе модульный монолит дешевле и честнее.

Отдельный миф: «микросервисы сами по себе быстрее». Сетевой вызов всегда медленнее вызова функции. Выигрыш появляется в другом месте — в параллельной работе команд, в точечном масштабировании «горячего» сервиса, в возможности откатить одну службу, не затрагивая остальное. Если проблема сейчас в медленном SQL-запросе, разрезание её не вылечит.

Кейс: интернет-магазин, в котором «корзина» жила отдельно от «оплаты»

В нашей практике мы сталкивались с таким случаем, когда команда из девяти человек разрезала монолит интернет-магазина на 22 службы ещё до первой тысячи заказов в день. Каталог, корзина, промокоды, склад, доставка, оплата, письма, «рекомендации», админка — каждое из этих слов стало отдельным репозиторием. Релиз фичи «бесплатная доставка от 1500 грн» занял три недели согласований контрактов. Локально магазин уже не запускался: нужен был docker-compose на 22 контейнера и тестовые ключи платёжки.

Мы провели тест на 100 пользователях и обнаружили, что оформление заказа, которое в монолите укладывалось в 180–220 мс на p95, после разрезания прыгнуло свыше 900 мс. Не из-за «плохого кода», а из-за четырёх последовательных HTTP-вызовов на критическом пути, каждый из которых открывал TLS и ходил в свою базу. Склад отвечал 99,2% времени — и этого хватало, чтобы раз в несколько минут срывать checkout.

Откатили границы, а не «идею микросервисов». Оставили три контура: каталог (чтение, тяжёлое кэширование), checkout (корзина + промокод + создание заказа в одной службе) и платежи (отдельная служба с требованиями PCI и собственным циклом релизов). Рекомендации вернули модулем в каталог. Письма ушли в очередь, а не в синхронный вызов. Через шесть недель p95 вернулся к 250–300 мс, а фичи снова выходили еженедельно. Платёжный сервис действительно выиграл от изоляции: его можно было обновлять в пятницу вечером, не затрагивая витрину.

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

Чек-лист: стоит ли дробить систему именно сейчас

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

1. Есть как минимум две команды, которые регулярно блокируют друг друга общим релизом.
2. Пиковая нагрузка неравномерна: масштабировать нужно одну способность (поиск, стрим, оплату), а не всё приложение.
3. Отказ части функций допустим для бизнеса: витрина может жить без рекомендаций, но не без корзины.
4. Ограниченные контексты уже видны в коде и в разговорах домена, а не только на слайде.
5. Есть автоматизированный пайплайн, контейнеризация, централизованные логи, метрики и алерты. Без этого новый сервис — это новый ночной звонок.
6. Команда готова владеть эксплуатацией: онколл, дашборды, бюджет ошибок, политику повторов.
7. Есть понятная стратегия данных: кто источник истины, как расходятся копии, что делать с компенсациями.
8. Сетевой бюджет на критический сценарий посчитан. Если на пути пользователя больше двух-трёх синхронных хопов — граница проведена плохо.
9. Безопасность продумана на границе: аутентификация на шлюзе, авторизация в службе, секреты не в образах, трафик между сервисами не «открытый, потому что внутри VPC».
10. Есть план отката одной службы и план наблюдения за сагой, а не только за HTTP 200 на шлюзе.

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

Когда система уже «сыпается»: тревожные сигналы

По моему опыту сопровождения микросервисного контура в течение месяца после разрезания монолита первые симптомы редко выглядят как «сервис упал». Чаще продукт «просто тормозит», а дашборд зелёного цвета, потому что каждая служба отдельно жива.

Первый сигнал — рост p95/p99 без роста CPU. Это почти всегда очереди в сети, ретраи, холодные соединения или синхронная цепочка. Смотрите трейс одного пользовательского сценария, а не среднее по кластеру. Второй — расхождение данных: заказ есть, оплаты нет, или наоборот. Ищите обрыв саги, неидемпотентный обработчик, который отработал дважды, и отсутствие outbox-паттерна (запись в базу и публикация события в одной локальной транзакции).

Третий сигнал — «релиз одной службы ломает другую». Контракт изменили без версии, поле убрали, потребитель не толерантен к лишним атрибутам. Здесь спасают consumer-driven contracts и правило читателя, который игнорирует неизвестное. Четвёртый — взрыв стоимости инфраструктуры: десятки малых инстансов простаивают, но каждый держит собственный кластер базы, собственный пул соединений и собственный дашборд. Точечное объединение «холодных» служб обратно в модуль — нормальное инженерное действие, а не поражение.

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

Каскадные отказы лечатся не «ещё одним репликами». Выключатель, таймаут короче терпения пользователя, кэш на чтениях, очередь на записях, деградированный режим («показать наличие из кэша, если склад не отвечает») — это и есть проектирование с расчётом на отказ, о котором писали авторы классического определения ещё в 2014-м.

Когда стоит звать архитектора, а когда хватит команды

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

Архитектора или платформенную команду стоит звать, когда появляется хотя бы одно из условий: несколько продуктовых команд на общей системе; требования изоляции (PCI, персональные данные, отдельный контур отказа); потребность в полиглоте (Python для ML-скоринга рядом с JVM-ядром); или уже есть распределённые гонки, которые не лечатся индексом в Postgres. Специалист здесь нужен не чтобы «нарисовать сервисы», а чтобы провести bounded context, бюджет задержки, модель данных и минимальный набор платформенных сервисов: шлюз, идентичность, телеметрия, CI/CD, секреты.

Отдельный случай — регулируемые отрасли и публичный сектор в Украине, где контуры персональных данных, резервного копирования и аудита жёстче желания «микросервисить всё». Там чаще выигрывает гибрид: ядро из модулей плюс несколько изолированных служб на периметре. Это не отсталость, а соответствие стоимости риска.

Вопросы, которые появляются после первого релиза

Чем микросервис отличается от «просто API»?

API — это способ разговора. Микросервис — способ жизни компонента: собственный процесс, собственное развёртывание, собственные данные, собственная ответственность за отказ. Монолит тоже может отдавать REST. Пока служба не может выйти в прод отдельно от соседей, это модуль с HTTP-фасадом, а не микросервис.

Сколько служб — это уже слишком много?

Нет магического числа. Ориентир практический: команда из 6–8 человек комфортно несёт две-четыре службы, не двадцать. Если количество сервисов растёт быстрее количества команд, вы режете технические слои или эндпоинты, а не домен. Объединение «тихих» служб обратно — законная эволюция, её всё чаще фиксируют в отраслевых обзорах середины 2020-х.

Обязателен ли Kubernetes?

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

Как вынести первый сервис из монолита, не останавливая продукт?

Работает стратегия «лианы» (strangler fig): новый контур пишется рядом, шлюз постепенно переводит на него часть трафика, старый код отмирает. Начинают со способности, у которой есть собственные данные и собственный ритм изменений — часто это уведомления, поиск, генерация файлов, иногда оплата. Антикоррупционный слой на границе со старым ядром бережёт новый сервис от чужой модели данных.

Можно ли писать службы разными языками?

Да, и это одно из обещаний стиля. Делайте это там, где язык даёт реальный выигрыш: Go для нагруженного прокси, Python для офлайн-скоринга, JVM для сложной доменной логики. Каждый новый язык — это ещё один способ собирать, логировать, профилировать и нанимать людей. Полиглот без нужды дороже «скучной» одинаковости.

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

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