Как перенести монолит на микросервисы, используя паттерн strangler-fig?

Question

Accepted Answer

The **strangler-fig pattern** выполняет миграцию пошагово: вы оборачиваете монолит слоем маршрутизации, извлекаете одну возможность за раз в сервис и перенаправляете трафик на него — пока монолит не будет "задушен". Нет **полной переписи с нуля**.

## Как это работает

```text
Step 1: route all traffic through a facade/proxy to the monolith
Step 2: extract ONE capability → new service
Step 3: route just that path to the new service
Step 4: repeat; delete that code from the monolith

Client ─▶ [ Proxy ] ─┬─▶ /orders  ─▶ NEW Orders service
                       └─▶ everything else ─▶ Monolith
```

## Выбор того, что извлечь в первую очередь

```text
✓ A bounded context with clear boundaries
✓ Something that needs independent scaling or deploys
✓ A part with few inbound dependencies (low risk)
✗ Don't start with the tangled core
```

## Обработка общих данных

Самая сложная часть — база данных. Извлеките таблицы сервиса, затем разорвите связь с общей БД, используя события или слой anti-corruption, часто через технику **branch-by-abstraction**, пока оба работают.

## Компромиссы

```text
✓ Low risk — small, reversible steps, always shippable
✓ Value early, learn the seams as you go
✗ Slow; you run a hybrid system for a long time
✗ Temporary duplication and routing complexity
```

## Почему это важно

Полные переписи с нуля печально известны своими провалами — они замораживают разработку функций на месяцы и выполняют рискованное единовременное переключение.

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