Переосмысляя многопользовательский режим в реальном времени: продвинутые архитектуры Pub-Sub для межрегионального матчмейкинга

Иллюстрация передачи файлов

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

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

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

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

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

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

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

Роль Pub-Sub в современной многопользовательской инфраструктуре

В отличие от точка-точка сокетов или REST API, системы Publisher-Subscriber (pub-sub) позволяют:

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

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

Шаблон архитектуры: Шардинг лобби через динамические каналы

Шаблон архитектуры

В наших развертываниях в реальном мире мы разработали архитектуру шардинга матчмейкинга, которая назначает игроков в лобби через динамические каналы pub-sub. Вот как это работает:

Входной шлюз получает запрос на игру и публикует “запрос на присоединение” в тему матчмейкинга, специфичную для региона.
Сервис матчмейкера (бессостояние, горизонтально масштабируемый) подписывается на эту тему и маршрутизирует игрока в шард лобби — эфемерный канал pub-sub.
Как только шард достигает кворума (например, 4 игрока), сервис публикует событие start_game для всех подписанных клиентов.
Каждый клиент затем переходит в сессию игры в реальном времени, управляемую через специальную тему состояния матчей.

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

Межрегиональная брокерская сетка: решение проблемы “заблокированного сервера”

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

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

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

Ключевые уроки из производственного использования

На протяжении миллионов сессий и реальных PvP матчей с денежными ставками несколько выводов выделяются:

Гигиена тем критически важна. Автоистекающие или эфемерные темы предотвращают утечки памяти и призрачных игроков.
Выбор брокера имеет значение. Redis PubSub прост, но не гарантирует порядок и доставку; NATS и Kafka предлагают больше контроля за счет сложности настройки.
Наблюдаемость должна быть встроенной. Каждое событие сообщения должно быть отслеживаемым — OpenTelemetry помог нам выявить тонкие рассинхронизации и тайм-ауты.
Запасные варианты на стороне клиента являются обязательными. Когда pub-sub не работает (например, ненадежные мобильные сети), клиенты плавно переходят в режим восстановления с опросом.

Переход к полностью безсерверной оркестрации

Мы сейчас исследуем архитектуру с приоритетом на безсерверные технологии для будущих игр, где

Логика матчмейкинга выражается как функции, основанные на событиях (например, AWS Lambda, GCP Cloud Functions).
Оркестрация лобби работает на бессостоящих контейнерах, которые запускаются по регионам во время пиковых нагрузок.
Pub-sub остается основной основой для матчмейкинга и внутриигрового обмена сообщениями, абстрагируя сложности маршрутизации инфраструктуры.

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

Заключение

Pub-sub — это не просто деталь реализации — это возможность изменить то, как многопользовательские игры масштабируются, адаптируются и выживают в современных условиях.

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

Статья является редакционной, автором является Андрей Кулаков

Андрей Кулаков — системный архитектор и дизайнер игр, сосредоточенный на многопользовательской инфраструктуре для мобильных и казуальных игр. Он внес вклад в некоторые из самых технически сложных фреймворков матчмейкинга в Восточной Европе и в настоящее время исследует безсерверные архитектуры для глобального многопользовательского масштаба.

Эта история была первоначально опубликована 3 октября 2022 года