От монолита к сервисам

Поиск швов: bounded context как единицы декомпозиции

Правильный шов для извлечения сервиса — это bounded context (урок 06): область модели, где применяется один согласованный набор концепций и языка. Bounded context уже имеет естественную API-поверхность — трансляции, которые он экспортирует в другие контексты — и естественную границу данных — агрегаты, которыми он владеет.

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

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

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

Паттерн strangler fig

Strangler fig (Фаулер, 2004) — инкрементальный паттерн миграции, названный в честь тропической лианы, растущей вокруг существующего дерева и в конце концов заменяющей его. Применительно к ПО:

1. Поставь прокси перед монолитом. Весь трафик проходит через прокси (API-шлюз, слой маршрутизации или обратный прокси). Монолит изначально обрабатывает всё.
2. Извлеки одну возможность в новый сервис. Новый сервис владеет частью домена — правильным bounded context.
3. Маршрутизируй трафик этой возможности к новому сервису. Прокси направляет запросы извлечённой возможности к новому сервису. Код монолита для этой возможности становится мёртвым.
4. Удали мёртвый код из монолита. Монолит уменьшается. Повторяй для следующей возможности.

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

Владение данными и правило database-per-service

Самое нарушаемое правило при миграции на микросервисы — владение данными. Strangler fig может маршрутизировать API-трафик к новому сервису с первого дня, но миграция владения данными занимает больше времени. Пока владение данными не передано, сервис — фасад, а не автономная единица.

Database-per-service означает, что у каждого сервиса есть собственное хранилище без чтения или записи его таблиц другими сервисами. Это не технологический выбор (один инстанс PostgreSQL может обслуживать несколько сервисов на разных схемах) — это контракт владения:

• Только BillingService пишет в таблицы invoices и charges.
• Никакой другой сервис не держит ORM-модель для этих таблиц.
• Другие сервисы, которым нужны данные биллинга, вызывают API BillingService или потребляют его события.

Последовательность миграции для владения данными:

1. Определить весь код в монолите, читающий или пишущий мигрируемые таблицы.
2. Обернуть эти точки доступа за интерфейс в монолите, совпадающий с API-поверхностью нового сервиса.
3. Задеплоить новый сервис и направить реализацию интерфейса монолита на API нового сервиса.
4. Мигрировать данные в новую схему.
5. Удалить таблицы монолита (или заблокировать схему так, чтобы записи отклонялись).

Декомпозиция по возможности, а не по слою

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

Сервис, извлечённый по слою:

• Не может быть независимо задеплоен (сервис логики зависит от сервиса данных для каждой операции).
• Не может быть независимо протестирован (сервис логики не имеет поведения без сервиса данных).
• Принуждает к синхронному зацеплению для каждого запроса (три сетевых хопа вместо нуля).

Сервис, извлечённый по бизнес-возможности, владеет своим полным вертикальным срезом: API, логика, хранилище. Это подход вертикальных срезов, применённый к декомпозиции сервисов.

Последовательность: что извлекать первым

Не все модули одинаково хороши в качестве отправной точки для извлечения. Strangler fig работает лучше, когда первый извлекаемый сервис:

Имеет низкое зацепление с другими внутренностями монолита. Если биллинговая возможность обращается только к двум внутренним API (и эти вызовы можно обернуть за интерфейсы), извлечение относительно ограничено. Если она разделяет таблицы с каждым другим модулем, извлечение требует одновременной миграции каждой точки доступа.

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

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

Имеет чёткое владение. Команда, уже владеющая возможностью, может владеть её сервисом. Общий кросс-командный код сложнее всего извлекать.