�ݺ�ߣ

Опыт использования Erlang
в разработке многопользовательской игры.
Юра Жлоба aka yzh44yzh

Многопоточность
Распределенность
Устойчивость к ошибкам
Горячее обновление кода
Кратенько про Erlang

Кратенько про нас

Кратенько про проект

А теперь переходим к сути :)
Многопоточность. Теория и практика.
Распределенность (только теория).
Устойчивость к ошибкам. Теория и практика.
Горячее обновление кода. Теория и практика.
Борьба за качество проекта.
Недостатки Erlang.
Выводы.

Многопоточность. Теория.
О, это оооочень сложно!
Мютексы там, семафоры всякие,
критические секции
“Java Concurrency in Practice”
нужно выучить назубок
А иначе страшные dead lock будут
преследовать вас в ночных кошмарах

Многопоточность бывает разная.
Бывает такая, которая простая :)

Легкие потоки
Эффективные планировщики
Изолированные области памяти
Изолированные сборщики мусора
Обмен сообщениями

Многопоточность. Практика.
Процессы – кирпичики архитектуры
Сотни и тысячи процессов в одном проекте

Сходство с ООП:
Инкапсуляция состояния
Публичные и приватные функции
Отправка сообщений вместо вызовов функций
Полиморфизм функций и модулей
Даже конструкторы и деструкторы есть
И даже фабрика :)

Dead lock, Race condition
Бывают, да. Но они не совсем не страшные.

Как выглядит эффективный сервер
если он написан не на Erlang?
(Ruby, Python, Node.js etc)

Например, так:
Несколько нод, по одной на каждое ядро
Rabbit MQ, чтобы наладить коммуникацию
Nginx на входе
Redis для in-memory кеширования

Все это заменяет одна нода на Erlang
Проще в разработке,
в развертывании,
в диагностике проблем,
в поддержке.

Решение высокого уровня
Сетевая прозрачность
Просто посылаем сообщение процессу в другой
ноде так же, как и процессу в своей ноде

Безопасность на куках
Доверенная зона, где все процессы
и все функции доступны

Но и собственное решение
с предоставлением внешнего АПИ
не запрещается делать :)

Устойчивость к ошибкам. Теория.
3 уровня защиты:
Изоляция потоков
Супервайзеры

Устойчивость к ошибкам. Практика.
Нет волшебной таблетки
От бага в бизнес-логике
никакой супервайзер не спасет
Нода не падает,
Но отказ в обслуживании ничем не лучше

Устойчивость к ошибкам. Практика.
Let it crash
или
try/catch, где надо

Горячее обновление кода. Теория.
Жизнь и смерть Erlang-процесса
Как изменить неизменяемое состояние?

Бесконечная рекурсия
Хвостовая, без накопления памяти на стеке

Аргументы функции и все переменные в ней неизменны
А состояние процесса меняется. Чудо :)

Горячая загрузка модуля меняет код его функций
Но состояние процесса остается прежним
В какой-то момент процесс покидает старую
функцию loop, и входит в новую функцию loop

В простом случае все просто
Но бывают сложные случаи :)

Изменилась структура данных
Изменилось дерево супервайзеров
Разное время обновления процессов

Горячее обновление кода. Практика.
Юзаем локально, в ходе разработки
Написал код, загрузил, поглядел как работает
Перезапускать сервер
при каждом изменении в коде – лишнее.

Выкатываем фичу в production
Потому что не хотим рестартовать сервер
Потому что там всегда есть игры,
которые прервутся

Имеем нестабильный production сервер
И пользователей в роли бета-тесторов
(и они не счастливы выполнять эту роль :)

Отдельный тестовый сервер
Нестабильные изменения выкатываем на него

Production сервер обновляем редко
Горячее обновление не получается
из-за “сложных случаев”
Обновление – это всегда рестарт

Сохранение состояний игр перед рестартом
Восстановление после рестарта

И что теперь?
Горячее обновление не нужно?

Ну можно выкатывать быстрые,
не опасные фичи, мелкие фиксы
Если не хочется ждать 2 недели
до конца спринта.

Но еще есть супер полезное применение ...

Диагностика проблем прямо в production
Создание новых средств диагностики
И внедрение их налету

Борьба за качество проекта
Тестировать сложно
И вручную, и автоматически
Оба варианта стоят времени и усилий

Хорошо иметь функцию без побочных эффектов
Написал юнит-тест
Проверил правильные, неправильные
и граничные входящие данные
И уверен, что функция всегда работает как надо

Вот бы весь проект состоял из чистых функций!
Но, черт возьми, повсюду полно побочных
эффектов. Кишмя кишат. Печаль :(

Побочные эффекты:
послали данные в сокет
записали чего-то в файл
вывели сообщение на консоль
сохранили данные в базу
запустили новый процесс
послали сообщение другому процессу

Страшная тайна программирования
Об этом не пишут в книгах ...

Страшная тайна программирования
Побочный эффект -- это смысл работы любой
программы, это и есть то полезное, что она делает.
Примите это :)

Тестируем работу с базой данных
К черту моки!
Будем тестировать работу с базой данных,
а не с моками!

Отдельная тестовая база
DROP TABLE, CREATE TABLE,
наполнение таблиц тестовыми данными
Перед каждым тестом

Тестируем функции,
которые реально читают из базы и пишут в базу
Да, это не быстро
Зато тестируем то, что надо :)

Тестируем взаимодействие процессов
В тестах подымаем дерево супервайзеров
Запускаем процессы
Заставляем их посылать сообщения друг другу

Творится синхронное и асинхронное невесть что
А тест должен это как-то проверять
(асинхронное сразу не проверишь, подождать надо)
Придумай, как проверять.
Ты ведь инженер, это твоя работа :)

Надеюсь, эти тесты не сильно
зависят от фазы луны :)
Мои худо-бедно работают,
и местами что-то проверяют

Более-менее нормальное покрытие тестами
стоит дорого.
А их еще поддерживать надо,
обновлять при изменениях в коде.

Большая компания наймет
отдельных людей для этого.
А что делать маленькой компании?
Нас всего трое, как тестировать?

Тестовый клиент
Отдельное консольное приложение
Умеет создавать десятки и сотни подключений
И через них дергать все АПИ сервера

Два режима работы:
Полу-ручной
Стресс-тест

Выявил и устранил проблемы в архитектуре
Нашел и оптимизировал узкие места
Пофиксил баги
Сплю спокойно :)

Недостатки Erlang
Малое количество разработчиков
Не является языком общего назначения
Динамическая типизация
Библиотеки третьих сторон
не production ready

Выводы
Будем ли мы применять Erlang
в следующих проектах?

Выводы
Однозначно да :)

�ݺ�ߣ

Опыт использования Erlang в разработке многопользовательской игры

More Related Content

Опыт использования Erlang в разработке многопользовательской игры