Как предоставить несколько сервисов через облачный шлюз?

Question

Предположим, я работаю над многопользовательской онлайн-игрой. Каждая группа игроков может начать экземпляр игры, чтобы играть. Возьмем для примера League of Legends.

В любой момент одновременно проводится множество игровых матчей. Мой вопрос об архитектуре этого дела. Вот мои предложения:

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

Это лучшее, что мы можем получить?

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

Обратите внимание, что это сокет-соединения, а не HTTP-запросы к API-шлюзу.

РЕДАКТИРОВАТЬ 1: Этот вопрос не о балансировке нагрузки

Ключевое слово: ports . Будет ли каждый матч обслуживаться в другом порту? или есть другой способ обслуживания нескольких служб на одном хосте (host = IP)?

Разработка: я использую модель клиент-сервер для каждого экземпляра матча. Таким образом, несколько клиентов могут подключаться к одному и тому же серверу совпадений, чтобы участвовать в одном совпадении. Каждое совпадение должно быть сервером совпадения.

Имеется ограничение: один хост (= IP) для обслуживания нескольких сервисов должен предоставлять их на разных портах. Матч 1 на порту 1234. Таким образом, клиенты, участвующие в матче 1, будут подключаться к серверу матчей и взаимодействовать с ним через порт 1234.

РЕДАКТИРОВАТЬ 2: Масштабируемость является целью

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

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

Пример: Любой клиент запустит TCP-соединение с сервером, прослушивающим порт A. Есть ли способ обслуживать несколько MatchServer на одном и том же порту A (чтобы больше одновременных MatchServers не приводило к в больше портов)?

Есть ли лучший масштабируемый способ обслуживать разные миры нескольких матчей?

Answer 1

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

Длинный ответ:

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

Для League of Legends это может быть довольно просто: использовать какой-нибудь сервер поиска работоспособности с наименьшим количеством нагрузки и прикрепить (вроде как липкие сеансы ) текущую игру к этому серверу - пока игра не закончится любые вычисления для конкретной игры сделаны там. Вы можете использовать любой механизм кэширования для хранения отношения game - server для последующих запросов на стороне шлюза.

Другим, немного более сложным примером может быть хранение данных для статистики для конкретной игры - обычно это решается с помощью sharding , что является обычным следствием распределенных вычислений. Это можно решить следующим образом: используйте какую-то функцию хеширования (например, по модулю) с идентификатором игры в качестве параметра для расчета номера сервера. Например, 18283 mod 15 = 13 для идентификатора игры = 18283 и 15 доступных шардов - поэтому 13-й сервер должен хранить / обслуживать эти данные.

Основной проблемой здесь будет «ребалансировка» - например, добавление / удаление осколка из кластера.

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