Миграция iGaming по Strangler Fig: передайте ответственность и отключите старый путь

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

Описание Strangler Fig Мартина Фаулера объясняет постепенную замену управляемых частей и временную архитектуру для совместной работы старого и нового. На действующей iGaming-платформе практическая задача — передать ограниченную функциональность, не потеряв принятую работу и не создав второй источник финансовых изменений.

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

Выберите часть платформы и определите, что останется

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

В нашем примере предлагаемая часть переносит управление процессом вывода в согласованном объёме в новый компонент. Существующий кошелёк остаётся единственным источником финансовых записей через свой контролируемый интерфейс. Проверка личности, ограничения игроков и договорённости с провайдерами остаются зависимостями. Это не миграция кошелька; новый компонент не получает права напрямую редактировать балансы.

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

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

Контролируйте каждый вход на границе замены

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

Руководство Microsoft по Strangler Fig описывает фасад, распределяющий запросы между старым и новым компонентами, и предупреждает о возможном узком месте или единой точке отказа. Эксплуатируйте слой маршрутизации как сервис с проверенными ресурсами, управлением доступом, мониторингом и версионируемой конфигурацией.

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

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

Различайте маршрутизацию ещё не перенесённой функциональности и повтор неопределённой команды. Истечение ожидания после возможного принятия не разрешает отправить тот же запрос другой реализации. Сохраните неопределённость и расследуйте её через ответственный путь; автоматическое переключение иначе может создать дополнительную выплату.

Сохраните явного ответственного за незавершённые операции

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

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

• Приём: надёжно сохраните идентификатор операции, контекст операции, выбранный ответственный компонент, аккаунт провайдера, доступные идентификаторы связи и значимые условия до запуска действий, которые могут изменить средства или вызвать действие во внешней системе. Полученные позже идентификаторы провайдера привяжите к той же операции.
• Продолжение: проверяйте подлинность и соответствие обратных вызовов, запланированной работы и действий сотрудников исходной операции. Неизвестные или противоречивые доказательства требуют ответственного за расследование.
• Деньги: применяйте разрешённую команду кошелька через существующий источник финансовых изменений с исходным идентификатором операции и проверенным контекстом операции. Повторные доказательства не должны повторять финансовый эффект.
• Ограничения: сохраняйте принятый контекст, не предполагая, что он разрешает любое дальнейшее действие. Применяйте текущие меры контроля, необходимые для фактического действия и правил оператора.

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

Переносите данные без конкурирующих полномочий

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

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

Конкретный пример базы: логическая репликация PostgreSQL 18 копирует данные таблиц, затем применяет последующие изменения источника. Её документированные ограничения включают изменения схемы и состояния последовательностей, которые не реплицируются. Поэтому репликация строк сама не подтверждает готовности записывать в целевую базу. Проверьте фактические движок, версию и механизм миграции.

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

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

Докажите совместную работу до перенаправления реальных запросов

Сделайте сравнение безопасным до объявления параллельного запуска. Начните с контролируемых тестовых данных и записанных случаев, подходящих утверждённой среде. Теневая проверка может вычислять ответ замены, но не должна отправлять реальные команды провайдеру, создавать записи кошелька или запускать сообщения игрокам. Обеспечьте эту границу технически, а не неформальным обещанием тестировщиков.

Сравнивайте смысл, а не только одинаковый JSON. Остаётся ли та же операция нерешённой? Остаётся ли запрещённое действие запрещённым? Может ли поддержка найти тот же идентификатор провайдера? Документируйте намеренные различия, например исправленное сопоставление статусов, с ответственным за решение. Необъяснимое финансовое расхождение или расхождение доступа блокирует расширение; старый результат — доказательство для изучения, а не всегда правильная спецификация.

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

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

Проведите переход с двумя разными планами восстановления

Напишите исполнимый план переключения с ответственным за решение, техническими действиями, доказательствами, условиями приостановки и коммуникацией. План должен сказать, что передаётся и что остаётся в старом компоненте. Презентации «направить трафик в новый сервис» недостаточно.

• Подготовка: продемонстрируйте выбранную часть, совместимые контракты, маршрутизацию по ответственному за операцию, восстановление захвата и процедуры принимающей команды. Подтвердите внешние зависимости и утверждённые меры контроля.
• Установление границы: запретите старому компоненту принимать новые выводы выбранного объёма, сохранив обработку уже принятой работы. Запрещайте прежнему компоненту запись только в той области данных, ответственность за которую фактически передаёте; в примере кошелёк сохраняет полномочия. Примените накопившиеся изменения и сверьте нужные данные в согласованной точке до разрешения новой стороне принимать работу.
• Переключение и наблюдение: включите выбранную новую ответственность через контролируемую конфигурацию. Предотвратите конкурирующие приём и записи; проверьте принятые операции, доказательства провайдера, эффекты кошелька и доступ поддержки. Остановите расширение, если обязательное условие не доказано.

До принятия новой работы замещающим компонентом возврат на старый маршрут может быть возможен, если команда докажет отсутствие новых устойчивых обязательств или внешних эффектов и совместимость старого пути. Отрепетируйте этот случай, а не предполагайте его.

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

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

Отключите старый путь и оцените следующую часть

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

Безопасно проверьте предлагаемое отключение в согласованной среде и изучите доказательства зависимостей за период, выбранный для реального процесса. Отсутствие запросов к конечной точке за короткий период наблюдения не исключает задержанный ответ провайдера или редкое задание. Осознанно отключайте оставшиеся полномочия; не удаляйте финансовую или аудиторскую историю ради чистой архитектурной схемы.

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

Сравните результат с исходным ограничением: может ли команда менять процесс вывода с нужной независимостью, может ли поддержка решать те же случаи и исчезла ли старая зависимость? Затем выберите следующую часть по текущим доказательствам. Если нельзя контролировать входы, оплачивать совместную эксплуатацию или поддерживать старую систему, пересмотрите более широкую замену либо другое вмешательство.

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

• Граница принята: функциональность, входные пути, зависимости, сохранённый источник финансовых изменений и ожидаемое улучшение явны и пригодны для проверки.
• Совместная работа доказана: безопасное сравнение, совместимые контракты, надёжная ответственность за операции и полный захват изменений продемонстрированы в предложенном объёме.
• Передача контролируется: в каждой передаваемой области решения принимает только одна ответственная система; согласованы доказательства, сверка, процедуры сотрудников и восстановление до и после новой работы.
• Отключение обосновано: старые вызовы, записи и открытые обязательства закрыты, нужная история доступна, судьба временных зависимостей определена с ответственными.