Динамические вершины - как правильно спроектировать архитектуру vert.x для простой игры vert.x?

Я пытаюсь разработать доказательство концепции для Vert.x - простой браузер в реальном времени.

Представьте себе игру, похожую на онлайн-покер - у вас есть лобби с рядом существующих игр, к которым вы можете присоединиться. Вы также можете создать новую игру (поэтому количество игр в этом лобби является переменной). Перед этим у вас есть асинхронный HTTP-сервер (кластер), к которому подключаются игроки. Особенно когда-то в конкретной игре, все в режиме реального времени, поэтому, когда игрок выполняет какое-то действие, другие видят его сразу без обновления или регулярного опроса ajax.

Я думал о том, как разбить эту функциональность на вершины. Моя первая мысль - создать вертикулу для обработки http-подключений (и настроить http-сервер для отображения выбранных событий в eventbus для http-клиентов), еще одна вершина для представления игрового лобби и третьей вертикали для представления реальной игры. Лобби и виртуальные игры будут знать только о шине событий, они вообще не будут обрабатывать http.

Единственное, что неясно мне, - это объем этих вершин, особенно игровая вертикаль, потому что будет больше (динамическое число) игр. По умолчанию вы устанавливаете фиксированное количество конкретных экземпляров вертикул (в простых приложениях, которые часто являются одними). В этом сценарии эта одна вертикаль должна будет прослушивать события event-событий для игр, решать, к какой игре относится это событие, десериализовать состояние игры, изменить ее, сериализовать и снова сохранить. Затем уведомите всех подключенных игроков.

Вместо этого я хотел бы использовать область вершин для каждой игры. Под этим я имею в виду, что когда в вестибюле создается новая игра, то в верхней части виртуальной верхушки появится новый экземпляр вершин игры, передайте ему (каким-то образом) новый идентификатор игры (чтобы он мог привязываться к событиям только для этого ID игры) и эта игровая вертикаль сохранит состояние для этой конкретной игры в памяти в своих переменных экземпляра. Когда игра заканчивается, verticle инструктирует подключенные браузеры возвращаться в лобби и уничтожать себя.

Я пытаюсь представить это правильно? Если да, то каков наилучший способ достижения этого? В частности, речь идет о динамическом создании и уничтожении экземпляров verticle, передавая некоторую информацию (ID и т.д.) На вновь созданную вершину?

Бонусный вопрос - как я могу ограничить, что игрок может слушать (и отправлять) события из игры, к которой он принадлежит? Так что он не влияет на другие игры. В основном аналогичная вещь, которую вы бы сделали с сеансами/управлением доступом в традиционном приложении Java Servlet/EE.

1 ответ

Поскольку в течение некоторого времени не было ответов, я реализовал его так, как я изначально описывал в вопросе. Это действительно неплохо, демонстрационный код можно найти здесь: https://github.com/michalboska/codingbeer-vertx

Существует одна Verticle (GameLobbyVerticle), которая запускает новый экземпляр GameVerticle для каждой игры. Экземпляр GameVerticle запоминает (в переменных-членах) все состояния, относящиеся к конкретному экземпляру игры.

Каждый экземпляр также создает несколько конечных точек EventBus (адреса содержат уникальный идентификатор игры, так что каждый экземпляр GameVerticle имеет свои собственные уникальные конечные точки eventbus) и прослушивает системные сообщения, вход игроков и передает события связанным игрокам. Каждый экземпляр имеет "общедоступную очередь" (доступную клиентам WebSocket через мост eventbus) и "приватную очередь" (недоступную через мост, предназначенную для системных сообщений, которые мы не хотим, чтобы клиенты обманывали).

Динамическое развертывание и развертывание выполняется с помощью API-интерфейсов container.deployVerticle и container.undeployVerticle.

licensed under cc by-sa 3.0 with attribution.