Кейс
Миграция монолита на микросервисы
Поэтапное выделение микросервисов из монолита без простоя: границы доменов, события и оркестрация в Kubernetes.
- Год
- 2026
- Клиент
- Зрелый SaaS-продукт
- Роль
- Tech Lead
Описание
Зрелый монолит на Laravel перестал отвечать требованиям бизнеса: релизы стали рискованными, команды мешали друг другу, а отдельные нагруженные модули невозможно было масштабировать независимо. Я возглавил поэтапную миграцию на микросервисы по стратегии «душитель» (strangler fig), без остановки продукта. Мы начали с выделения границ по доменам на основе DDD, затем последовательно извлекали сервисы, переводя межмодульное взаимодействие на асинхронные события через брокер сообщений и transactional outbox для надёжной публикации. Наиболее нагруженные по латентности сервисы реализованы на Go, продуктовые — остались на Laravel. Все сервисы контейнеризированы и развёрнуты в Kubernetes с независимыми пайплайнами CI/CD, автомасштабированием и полной наблюдаемостью: структурированные логи с корреляционными идентификаторами, метрики Prometheus и распределённая трассировка. Монолит при этом продолжал работать, постепенно «худея» по мере выноса функциональности.
Задача
Монолит стал узким местом: любой релиз затрагивал всю систему и нёс риск, команды конфликтовали в общем коде и базе, а нагруженные модули нельзя было масштабировать отдельно от остальных.
Решение
Применил стратегию strangler fig: выделил доменные границы, поэтапно извлекал сервисы с асинхронным обменом событиями и outbox, нагруженные части переписал на Go, развернул всё в Kubernetes с отдельными пайплайнами и сквозной наблюдаемостью.
Результаты
Частота релизов выросла в 4 раза, время восстановления после инцидентов сократилось втрое, нагруженные сервисы масштабируются независимо, миграция прошла без простоя продукта, время вывода новых фич сократилось на 40%.