Архитектура MMO сервера
 

Есть желание попробовать написать ММО клиент-сервер и хотелось бы начать с правильной архитектуры. Есть ли у кого опыт в таких делах?

Пока выделил следующие составляющие (деление на сервера):
1. Авторизация, лодбалансер, бизнес логика
2. Сервера зон/комнат
3. База данных

Как-то так:


Основной вопрос состоит в правильной структуре каждого из серверов. Тут пока опыта почти нет. Хотелось бы услышать мнение об этом у участников сообщества.

Ответ: Архитектура MMO сервера
 

Ответ: Архитектура MMO сервера
 

pax
у меня есть некий опыт написания серверов которые работают, потому расскажу всякое

сначала по терминам
PCU - Peak Concurrent user, грубо говоря сколько сокетов переварит ваш сервак
RPS - Requests Per Second, если обработка не упирается в цпу то это bandwidth/packet_size, при пакете в 5 кб и канале 100 мбит, RPS будет 2.5k (тысяч ! не миллионов)

1) собсно PCU это грубо говоря сколько сокетов может держать ОС, линукс сразу идет НАХ*Й, ибо говно там в сетевом стеке, берем FreeBSD, на всяких ерлангах одна машина (12 ядер, 128 гб рамы) тянет 2kk PCU

2) внизу сервер БД, замечательная штука да, а теперь представим что сверху у нас 100500 серверов, одновременно пытается играть 5 млн юзеров, везде что-то двигается, такая байда может нагенерить трафика на бд в районе 200-400 гб\s, можно конечно взять один йоба сервак, вставить туда 64 ядра, 512-1024 гб рамы и пидорасить тупо 10 ethernet карт по 40 гб\с, но это не выход =) а каналов по 400 гб\с щас ни у кого толком нету

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

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

для такой цели я рекомендовал бы большинство серверов ставить NoSQL, например MongoDB, и делать там реплики по 3 сервера и обязательно покупать реалтайм бекап (http://www.mongodb.com/press/10gen-a...backup-service мы этот юзаем, он бекапит журнал и потом можно восстановить любую точку во времени), но некоторые (статистика точно) должны быть SQL ибо к ним идут пидорские запросы наподобие "а дай мне топ 10 юзеров" который NoSQL не переваривает

3) авторизация и лобби, они ОЧЕНЬ топорные на логике, по-сути логики там нету, там даже не нужно постоянное подключение, это просто REST API, а если так то юзаем мощный веб-сервер, например Mongrel2 или NGINX, надо отдать должное этим монстрам и на среднем серваке они займут канал 10 гб\с полностью с всего ~10-25% CPU

думаю тут описывать сильно не надо, код авторизации тупо является посредником между веб сервером и бд, лучше всего его написать на C и вшить прямо в код веб сервера (в то место где он CGI делает)

делать балансер тут вообще нету смысла, разве что у тебя будет ОТДЕЛЬНАЯ СТОЙКА И ОТДЕЛЬНЫЙ СВИТЧ на это, единственный тип балансировки который взлетает на highload - ethernet balancing, то есть у нас N серваков у которых по две сетевые карты, одни карты торчат аплинком в мир, вторые карты торчат тупо в один лоу-латенси свитч, в этот свитч торчат все обработчики запросов, обработчики запросов тоже имеют по две карты (одна в свитч, другая аплинк), и когда на балансер приходит ip пакет с запросом то он у него меняет ethernet адресс ! таким образом наш чудо свитч по матрице комутации перекидывает пакет очень быстро, с помощью round-robin можно так забалансировать очень много трафика

4) сервера комнат, думаю надо банально ставить монстро-серваки по много ядер и много рамы, клиенты будут с ними конектится постоянно, потому тут всё зависит от контекста использования - ведь игровая логика бывает разная, всяким MMORPG надо коллизии считать например

этим серверам нужно кешировать состояния мира чтобы не лазить в бд иначе слишком сильно увеличится латентность обработки запросов

верх эволюции это горизонтальное масштабирование в рамках одной комнаты, но я такого не видел, например в EVE Online у них по серверу на звёздную систему, если в какой системе будет происходить бой то они вытягивают сервер помощнее из пула и запускают на нем эту систему

думаю можно это отдельно обсудить если скажешь какой жанр игр нужно =)

Ответ: Архитектура MMO сервера
 

Я сейчас изучаю эту тему. Сделал простенький сервер на node.js + socket.io
Клиент Unity3D + UnitySocketIO

А вообще для MMO есть готовое решение на node.js Pomelo framework (схемы архитектуры)

В Pomelo не вникал, показалось сложно.

Ответ: Архитектура MMO сервера
 

Данных, которые нужно сохранять периодически в БД на самом деле не так и много- покупка чего то там, левел ап, шмот. Все остальные данные в реалтайме можно держать в комнате на аватаре игрока, и писать в бд при дисконнекте. http://habrahabr.ru/company/mailru/blog/182088/ тут интересно написано. socket.io юзает веб сокеты, как то не тру. Pomelo удобоваримо только для сессионных игр.

Ответ: Архитектура MMO сервера
 

Если использовать node.js для серверной логики, то тут есть плюсы и минусы. Плюсы начнём с того что это лёгкость в модифицируемости и скорость разработки - минусы, конечно C++ с правильными руками будет намного мощнее.
Но критические зоны, например коллизия и математика без проблем может быть вынесена в C++ Addon'ы (модули) для node.js, что также можно делать позже (но не слишком).

Относительно сетевого трафика, тут по любому нужно писать свой сериализатор а не использовать тот же socket.io, т.к. унаследуешь кучу проблем от него, которые например Unity вообще не упали. Плюс если писать свой протокол, то можно нормально стримы заюзать от TCP, а не пакетно обрабатывать всё.
Парсер снова, может быть вынесен на C++, и там уже генерить V8 объекты (JSON), которому node.js будет рад.
Есть вот такой протокол, очень многообещающий: http://kentonv.github.io/capnproto/

Также очень зависит от архитектуры твоего игрового сервера.
"ММО, МООшке рознь". Ты упомянул комнаты/зоны, речь идёт о разбиении мира на зоны (как в давние времена в WoW с предзагрузкой при переходах), или как в EVE, или речь идёт о матчах, как в LoL / Dota 2 / BF3 и т.п. играх?

БД, как jimon сказал нужно качественно кластерить и иметь возможность восстановления реплик.
БД использовать для редко нужных данных и периодическом сохранении данных, необходимых для восстановления игрового состояния.
Большинство данных должно держаться в раме и там же оперироваться игровыми серверами, периодически паралельно сохраняя то что нужно в бд.
Если сервера должны обмениваться данными между собой (сервера в плане процессов), то заводи redis, т.к. он очень эффективен для реалтайм быстрых транспортов. Redis - это реалтайм хранилище, подобно простой бд с разными плюшками.

Если тебе нужно общаться между серверами напрямую - например lobby сервер может поискать игровые сервера, и если lobby имеет приоритет на игровыми, попросить игровой сервер на создание игровой комнаты. В подобной ситуации тебе нужно напрямую общаться между серверами.
Тут я бы посоветовал ZeroMQ, он и прост и сложен. Просто для старта, и сложность заключается не в самой либе, а возможностях для сложных архитектурных решений коммуникации между процессами.

Даже логин сервер - должен скейлиться.
Авторизация - это побочный процесс, как addon в процессе, его задача получить данные логина, авторизировать/отклонить, и закинуть данные сессии в redis чтобы другие сервера/процессы могли получить эти данные, также сообщить запрашивающему процессу о статусе авторизации.

Я бы также совмещал RESTful с Real-Time. Большинство должно быть как раз RESTful до игры, а сама игра Real-Time.


Отличная практика для развития в этой сфере - это анализ существующих игр и их архитектуры.
Вот список рекомендуемых примеров: EVE; FireFall; Dota 2 / LoL; BF3.
Каждый из этих примеров утилизирует REST и RT везде. Что-то на REST'е, что-то на RT (realtime).

Ответ: Архитектура MMO сервера
 

Спасибо отписавшимся, я пока не преследую планы по глобальному завоеванию мира, поэтому мои запросы примерно такие:

1. Допустим 5к игроков одновременно максимум.
2. Игровой мир это комнаты с загрузкой, не единый мир.
3. Сессии не длинные, по трафику допустим это шутер с числом игроков в комнате не превышающим 50-100 (в большинстве случаев будет меньше).
4. Основной геймплей - бои длительностью до 20-30 минут (к примеру WoT).

Ответ: Архитектура MMO сервера
 

шутер ? на 100 человек ? имхо слишком сложно :crazy: ты думаешь не о том, всякая бд, авторизация и прочее для 5к PCU можно тупо на php на VDS поднять за 20$\мес и взлетит, а вот сервер ... я бы сказал что для 100 человек это невозможно даже, 20 человек территориально ограничено - более реально, по крайней мере нужно будет раскидывать серваки по всем частям мира чтобы для локальных юзеров был меньший пинг

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

всякие сетевые танки и самолетики куда проще делать ибо там игрок не меняет положение в пространстве очень резко

Ответ: Архитектура MMO сервера
 

Для каких целей?

Ответ: Архитектура MMO сервера
 

Шутер я предположил по трафику, шутер я писать не буду. Я уже на проекте с роботами понял что синхронизация topdown шутера очень сложная. Надо делать всякие обманы чтобы выглядело нормально. Допустим это космосим (опять же к примеру) и летать надо не на истребителях, а на более тяжелых кораблях.

Я думаю для точного расчета попаданий. В статье про сеть в Source это описано.

Ответ: Архитектура MMO сервера
 

pax
ну реально, если тебе хватит латентности в 200-500 мс для космосима типа EVE, то вполне можно напедалить простенький сервер на 100 человек на банальном C и сокетах, это ни какой либо rocket science уже, думаю 1 средний дедик потянет всех твоих 5к игроков (50 комнат)

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

так делают в большинстве MMO где не требуется моментальная реакция на перемещение игрока

Ответ: Архитектура MMO сервера
 

Latency критичен только в играх где есть прямое взаимодействие между игроками - шутеры, топ-даун и т.п.
А игры с например целями Lineage, EVE и т.п. Latency не так критичен. Там даже можно иметь интерполяцию заместо экстраполяции, если нету никаких действий между игроками с элементами реакции, где от скорости реакции зависит прогресс игроков.

Если это комнаты, то нужно думать над развёрткой серверов в разных регионах (дата-центрах), и обслуживать эти регионы по отдельности (по стандарту) с возможностью и на глобальных сервах играть.

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

Следственно изначально, либо без режимов игры и учёта рейтинга, и вообще на одном сервере, а потом если поднимается число пользователей, добавлять регионы и уже по стандарту обслуживать игроков с этих регионов. Так будет ниже Latency и игроки довольны будут.

Либо сделать комнаты, в которые тупо можно присоединяться, заместо матчей где требуется набор игроков до начала игры.
Но это зависит от гейм-дизайна, контра например такое позволяет, а вот LoL или Dota 2 или стратежки - уже нет.

Ответ: Архитектура MMO сервера
 

Еще появилось два вопроса (не совсем связанных с mmo):

1. TCP пакеты доходят медленно. При пинге 32 мс пакеты доходят за ~270мс. Это так и должно быть или в коде вероятно проблемы? На локалхосте пакеты доходят за 5 мс.

2. Есть ли где статьи по реализации reliable udp? Есть желание попробовать написать такой протокол самому.

Ответ: Архитектура MMO сервера
 

pax

1) не должно быть, разве что у тебя 50+% потерь пакетов, может ты просто буфер не флашишь чтобы ОС сразу отправляла пакеты ?

2) есть разные готовые реализации, посмотри на гитхаб к примеру https://github.com/search?q=reliabil...al&ref=cmdform

Ответ: Архитектура MMO сервера
 

Есть ещё вариант с плохой сетью в которой пропадают пакеты, тогда пинг будет расти, из-за повторной отправки пропавших пакетов.