Что такое Strangler Fig — постепенная миграция legacy?

#Метафора

Фикус-душитель прорастает на дереве-хозяине, постепенно оплетает его корнями, и через годы от старого дерева остаётся лишь пустота внутри нового. Система-хозяин продолжает работать, пока новая берёт на себя её функции.

#Big bang против Strangler Fig

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

#Шаги для каждой функции

#Фасад на YARP

{
  "ReverseProxy": {
    "Routes": {
      "catalog-new": { "ClusterId": "catalog", "Order": 1, "Match": { "Path": "/api/catalog/{**rest}" } },
      "legacy-all":  { "ClusterId": "legacy",  "Order": 100, "Match": { "Path": "{**catch-all}" } }
    },
    "Clusters": {
      "catalog": { "Destinations": { "d1": { "Address": "http://catalog-service:8080" } } },
      "legacy":  { "Destinations": { "d1": { "Address": "http://legacy-iis.internal" } } }
    }
  }
}

Постепенное переключение — по проценту трафика, пользователям-тестировщикам или feature flag:

app.MapReverseProxy(proxy => proxy.Use(async (ctx, next) =>
{
    var flags = ctx.RequestServices.GetRequiredService<IFeatureManager>();
    if (ctx.Request.Path.StartsWithSegments("/api/orders") && !await flags.IsEnabledAsync("NewOrdersService"))
        ctx.Features.Get<IReverseProxyFeature>()!.AvailableDestinations = GetLegacyDestinations(ctx);
    await next();
}));

Microsoft предлагает для ASP.NET Framework → ASP.NET Core готовые инструменты: System.Web Adapters и YARP-based incremental migration (новое приложение ASP.NET Core проксирует немигрированные маршруты в старое, общая сессия и аутентификация).

#Данные — самая сложная часть

Варианты:

1. Общая БД на переходный период — новый сервис читает/пишет в старую схему. Быстро, но сохраняет связанность; допустимо как временный шаг.
2. Синхронизация через CDC (Debezium) или события: legacy остаётся источником истины, новая БД — производная, пока функция не мигрирована полностью.
3. Двойная запись через фасад/новый сервис (с outbox, не наивно!) на время перехода.
4. Перенос владения: после переключения новая система — источник истины, старая получает изменения обратно, если они ей ещё нужны.

#Anti-Corruption Layer

ACL (термин DDD) не даёт странностям старой модели «просочиться» в новую: маппинг статусов, форматов, кодировок, разбиение «божественных» таблиц. Новая система говорит на своём языке, а переводом занимается изолированный слой.

#Практические советы

• Начинайте с функции, которая приносит ценность и слабо связана с остальным (каталог, уведомления, отчёты), чтобы быстро доказать работоспособность подхода.
• Замораживайте изменения в мигрируемой части legacy, иначе придётся переносить движущуюся цель.
• Сравнивайте результаты (shadow traffic / dark launch): отправлять копию запросов в новую систему и сравнивать ответы, не отдавая их пользователю.
• Удаляйте мигрированный код из legacy — иначе через год будут поддерживаться обе версии.
• Наблюдаемость обеих систем и фасада — единые трассировки и метрики.
• Иметь план завершения: без него «временное» сосуществование становится постоянным.

#Вопросы на засыпку

#Итог

Strangler Fig заменяет legacy постепенно: фасад перехватывает трафик, функции переносятся по одной с постепенным переключением и возможностью отката, а старый код удаляется. Главные сложности — данные и изоляция моделей (CDC, события, Anti-Corruption Layer). Это медленнее на старте, но надёжнее и ценнее для бизнеса, чем большое переписывание.