Микросервисная архитектура для онлайн игр. Проблема асинхронности?
Решил переделать сервер своей игры из монолита в микросервисы. Пишу на nodejs связь, связь между сервисами nanomsg. Решил начать с того что выделить в отдельный сервис Ботов и всю их логику передвижения, состояния. Примерно ботов около 10000.
Раньше было так, что для каждого пользователя ищутся ближайшие боты и отправляются ему их координаты, в пределах одного сервиса это не составляет проблем, при микросервисном подходе координаты ботов будут приходить асинхронно и теряться. Как в такой ситуации лучше подступить? Возможно кто то сталкивался? Буду благодарен за любой совет или ссылку на статью.
Мало информации о том, что есть и чего хочется. Но в целом, микросервисы не предполагают асинхронности по умолчанию. Но даже с ней вроде всё выглядит легко:
1. Поднимаем сервис регистрации ботов на базе любого сервера очередей
2. Пользователи подписываются на сообщения о появления бота в их округе
3. Боты отправляют свои координаты на сервис, не дожидаясь ответа (он в принципе и не нужен)
4. Сервис уведомляет пользователей об интересующих их ботах.
Вы же под ботами понимаете какую-то систему принятия решений, так?
Если так - то это просто один из компонентов системы, связанный с другими через ивенты. А ивенты уже можно пробрасывать асинхронно через шину сообщений. У вас будет просто диспатчер ивентов который может раскидывать оные по процессам. Проблема будет только в синхронизации состояний но это решаемо.
Да под ботами понимается система принятия решений. Каждый тик это система прогоняет массив ботов и в зависимости от состояния каждого принимает различные решения.
На основном сервере каждые 50 мс для пользователя отправляется сообщение в котором содержатся координаты ближайших ботов, так как мир не ограничен их в массиве может быть 10 000 и более.
Получается что мне нужно хоронить массив всех ботов и в основном сервисе и в сервисе ботов, но передовать в основной сервис только изменения . А выборку ближайших тоже осуществлять на основном сервисе?
iid0001: можно промежуточное состояние хранить в redis например. То есть у нас один сервис обсчитывает состояние ботов а другой сервис просто забирает состояние ближайших. У редиса есть возможность в качестке клюей использовать геохэши, за счет чего можно оптимизировать выборки по координатам. Но надо думать.
Вообще не факт что это даст профит, тут все сильно зависит от того как это можно разделить. Я бы подумал о том как все это ложится на ECS (Entity Component System) и можно ли поделить каждый компонент на отдельный процесс и как следствие - повыносить все это добро.
Для игр все чуть сложнее чем для обычных приложений.
Простой
