Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

Допустим у нас есть два варианта.

• погибнут все люди, кроме 1000 человек. Это 7 миллиардов смертей.
• погибнут последние 1000 человек. Это всего 1000 смертей.

Что хуже? Если хоть чуть-чуть подумать, то второй вариант намного хуже. Почему? Ну, вымрет человечество и что с того? Not a big deal. Проблема не в этом, а проблема в том, что если погибнут последние 1000 человек, то мы потеряем триллионы и триллионы жизней, которые могли бы рождаться и жить начиная с сегодняшнего дня и кончая тепловой смертью Вселенной. Останется не исследованной и не заселённой наша Солнечная система, Млечный Путь, Суперкластер Вирго и вообще вся Вселенная.

Когда говорят про разработку игр, обычно речь идет о шейдерах, графике, AI и т.д. Крайне редко затрагивается серверная часть игровых проектов, а ещё реже — базы данных. Исправим это досадное недоразумение: сегодня я расскажу о нашем опыте работы с базами данных, который мы приобрели в ходе разработки Аллодов Онлайн и нашего нового проекта Skyforge. Обе эти игры — клиентские MMORPG. В первой зарегистрировано несколько миллионов игроков. Вторая разрабатывается студией в строжайшей секретности в недрах Allods Team.

Меня зовут Андрей Фролов. Я ведущий программист Allods Team и работаю в команде сервера. Мой опыт разработки — почти 10 лет, но в игры я попал только в октябре 2009. В коллективе я уже больше трёх лет, с марта 2010. Начинал работу на Аллодах Онлайн, а сейчас на Skyforge. Занимаюсь всем, что так или иначе связано с сервером Skyforge и базами данных. В этой статье я расскажу о базах данных в онлайн-играх на примере Аллодов и Skyforge.

Некоторое время назад я попал в геймдев, где столкнулся с проектами по 2 млн. строк кода, которые пишут десятки программистов. При таких масштабах кодобазы возникают проблемы неведомого мне ранее характера. Об одной и них я хочу вам сейчас рассказать.

Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.

Примеры из практики, как моей, так и моих коллег:

• Переделать всю работу с базой данных с чистого JDBC на Hibernate.
• Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
• Полностью переписать подсистему трансляции XML файлов в рантайм объекты.

Что делать? С какой стороны подойти к проблеме? Ниже представлен набор советов и практик, которые нам помогают справиться с этой проблемой. Сначала более общие слова, а потом конкретные методики. В общем-то ничего сверхъествественного, но кому-то может помочь.