Что скажете об архитектуре?

Question

[Владимир Грабко]

main -> вьюшка на js
http rpc -> там тупо прокси между http и tcp rpc (на основе fasthttp). Все остальные сервисы
работают по RpcTcp
auth service -> сервис отвечает за раюоту с учётками узеров. У него своя бд (auth db)
возвращает jwt
service all function -> там все функции которые по идеи не создают большой нагрузки. Как
только какая то функция из того сервиса отнимет 30% обращений к
сервису она будет перенесена в отдельный сервис.
battle service -> этот сервер просто знает на какой ноде создана комната (battle node)
battle bot -> Бот. Работает со всеми нодами.

chat * аналогичен battle части только вместо бота там авто модератор. Он модерит
публичные чаты автоматом (примитивный фильтр мата за который автоматом банит в
чате)

каждая нода имеет своё хранилище. А в all function для каждого модуля (какая то фича) тоже своя бд дабы в случае большой нагрузки я спокойно мог вынести всё это дело в отдельный сервис.

Бот и модератор маштабируются путём указания адресов к ним в конфигах ноды)

Answer 1

[lubezniy]

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

Comments

[Владимир Грабко]

к авторизации как раз минимальное количество запросов. jwt же.

Answer 2

[Максим Кудрявцев]

Как сказал lubezniy посмотри авторизацию. Ты пишешь про то, что к ней "минимальное количество запросов", ок, давай так считать, а ты учел вариант, что тебя кто-то брутить будет, что могут целенаправлено валить сервис авторизации? Авторизация легла - считай легло все остальное. Обрати на этот сервис доп.внимание. Продумай механизм возможного масштабирования, способы защиты от перегрузки/падения.

Далее ты пишешь, что у тебя chat & battle фактически одно и то же. Так у меня вопрос, зачем их тогда связывать с глобальными сервисами? Сделай общий тип room, который в зависимости от типа будет привязываться либо на chat либо на battle service.

Comments

[Владимир Грабко]

там разница в хранении данных (огромная). Разве что убрать сигнальный сервер чата и совместить его с сигнальным сервером battle, а ноды для чата одни, а для battle Другие. Но мне чёт не нравится это.

[Владимир Грабко]

как бы посоветовали маштабировать auth ?

Answer 3

[Gizmothron]

Вроде заумно сделано. Серьезно поработал.
Но нет явного горизонтального масштабированияю

UPD:
В комментариях обсудили всякие технические вопросы.

А вот по организации логики в мультиплеере
https://habrahabr.ru/post/302394/

Comments

[Владимир Грабко]

Вроде же есть. Размер нод не ограничен. Там два узких места сейчас. Авторизация и сигнальные сервера. Но что с этим делать я хз.

[Gizmothron]

Владимир Грабко: если у тебя было бы масштабирование, то была бы и оркестрация. не вижу.

[Gizmothron]

Владимир Грабко: и балансер.
у тебя какая балансировка - внешняя или внутренняя?

[Владимир Грабко]

Gizmothron: у меня 3 балансера. nginx на fasthttp проксю и сигнальные серверы для нод.

[Владимир Грабко]

Gizmothron: описание происходит в общем пакете который компилится в каждый из сервисов.

[Gizmothron]

На сколько физических серверов можно раскинуть вашу систему?
Как будет осуществляться синхронизация между этими физическими серверами?

[Gizmothron]

Нужна ли вообще жесткая синхронизация или её можно провести в отложенном режиме (как например делает mosh при использовании предикативного эха)

[Владимир Грабко]

Gizmothron: а управление не продумано.

[Gizmothron]

Владимир Грабко: а вдруг у вас один физический сервер будет вообще недоступен?
DDoS или просто блок питания из строя выше.
а что будет если сервер обратно вернется в строй. но пока он лежал он не синхронизировался с остальными. и что будет когда он вернется с устаревшими данными.

[Владимир Грабко]

Gizmothron: да сколько угодно. Сихронизации между нодами чата нет (у каждой своя бд) ну а между нодами battle псевдо синхронизация. Они хранят бой в озу, а по его завершению говорят сигнальному серверу о результате, а тот уже пишет в субд.

[Gizmothron]

Имхо:

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

Если же собираетесь масштабироваться на разные физические сервера, то задача синхронизации и управления между ними - это сложнейшая задача.

[Gizmothron]

И нужно сразу закладывать синхронизацию и оркестрацию.

[Gizmothron]

Владимир Грабко:
> Они хранят бой в озу, а по его завершению говорят сигнальному серверу о результате, а тот уже пишет в субд.

То есть бои индивидуальные? Игрокам не нужно знать о том, что делает другой, если он вдруг на другом сервере?

[Владимир Грабко]

Gizmothron: я не знаю что будет нужно. Я же не ванга что бы сказать что завтра у меня бдет 1м. играков которые уложат сервер. Верно?

[Владимир Грабко]

Gizmothron: сейчас для связи на 1 хосте я юзаю юникс сокет

[Gizmothron]

Владимир Грабко:
> Сихронизации между нодами чата нет (у каждой своя бд)

То есть каждая нода - это изолированный мир?
А зачем тогда вообще все эти сложности реализовывать, если все это не в одной куче работает синхронно?

Вполне достаточно отложенной синхронизации таблицы побед (скилов, прокачки персонажа), хоть раз в 15 минут.

[Владимир Грабко]

Gizmothron: а для управления я просто сделал систему которая знает все части сети (ноды). мониторит, логи собирает и я могу ними от туда управлять.

[Владимир Грабко]

Gizmothron: каждая нода изолированый мир. Верно. А с battle сделано так потому что после боя идут изменения профиля игрока. Каждые 15 минут не прокатывают.

[Владимир Грабко]

Gizmothron: там просто милиарды чат комнат (начиная от общих и заканчивая чатами в каждой комнате на battle ) При этом сам battle даже не знает что у него есть чат. Страница собирается в main на основе полученных данных от сигнальных серверов. А потом main напрямую общается с нодами.

[Gizmothron]

> я не знаю что будет нужно. Я же не ванга что бы сказать что завтра у меня бдет 1м. играков которые уложат сервер. Верно?
> Gizmothron: сейчас для связи на 1 хосте я юзаю юникс сокет

Если не закладывайте масштабирования, то нет нужды делать столько нод.
И программировать удобнее и эффективнее будет работать в одной ноде.
И балансеры не нужны.

А если же планируется расширение на множество серверов, то простая замена unix socket на TCP/IP не поможет. Придется в корне переделывать.

[Gizmothron]

Владимир Грабко:
> а для управления я просто сделал систему которая знает все части сети (ноды). мониторит, логи собирает и я могу ними от туда управлять.

Дело ваше. Но я бы взял готовый мониторинг Hashicorp Consul или Yandex Cocaine Runtime или Zookeeper или etcd.

[Владимир Грабко]

Gizmothron: я сечас на локальном сервере настроил куча виртуальных серверов и там тестирую всё это дело. Оверхед между сервисами не больше 23мс.

[Владимир Грабко]

Gizmothron: и вроде работает нормально. Завтра думаю написать бота который будет эмулировать действия пользователей и посмотреть как оно работает под нагрузкой в 2м. потоков (в инете дают физ. сервер на тест на 7 дней. Там и запущу бота. Вот и реальная связь )

[Gizmothron]

Владимир Грабко:
Ну с изолированными-то игровыми мирами и несрочной синхронизацией - все намного проще.
Я то думал - у вас общее игровое поле.

А раз так: то тогда это вообще все может быть одним единым сервисом.

[Gizmothron]

Владимир Грабко:
> я сечас на локальном сервере настроил куча виртуальных серверов и там тестирую всё это дело. Оверхед между сервисами не больше 23мс.

Не показатель.
Вы фактически меряете оверхед виртуальных машин.

[Владимир Грабко]

Gizmothron: игровое поле общее (оно синхронизируется с нодами Battle) так какигрок может быть только на 1 локации то по завершению боя я и синхронизирую всё в общим игровым полем (см. all func)

[Владимир Грабко]

Gizmothron: я меряю оверхед кода. А там если и буду маштабировать на разны физичиские сервера то между ними будет прямой канал без свичей в 1 цоде )

[Gizmothron]

Владимир Грабко:
То есть 1 нода = 1 локация?
Фактически игроки должны будут перемещаться между нодами, при перемещении по карте?

Тогда не масштабируемо. Единственная защита - что DDoS может вам затушить одну локацию, а другие в это время будут успешно работать.

[Владимир Грабко]

Gizmothron: так что я не думаю что показатель поднимтся больше 30м.с даже на разных физических.

[Gizmothron]

Владимир Грабко:
> А там если и буду маштабировать на разны физичиские сервера то между ними будет прямой канал без свичей в 1 цоде )

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

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

Впрочем у OVH и AWS есть какая то внутренняя виртуальная сеть за отдельные деньги.

Однако это далеко не бюджетно в суммы. Поэтому я бы предусмотрел сразу минимизацию трафика между серверами, чтобы между серверами можно было внешними каналами связи пользоваться.

[Gizmothron]

И локализация серверов, чтобы можно было играть в географически ближайшем - это далеко не то же самое, что внутри датацентра.

[Владимир Грабко]

Gizmothron: 1 сигнальный сервер == 1 локация. А ноды это то где проходят сражения

[Владимир Грабко]

Gizmothron: для этого же и сделана часть сигнальных серверов с общей бд. По сети gzip ходит.

[Gizmothron]

Владимир Грабко: общая БД - вашим средствами?
или репликация СУБД?

[Владимир Грабко]

Gizmothron: репликация mysql

[Gizmothron]

Владимир Грабко: Жесть. Это же трафик

[Владимир Грабко]

Gizmothron: а как ещё маштабировать mysql то?

[Gizmothron]

Владимир Грабко: репликация - это не масштабирование. скорее даже наборот.
репликация - это дюрабилити.

[Владимир Грабко]

Gizmothron: ну а что почитать по этому поводу?

[Gizmothron]

https://habrahabr.ru/company/mailru/blog/273695/
Шардинг

[Владимир Грабко]

Gizmothron: спасибо!