Переход от монолита почти никогда не бывает героическим переписыванием. Сильные команды режут систему небольшими срезами и сохраняют право на откат.
Для реального проектирования глава помогает увидеть, как постепенный перехват сценариев, ветвление через абстракцию, поэтапное разделение базы и измеримые проверки превращают миграцию из разовой ставки в управляемую программу изменений.
Для интервью и инженерных разборов она полезна тем, что помогает обсуждать миграцию через риск двойной записи, пути отката и цену каждого шага, а не через красивую целевую картинку сервисов.
Практическая польза главы
Практика проектирования
Переносите сценарии по одному: сначала маршрутный слой, затем новый сервис, проверка и удаление старого кода.
Качество решений
Снижайте риск миграции через небольшие срезы, измеримые проверки и заранее продуманный откат.
Аргументация на интервью
Показывайте, почему переписывание одним рывком опасно и где старый и новый контур должны временно сосуществовать.
Анализ отказов
Планируйте откат, контроль двойной записи и поэтапное разделение базы данных.
Связанная книга
Building Microservices
Первая книга Newman объясняет, какую сервисную архитектуру строить; эта показывает, как безопасно прийти к ней из монолита.
Monolith to Microservices (От монолита к микросервисам)
Авторы: Sam Newman
Издательство: O'Reilly Media, 2019
Объём: 272 страниц
Разбор книги Sam Newman: пошаговая миграция из монолита, Strangler Fig, Branch by Abstraction, разделение базы данных, откат и контроль двойной записи.
В этой главе микросервисы рассматриваются не как целевая картинка, а как из . Newman показывает, как выбирать , постепенно выполнять , держать путь и аккуратно проходить этапы вроде при разделении данных.
Зачем нужна отдельная книга о миграции
Новая разработка и существующая система
позволяет выбрать архитектуру заранее. Миграция почти всегда начинается с , где уже есть пользователи, данные, интеграции и ограничения эксплуатации.
Постепенная миграция
Книга учит заменять монолит небольшими безопасными шагами: без и без ставки, которую невозможно быстро отменить.
Структура книги
Главы 1-2
Зачем мигрировать, когда лучше остановиться и как выбрать первый безопасный срез.
Главы 3-4
Паттерны декомпозиции кода, выделения сервисов и поэтапного разделения базы данных.
Глава 5
Проблемы роста: ответственность команд, наблюдаемость, организация и цена координации.
Глава 1: ровно столько микросервисов, сколько нужно
Три ключевые идеи микросервисов
1. Независимое развёртывание
Если сервис нельзя от соседей, команда получает сетевую сложность без настоящей автономии.
2. Модель вокруг домена
Хорошая граница обычно совпадает с и языком предметной области, а не с техническим слоем.
3. Владение данными
Сервис отвечает за свои данные и открывает их через API, а не через .
Типы монолитов
Монолит в одном процессе
Весь код разворачивается одной единицей. Это не обязательно плохо, пока изменения остаются управляемыми.
Модульный монолит
может быть сильным промежуточным этапом: границы уже видны, а эксплуатационная сложность ещё низкая.
Распределённый монолит
выглядит как набор сервисов, но требует общих релизов, общей базы и постоянной координации.
Глава 2: планирование миграции
Когда микросервисы пока не нужны
- Домен ещё не понятен — сначала разберитесь, где меняются правила и язык.
- Стартап ищет форму продукта — скорость обучения важнее распределённой архитектуры.
- Команда мала — операционная цена сервиса может превысить выигрыш.
- Нет инженерной базы — сначала CI/CD, мониторинг, трассировка и поддержка релизов.
Как выбрать первый сервис для выделения
| Критерий | Что проверить |
|---|---|
| Низкая связанность | Мало зависимостей от соседних частей системы и внешних команд. |
| Понятные границы данных | Видно, какие таблицы и события относятся к этому . |
| Готовая команда | Есть люди, которые готовы взять за код, данные и эксплуатацию. |
| Измеримая польза | Выделение уменьшает задержки изменений, риски релиза или стоимость сопровождения. |
Связанная книга
Learning Domain-Driven Design
Глубже про совместное моделирование событий, карты контекстов и стратегические паттерны декомпозиции.
Domain-Driven Design для декомпозиции
Event Storming
- Собираем и разработчиков.
- Выявляем и бизнес-решения.
- Группируем события в ограниченные контексты.
- Ищем будущие границы сервисов и швы для миграции.
Context Map
- — общий фрагмент модели, который меняется только по договорённости.
- — явная зависимость поставщика и потребителя модели.
- — защитный слой между новой моделью и старой системой.
- — осознанная подстройка под внешний API, когда влиять на него нельзя.
Глава 3: паттерны декомпозиции
Strangler Fig
постепенно переносит сценарии из монолита в новый контур, пока старая реализация не становится ненужной.
Прокси
Ставим маршрутный слой перед монолитом.
Перехват
Отбираем сценарии, которые можно вынести первыми.
Перенаправление
Ведём часть трафика в новый сервис.
Удаление
Убираем старый код после стабилизации нового пути.
Branch by Abstraction
помогает заменить реализацию внутри монолита без долгоживущей ветки и рискованного релиза.
1. Ввести абстракцию
Стабильный интерфейс отделяет вызывающий код от реализации.
2. Добавить новый путь
Новый сервис реализует тот же контракт и проходит параллельные проверки.
3. Переключить трафик
позволяет включать новый путь постепенно.
Параллельный запуск
оставляет старую реализацию источником ответа, но рядом считает результат новой версии и сравнивает расхождения.
Как работает:
- Вызываем старую и новую реализацию.
- Сравниваем результат и побочные эффекты.
- Логируем расхождения и причины.
- Пользователю возвращаем проверенный старый ответ.
Когда полезен:
- Критичные сценарии, например платежи.
- Сложная логика с пограничными случаями.
- Нужна уверенность перед переключением трафика.
Добавление поведения рядом с монолитом
позволяет расширить сценарий рядом с монолитом: например, добавить аудит, логирование или обогащение данных как .
Глава 4: разделение базы данных
Почему это самая сложная часть
Общая база данных остаётся главным препятствием к независимым изменениям. Пока сервисы делят одну схему как контракт, они связаны релизами, миграциями и ошибками соседей.
Риски общей базы:
- Изменение схемы требует координации между командами.
- Неясно, кто владеет таблицей и правилами её изменения.
- Нагрузка одного сценария влияет на остальных.
- Сервис нельзя масштабировать и развивать независимо.
Целевое состояние:
- Каждый сервис владеет своим набором данных.
- Доступ идёт через API или события сервиса.
- Схему можно менять без общих релизов.
- Команда выбирает подходящую СУБД и режим хранения.
Паттерны разделения данных
Database View
- Создаём поверх таблиц монолита.
- Новый сервис читает через ограниченный слой.
- Детали старой схемы скрыты от потребителя.
- Подходит только для чтения.
Database Wrapping Service
- Ставим перед общими таблицами.
- Клиенты обращаются только через API.
- Контракт появляется раньше физического переноса таблиц.
- Это хороший промежуточный шаг перед настоящим владением данными.
Synchronize Data in Application
- Копируем нужные данные в новую базу.
- Синхронизацию выполняет код приложения.
- Постепенно переключаем чтение и запись на новую базу.
- После стабилизации удаляем временную синхронизацию.
Change Data Capture (CDC)
- Изменения читаются из журнала базы или специального источника.
- снижает давление на монолит.
- Инструменты вроде Debezium или AWS DMS помогают построить поток изменений.
- Нужно принять .
Работа с транзакциями
После разделения базы данных исчезают простые транзакции между сервисами. Их заменяют локальные транзакции, события и компенсирующие действия.
Saga
разбивает длинный сценарий на шаги с компенсацией при ошибке.
Outbox
записывает данные и событие в одной локальной транзакции.
Идемпотентность
и ключи идемпотентности делают повторные вызовы безопасными.
Глава 5: проблемы роста
Типичные ошибки при миграции
- Слишком много сервисов сразу — начните с одного-двух безопасных срезов.
- Неясная ответственность — заранее решите, кто сопровождает новый сервис.
- Общая база остаётся надолго — сервисы быстро превращаются в распределённый монолит.
- Нет наблюдаемости — команда не видит, где ломается новый путь.
Организационные аспекты
"If you have four teams working on a compiler, you'll get a 4-pass compiler."
Conway's Law
Обратный манёвр Конвея
предлагает сначала перестроить команды вокруг желаемых границ, а затем переносить код.
Вы создаёте и сопровождаете сервис
: команда отвечает не только за разработку, но и за работу сервиса после релиза.
Ключевые выводы
Что делать
- Мигрировать постепенно, а не переписывать систему одним рывком.
- Использовать постепенный перехват сценариев как основной паттерн безопасного переноса.
- Сначала укреплять модульный монолит, затем выделять сервисы.
- Планировать разделение данных вместе с разделением кода.
Чего избегать
- Не переносить всё сразу и без пути отката.
- Не оставлять общую базу главным контрактом между сервисами.
- Не начинать миграцию без понимания доменных границ.
- Не запускать сервисы без наблюдаемости и ответственной команды.
Для кого эта книга
Подходит:
- Командам, которые поддерживают крупный монолит и хотят снижать риск изменений.
- Архитекторам и техническим лидам, планирующим сервисную миграцию.
- Инженерам, которым нужно аргументировать путь, а не только целевую архитектуру.
- Тем, кто уже прочитал Building Microservices и столкнулся с реальным переходом.
Как читать вместе с другими книгами:
- Building Microservices — целевая модель сервисной архитектуры.
- Monolith to Microservices — безопасный путь из работающей системы.
- DDIA — глубина по распределённым данным и компромиссам согласованности.
Совет: читайте эту книгу как практическое продолжение Building Microservices. Она не обещает лёгкий переход, зато помогает разбить миграцию на шаги, где каждый шаг можно проверить, откатить и объяснить бизнесу.
Связанные главы
- Building Microservices (short summary) - Целевое состояние микросервисной архитектуры: принципы, которые эта книга переводит в пошаговую миграцию.
- Зачем нужны микросервисы и интеграция - Вводная рамка по сервисным границам, контрактам API и интеграции перед планированием миграции монолита.
- Стратегии декомпозиции - Практика выбора ограниченных контекстов и этапов выделения сервисов без остановки работающей системы.
- Learning Domain-Driven Design (short summary) - DDD-основа для доменных границ и контрактов, которая снижает риск получить распределённый монолит.
- Introducing Domain-Oriented Microservice Architecture - Кейс Uber о масштабной доменной трансформации и организационных изменениях при переходе к сервисной архитектуре.
- Модульный монолит и микросервисы - Контекст, когда модульный монолит остаётся рациональным промежуточным этапом перед микросервисным разбиением.