Сеть игровых серверов и магазин к ней
Проект показываем обезличенно: без названия, отрасли и ссылок
Проект живёт в продакшене с реальными игроками: несколько игровых режимов, между которыми игрок переходит без переподключения, общая авторизация и общий баланс на всю сеть, поддержка второй клиентской платформы и сайт, через который сеть монетизируется. Это редкий для студии тип нагрузки — состояние живёт в памяти процессов, а не в запросах, и перезапуск виден игрокам сразу.
Задача
- Отдельные серверы означают отдельные аккаунты, отдельные балансы и потерю игрока на каждом переходе. Нужна была сеть: единая точка входа, общая авторизация, один баланс на все режимы и возможность обновлять один режим, не выкидывая всех остальных. Плюс площадка, где эта сеть продаёт свои услуги и принимает оплату.
Что сделали
- Единая точка входа с маршрутизацией: игрок переходит между режимами без переподключения
- Общая авторизация со своей доработкой под сценарии сети и отдельным сервером ожидания
- Единая экономика: баланс и права хранятся в общем хранилище и одинаковы во всех режимах
- Поддержка второй клиентской платформы — игроки с консольно-мобильных клиентов заходят в ту же сеть
- Раздельная выкладка режимов: обновление одного не роняет остальные
- Сайт сети: тарифы, промокоды, приём оплаты и живой статус серверов с онлайном
- Управление и деплой скриптами: один контур команд вместо ручных операций на сервере
Результат
- Сеть работает в продакшене с живыми игроками, обновления выкатываются по одному режиму
- Игрок сохраняет аккаунт, баланс и права при переходе между режимами
- Аудитория второй клиентской платформы получила доступ без отдельной инфраструктуры
- Монетизация идёт через сайт с автоматической выдачей покупок в игру
Почему нельзя просто поставить несколько серверов
Наивная схема — несколько независимых серверов и список адресов на сайте — ломается на первом же игроке, который захотел перейти между режимами. Он теряет соединение, заходит заново, обнаруживает другой баланс и другие права, и чаще всего просто не возвращается. Поэтому в основе сети стоит единая точка входа: игрок подключается к ней один раз, а переход между режимами происходит внутри, без разрыва.
Из этого вытекает всё остальное. Раз соединение одно, авторизация должна быть общей. Раз авторизация общая, баланс и права тоже должны жить в одном месте, а не в файлах каждого сервера. Так набор серверов превращается в сеть, а не в список адресов.
Общее состояние и почему его вынесли из процессов
Баланс, права и связанные с игроком данные вынесены в общее хранилище с быстрым доступом, а долговременные записи — в реляционную базу. Это даёт две вещи сразу. Первая: любой режим видит актуальные значения без синхронизации между собой. Вторая: перезапуск одного режима не теряет ничего, кроме самой сессии — игрок вернётся туда же, с тем же балансом.
Отдельная работа потребовалась на стыке с авторизацией. Штатное решение не покрывало сценарии сети, поэтому его пришлось дорабатывать под себя и добавить отдельный сервер ожидания, который держит игрока, пока нужный режим поднимается. Для игрока это выглядит как короткая пауза вместо выброса из игры.
Магазин, который сам выдаёт покупку
Сайт сети — это не витрина, а часть контура: он принимает оплату, проверяет промокод и сам выдаёт покупку в игру, без участия администратора. Ключевое требование здесь — идемпотентность: подтверждение оплаты может прийти дважды, и вторая выдача не должна происходить. Каждая покупка обрабатывается по своему ключу, повтор с тем же ключом ничего не меняет.
Вторая заметная часть — живой статус серверов на сайте. Он не только показывает онлайн посетителю, но и работает диагностикой для команды: если режим перестал отвечать, это видно на главной странице раньше, чем об этом напишут игроки.
Что значит эксплуатировать проект с живыми пользователями
Разница между сдачей сайта и сопровождением сети — в цене перезапуска. Здесь любое обновление видно людям, которые в этот момент играют, поэтому все операции доведены до скриптов: запуск, остановка, выкладка конкретного режима, снятие резервной копии. Ручные команды на сервере исключены не из аккуратности, а потому что ошибка в них означает потерянный прогресс у реальных игроков.
Отсюда же требование к раздельной выкладке. Один режим обновляется, остальные продолжают работать, а игроки обновляемого получают предупреждение заранее. Это не архитектурное украшение, а условие, без которого сеть нельзя развивать, не теряя аудиторию на каждом релизе.