Вывод монолита в микросервисную архитектуру
Контекст
Задача
Релизы раз в квартал, отказы под пиковой нагрузкой, невозможность параллельной работы команд.
Работа
Решение
Архитектурный аудит и нагрузочное тестирование, декомпозиция по бизнес-доменам, поэтапный вынос сервисов, внедрение CI/CD и мониторинга.
Проблема бизнеса
Что происходило до проекта
Логистическая платформа выросла из небольшой системы в монолит, который перестал выдерживать собственный успех: релизы выходили раз в квартал, потому что любое изменение требовало полной регрессии всей системы; сезонные пики нагрузки роняли самые критичные функции вместе с второстепенными; три команды разработки стояли в очереди к одной кодовой базе.
Классическая дилемма: переписать с нуля — годы без новой функциональности и огромный риск; оставить как есть — деградация ускоряется. Нужен был третий путь.
Сдвиг
Как было — как стало
Как было
Как стало
Ход работы
Как решали
Архитектурный аудит и нагрузочное тестирование
Определили реальные границы доменов и узкие места под нагрузкой — вынос начали с доменов, которые давали максимум боли.
Декомпозиция по бизнес-доменам
Заказы, маршрутизация, биллинг — каждый домен стал отдельным сервисом со своей командой, базой и циклом релизов.
Шина событий
Сервисы общаются через Kafka: монолит и новые сервисы работали параллельно, обмениваясь событиями, пока трафик переводился постепенно.
CI/CD и мониторинг
Каждый сервис получил свой пайплайн и метрики: деплой перестал быть событием и стал рутиной.
Поэтапный вынос без остановки
Домены выносились по одному, с откатом на монолит при проблемах — платформа работала непрерывно весь проект.
Решение
Как устроено архитектурно
Kafka соединяет домены
Сервисы публикуют и читают события друг друга; монолит участвует в том же обмене, пока отдаёт домены.
Платформенный слой отделён
CI/CD деплоит сервисы, метрики и логи стекаются в наблюдаемость — эти потоки не пересекаются с бизнес-событиями.
Свои БД у сервисов
Каждый домен владеет данными: связность через события, а не через общую базу.
Продукт
Как это выглядит в работе
Продакшн-борд после декомпозиции: сервисы деплоятся независимо, монолит дожимается планово. Релиз перестал быть событием, ради которого собиралась вся инженерия.
Макет иллюстрирует механику интерфейса; данные на экране условные.
Границы решения
Что делает — и чего не делает
Честные рамки — часть архитектуры: они защищают результат не хуже кода.
Делает
- границы сервисов по бизнес-доменам, не по слоям
- шина событий как мост на переходный период
- свой CI/CD и мониторинг у каждого сервиса
- канареечные деплои и быстрый откат
- нагрузочные профили сезонных пиков
Не делает
- «микросервисов ради микросервисов» — домены укрупнены осознанно
- остановки платформы: вынос шёл под боевым трафиком
- распределённого монолита: сервисы общаются событиями, не синхронными вызовами
Итог
Результат
- Релизы выходят чаще
- Отказоустойчивость под пиком
- Параллельная работа нескольких команд
Числовые показатели публикуются после сверки с заказчиком.
Передача
Что осталось у клиента
- Исходный код, модели и конфигурации — вместе с правами.
- Документация и описание архитектуры.
- Возможность развивать решение своей командой или любым другим подрядчиком.
Следующий шаг
Расскажите про задачу
Разберём, оценим сроки и стоимость. Если задача не наша — скажем прямо и подскажем, к кому обратиться.
Обсудить задачу →