Опыт использования erlang в разработке...

Опыт использования 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 в разработке...

Technology