Я пытаюсь найти способ разработать архитектуру игрового сервера для мобильной игры в реальном времени. Дизайн должен быть рентабельным, но все же в некоторой степени масштабируемым (позже, по крайней мере, с минимальными усилиями).
Поток мобильных клиентов:
Подключается к серверу-дистрибьютору, предоставленному DNS LB, и группируется с x игроками. Если достигнуто y игроков, серверу-дистрибьютору необходимо связаться с управляющим сервером, который запускает или использует уже запущенный игровой сервер. Управляющий сервер отправляет обратно IP-адрес и порт на сервер-распределитель, который затем отправляет их сгруппированным игрокам. Затем игроки подключаются к данному игровому серверу. После игры игроки будут отправлены вместе на новый или тот же сервер-дистрибьютор.
Интересно, как реальным сервером (виртуальными машинами) для игровых серверов можно управлять динамически. Я посмотрел на экземпляры AWS EC2, но если у нас есть 500 игроков с 6 игроками в группе, которые играют 6 часов в день, нам потребуется ~ 84 экземпляра EC2 t3.small (2 виртуальных ЦП, 2 ГБ ОЗУ) запущенных. Это будет стоить ~ 1160,00 долларов США в месяц. Думаю, с такой ценой было бы выгодно иметь реальные виртуальные машины, а не динамические облачные экземпляры?
Я также посмотрел на AWS ECS что может быть хорошей уловкой, но я не уверен, как можно управлять игровыми серверами в контейнерах для автоматического масштабирования.
Ссылка на изображение Вот. Извините, изображения могут быть размещены не менее чем с 10 повторениями.
Распределитель:
Мобильные клиенты будут подключаться к ним, чтобы объединяться с другими игроками. Это похоже на лобби, где игроки будут сидеть, пока не дойдут до X игроков или, например. обратный отсчет закончился.
Сервер управления:
Необходимо позаботиться о запущенном сервере (ВМ) и обработать запросы на запуск игрового сервера от дистрибьюторов.
Игровой сервер:
Является авторитетным серверным клиентом с физикой и т.д. Один игровой сервер (программное обеспечение) для X игроков в группе. Игроки будут подключаться к ним от дистрибьютора после «фазы» лобби.
Как это может быть динамически масштабируемым / рентабельным и пригодна ли эта архитектура? Я вижу одну проблему с управляющим сервером, потому что он должен обслуживать N игровых серверов vms и N дистрибьюторов. Но если мы масштабируем сервер управления, то каждый сервер управления должен знать то же самое, что и любой другой.
(Если чего-то не хватает или что-то может быть улучшено, дайте мне знать. Английский не мой родной язык, поэтому сложно выразить мою цель в такой сложной теме, как эта)
Это может быть полезная архитектура. Обратите внимание на хранение данных. Где хранятся данные? Если в базе данных SQL, как вы это масштабируете?
Чтобы масштабировать игру:
Если управляющий сервер выполняет только управление и контроль, это не должно быть узким местом.
Часть ОС, экземпляры ВМ:
Пока каждый компонент может масштабироваться независимо от других, все в порядке.
Сначала получите базу пользователей. К тому времени вы будете лучше понимать, где находятся точки давления и что нужно оптимизировать.
