У меня есть многопользовательская игра, основанная на архитектуре микросервисов, которую я пытаюсь понять, как масштабировать по горизонтали .В настоящее время она организована в Docker Swarm, но я подумываю переехать в Kubernetes.
Вот подробности об игре:
- Это настольная игра с карточками
- Несколько игроков сидят за одним столом и играют друг с другом
Как это работает сейчас, у меня есть один контейнер, который отвечает за все столы.Когда игрок присоединяется к столу, он садится и устанавливает соединение через веб-сокет, которое направляется в этот конкретный контейнер.Все игроки на всех столах подключены к одному контейнеру.Логика игры и игровые события могут быть легко переданы всем клиентам.
Это сейчас так. Все клиенты, которые сидят за одним столом, подключены к одному и тому же контейнеру , поэтому легко перемещать динамические игровые данные взад и вперед.
Client 1+
| Container A +Client 3
| +---------------+ |
+---> |---------------| <----+
|| Table 1 || |Client 4
Client 2+----> |---------------| <----+
|---------------|
|| Table 2 ||
|---------------|
|---------------|
|| Table 3 ||
+---------------+
| . |
| . |
| . |
+---------------+
Однако при попытке масштабированияэто просто увеличивает число контейнеров, с которыми вы сталкиваетесь, когда клиенты, сидящие за одним столом, подключены к разным контейнерам.Это означает, что каждое игровое действие и все общие динамические игровые данные должны обновляться в базе данных, расположенной между этими контейнерами.Однако это становится все труднее писать и поддерживать:
Container 1 Container 2
Client 1+ +-------------+ +-------------+ +Client 3
+----> |-------------| |-------------| <------+
|| Table 1 || || Table 1 ||
+----> |-------------| |-------------| <------+Client 4
Cleint 2+ |-------------| |-------------|
|| Table 2 || || Table 2 ||
+-------------+ +-------------+
| | | |
| | | |
| | | |
+----+--------+ +-----------+-+
| |
| |
| |
| +------------------------+ |
+> | Redis DB | <+
+------------------------+
Вместо того, чтобы проектировать подобные компоненты, было бы намного проще каким-то образом направить клиентов, которые должны сидеть на одной таблице, в один и тот же контейнер.Это сделано для того, чтобы не записывать каждое действие игрока и каждое обновление публичной таблицы в БД.Это выглядело бы так:
Game Service
+-----------------+
Client 1+ | | + Client 3
| | Container 1 | |
+------> +-----------+ <-------+
| |-----------| |
Client 2 +-----> || Table 1 || <-------+ Client 4
| |-----------| |
| |-----------| |
| || Table 2 || |
| |-----------| |
| +-----------+ |
| |
| Container 2 |
| +-----------+ |
| |-----------| |
| || Table 3 || |
| |-----------| |
| |-----------| |
| || Table 4 || |
| |-----------| |
| +-----------+ |
| |
+-----------------+
Наличие вышеупомянутой архитектуры значительно уменьшило бы сложность приложения.Проблема в том, что соединения, приходящие от разных клиентов, должны быть идентифицированы и направлены в правильный контейнер .Я не нашел способ сделать это.Возможна ли маршрутизация к конкретным контейнерам в службе и каким инструментом?
Какой правильный подход использовать в моем сценарии?Кроме того, если ручная маршрутизация запросов к целевому контейнеру не является приемлемой опцией, каков будет правильный способ создания этой службы?