Companion Book
Building Microservices
Теория и целевое состояние микросервисной архитектуры — что строить, а эта книга о том, как туда прийти.
Monolith to Microservices (От монолита к микросервисам)
Авторы: Sam Newman
Издательство: O'Reilly Media, 2019
Объём: 272 страниц
Разбор книги Sam Newman: Strangler Fig, Branch by Abstraction, разделение БД и практические паттерны миграции.
Оригинал
ПереводЗачем отдельная книга о миграции?
Greenfield vs Brownfield
"Building Microservices" описывает идеальный мир. Но 90% проектов — это legacy-системы, которые нужно трансформировать, не останавливая production.
Инкрементальная миграция
Книга даёт конкретные паттерны для постепенного перехода — без "big bang" переписывания и с минимальным риском для бизнеса.
Структура книги
Главы 1-2
Зачем мигрировать? Когда НЕ мигрировать? Планирование миграции.
Главы 3-4
Паттерны декомпозиции кода и разделения базы данных.
Глава 5
Проблемы роста и организационные аспекты миграции.
Глава 1: Просто достаточно микросервисов
Три ключевые идеи микросервисов
1. Independent Deployability
Возможность деплоить сервис без координации с другими командами — главный критерий правильных микросервисов.
2. Моделирование по домену
Границы сервисов = границы бизнес-доменов. DDD и Bounded Contexts как основа.
3. Владение данными
Каждый сервис владеет своими данными и скрывает их за API. Нет shared database.
Типы монолитов
Single-Process
Весь код в одном deployable unit. Самый распространённый тип.
Modular Monolith
Внутри разбит на модули, но деплоится как единое целое. Хороший промежуточный вариант!
Distributed Monolith
Худший вариант — формально сервисы, но все тесно связаны. Сложность обоих миров.
Глава 2: Планирование миграции
Когда НЕ нужны микросервисы?
- Непонятный домен — сначала поймите бизнес
- Стартап — скорость важнее архитектуры
- Маленькая команда — overhead перевесит пользу
- Нет DevOps культуры — сначала CI/CD и мониторинг
Как выбрать первый сервис для выделения?
| Критерий | Описание |
|---|---|
| Низкое зацепление | Минимум зависимостей от других частей системы |
| Чёткие границы данных | Понятно, какие таблицы "принадлежат" этому домену |
| Команда готова | Есть люди, способные владеть сервисом end-to-end |
| Бизнес-ценность | Выделение даст измеримые преимущества |
Связанная книга
Learning Domain-Driven Design
Полное руководство по DDD: Event Storming, Context Maps, strategic patterns для декомпозиции.
Domain-Driven Design для декомпозиции
Event Storming
- Собираем domain experts и разработчиков
- Выявляем domain events (оранжевые стикеры)
- Группируем в Bounded Contexts
- Находим границы будущих сервисов
Context Maps
- Shared Kernel — общий код
- Customer-Supplier — upstream/downstream
- Anticorruption Layer — защита от legacy
- Conformist — подстраиваемся под внешний API
Глава 3: Паттерны декомпозиции
Strangler Fig Pattern
Главный паттерн миграции — постепенное "обвивание" монолита новыми сервисами, пока от старой системы ничего не останется.
Proxy
Ставим proxy перед монолитом
Intercept
Перехватываем нужные вызовы
Redirect
Направляем в новый сервис
Remove
Удаляем код из монолита
Branch by Abstraction
Для выделения функционала изнутри монолита:
1. Создать абстракцию
Интерфейс вокруг выделяемого кода
2. Новая реализация
Микросервис, реализующий интерфейс
3. Переключение
Feature toggle → удаление старого кода
Parallel Run
Запускаем старую и новую реализацию параллельно, сравниваем результаты:
Как работает:
- Вызываем обе реализации
- Сравниваем результаты
- Логируем расхождения
- Возвращаем результат "старой" версии
Когда использовать:
- Критичный функционал (платежи)
- Сложная логика с edge cases
- Нужна уверенность в корректности
Decorating Collaborator
Добавляем новый функционал через прокси-сервис, не меняя монолит. Полезно для cross-cutting concerns: логирование, аудит, обогащение данных.
Глава 4: Разделение базы данных
Почему это самая сложная часть?
Shared database — главное препятствие к независимому деплою. Пока сервисы используют общую БД, они не являются настоящими микросервисами.
Проблемы shared DB:
- Изменение схемы требует координации
- Нет чётких границ владения данными
- Производительность одного влияет на всех
- Невозможно масштабировать независимо
Цель:
- Каждый сервис владеет своими данными
- Данные доступны только через API сервиса
- Можно менять схему без координации
- Можно выбирать подходящую СУБД
Паттерны разделения данных
Database View
- Создаём view поверх таблиц монолита
- Новый сервис читает через view
- Скрываем детали схемы
- Только для чтения!
Database Wrapping Service
- API-сервис перед shared таблицами
- Все обращаются только через API
- Потом переносим таблицы в сервис
- Хороший промежуточный шаг
Synchronize Data in Application
- Дублируем данные в новую БД
- Синхронизируем через application code
- Переключаемся на новую БД
- Удаляем синхронизацию
Change Data Capture (CDC)
- Debezium, AWS DMS
- Стримим изменения в реальном времени
- Минимальное влияние на монолит
- Eventual consistency
Работа с транзакциями
После разделения БД теряем ACID транзакции между сервисами. Альтернативы:
Saga Pattern
Цепочка локальных транзакций с компенсирующими действиями при ошибке.
Outbox Pattern
Атомарно записываем данные + событие в одну БД, затем публикуем.
Idempotency
Безопасные повторные вызовы с помощью idempotency keys.
Глава 5: Проблемы роста
Типичные ошибки при миграции
- Слишком много сервисов сразу — начните с 1-2
- Игнорирование ownership — кто будет поддерживать?
- Shared database надолго — создаёт distributed monolith
- Нет observability — не видите что происходит
Организационные аспекты
"If you have four teams working on a compiler, you'll get a 4-pass compiler."
— Conway's Law
Inverse Conway Maneuver:
Сначала реорганизуйте команды по доменам, потом мигрируйте код.
You Build It, You Run It:
Команда, которая пишет сервис, отвечает за его работу в production.
Ключевые выводы
Do:
- Инкрементальная миграция, а не big bang
- Strangler Fig как основной паттерн
- Сначала modular monolith, потом микросервисы
- Выделять БД сервиса как можно раньше
Don't:
- Мигрировать всё сразу
- Shared database между сервисами надолго
- Мигрировать без понимания домена
- Начинать без observability
Для кого эта книга?
Идеально подходит:
- Командам с legacy монолитом
- Архитекторам, планирующим миграцию
- Tech leads, ищущим практические паттерны
- Всем, кто уже прочитал "Building Microservices"
Связь с другими книгами:
- Building Microservices — теория и целевое состояние
- Monolith to Microservices — как туда добраться
- DDIA — глубокое понимание распределённых данных
Совет: Эта книга — идеальный companion к "Building Microservices". Первая книга рассказывает что такое микросервисы, вторая — как к ним прийти из существующего монолита.