Rails, Eventmachine, Erlang

3,452 views

Published on

Published in: Technology
3 Comments
12 Likes
Statistics
Notes
No Downloads
Views
Total views
3,452
On SlideShare
0
From Embeds
0
Number of Embeds
55
Actions
Shares
0
Downloads
42
Comments
3
Likes
12
Embeds 0
No embeds

No notes for slide

Rails, Eventmachine, Erlang

  1. 1. Эволюция: Rails, Eventmachine, Erlang Макс Лапшин max@maxidoors.ruSunday, December 16, 12
  2. 2. Программы древности • Написаны на С • Запутанная логика • Огромная сложность программированияSunday, December 16, 12
  3. 3. Программы древности • Данные хранятся в памяти • Ручная сериализация на диск • Сложные протоколы IPCSunday, December 16, 12
  4. 4. Программы древностиSunday, December 16, 12
  5. 5. PHP • Запрос-ответ • Программа живет одну секунду • Share nothing • Персистентность внешняя • Нулевой контроль за ресурсами • Естественный контроль за overloadSunday, December 16, 12
  6. 6. PHPSunday, December 16, 12
  7. 7. Rails • Идея PHP в совершенстве • Лучший инструмент для сайтов • Лучший выбор для Web 1.5Sunday, December 16, 12
  8. 8. RailsSunday, December 16, 12
  9. 9. Web меняется • Веб становится динамичным • Хватит перезагружать страницу • Ajax в рельсах реализован прекрасноSunday, December 16, 12
  10. 10. Web меняется • Веб становится интерактивным • Страница меняется сама! • Беда!Sunday, December 16, 12
  11. 11. Web меняетсяSunday, December 16, 12
  12. 12. Интерактивный веб в Rails • Меняется источник активности • Теперь опять сервер инициирует поток данных • Старые концепции опять не годятся • Comet, WebSockets, ServerSentEvents — рельсы это не могутSunday, December 16, 12
  13. 13. Проблемы • Подключенные клиенты • Возникает стейт в памяти • Проблемы обработки ошибок • Архитектурная непригодность для решения проблемSunday, December 16, 12
  14. 14. Rails • Организованы жестко по принципу запрос-ответ • Огромный расход памяти на каждого клиента • Один запрос — один инстанс • Только для коротких запросовSunday, December 16, 12
  15. 15. Типичная архитектура online-игры на Rails • Rails • Comet сервер • СУБД • Сотни лишних запросов к БД • Постоянная (де)сериализация и синхронизацияSunday, December 16, 12
  16. 16. Fail!Sunday, December 16, 12
  17. 17. Eventmachine • Решает проблемы с подключением клиентов • Держит стейт в памяти • В сотни раз сокращает трафик к БДSunday, December 16, 12
  18. 18. Online игра на Eventmachine • Стейт игры держится в памяти • Пользователи подключаются к одному серверу • Команды передаются внутри Ruby VM • Запись в БД только из игрыSunday, December 16, 12
  19. 19. Eventmachine • Сохраняется вся экосистема Rails • Можно прибить гвоздями асинхронную БД • Расшаренный код с Rails-приложениемSunday, December 16, 12
  20. 20. Win?!Sunday, December 16, 12
  21. 21. Eventmachine • Страдает реализация (нелепые баги) • Callbacks hell • Как жить с ошибками? • Учет ресурсов • Контроль перегрузки • Репликация и failoverSunday, December 16, 12
  22. 22. CallbacksSunday, December 16, 12
  23. 23. Fibers • Спасают • Глючат • Но спасают • Ещё сложнее, чем коллбекиSunday, December 16, 12
  24. 24. Обработка ошибок • Ошибки происходят • Баги в коде • Неожиданные входные данные • Все ошибки не убратьSunday, December 16, 12
  25. 25. Обработка ошибок • Как обрабатывать? • Как не повалить весь сервер? • Какие данные разрушаются от одной ошибки? • Как не превратить код в сплошную обработку ошибок?Sunday, December 16, 12
  26. 26. Обработка ошибок • В Ruby ошибка привязана к потоку выполнения • Объекты живут отдельно от потоков • Это ключевая проблема почти для всех языков • Надо связывать объекты и ошибки руками, делая новые ошибкиSunday, December 16, 12
  27. 27. Утечки памяти • В Ruby сотни утечек • Данные не группируются по объектам предметной области • Утекла, так утекла. Ребутнем потом.Sunday, December 16, 12
  28. 28. Fail!Sunday, December 16, 12
  29. 29. Контроль за нагрузкой • Как не дать сервису упасть под нагрузкой? • Как правильно отказать новым клиентам? • Как не навредить старым клиентам?Sunday, December 16, 12
  30. 30. Контроль за нагрузкойSunday, December 16, 12
  31. 31. Контроль за нагрузкой • Бесконтрольно принимаем клиентов • Начинаем тормозить всех • Все получают таймаут от фронт-прокси, делают retry • В системе удваивается количество работыSunday, December 16, 12
  32. 32. Контроль за нагрузкойSunday, December 16, 12
  33. 33. Контроль за нагрузкой • Требуется backpush в каждом компоненте системы • Важно не дать затыку пролезть вглубь системы • Для этого нужен адекватный контроль загрузки • Торможение клиента и отказ на ранней стадии • Требуется удобная сборка данных по состоянию клиентовSunday, December 16, 12
  34. 34. Репликация и failover • У вас только один Comet-сервер? • Как пережить его падение? • Репликация по сети — только руками.Sunday, December 16, 12
  35. 35. Fail!Sunday, December 16, 12
  36. 36. Erlang • Построен вокруг изоляции ошибок • Обработка клиентов строго изолирована и группирована • Все ресурсы строго разграничены • Обработка клиентов прогнозируема • Прозрачная сетевая кластеризацияSunday, December 16, 12
  37. 37. Процессы в Erlang • Вся логика изолирована в независимых процессах • Коммуникация только обменом сообщений • Данные только внутри процессов • Их могут быть миллионыSunday, December 16, 12
  38. 38. Процессы в Erlang • Процессы чертовски удобны! • Ими проще моделировать предметную область • Они совпадают с теми квадратиками на флипчарте • Проще проектировать в таких терминахSunday, December 16, 12
  39. 39. Ошибки • Любая ошибка привязана к процессу • Самое частое поведение — упасть процессу по ошибке • Не тратишь время на обработку ошибок • Система устойчива к нерегулярным сбоямSunday, December 16, 12
  40. 40. Ресурсы • Все ресурсы строго изолированы • Со смертью процесса всё освобождается, включая файлы и сокеты • Консоль прям внутри работающей системы • Элементарный поиск потребителя памяти • Утечки — вообще не проблемаSunday, December 16, 12
  41. 41. Ресурсы • Год аптайма — не проблемаSunday, December 16, 12
  42. 42. Контроль нагрузки • Синхронные call-ы сообщениями сдерживают нагрузку • Длина очереди процесса — прекрасная метрика • Можно интроспектить загрузки процессов • Гораздо проще вовремя отказатьSunday, December 16, 12
  43. 43. Кластеризация • Адресация процессов доступна по сети • Механизмы для глобальной адресации процессов в кластере • Надо быть аккуратным, что бы не положить каналSunday, December 16, 12
  44. 44. Win!Sunday, December 16, 12
  45. 45. Win?Sunday, December 16, 12
  46. 46. Проблемы Erlang • Говорливый синтаксис после Ruby • Неудобная работа со строками (много текста), но есть серьезные фичи для скорости (iolists) • Нет и не планируется удобного ORM типа ActiveRecord • Зато можно хранить данные в памяти. Пользуйтесь этим!Sunday, December 16, 12
  47. 47. С чего начать? • “Erlang Programming” by Francesco Cesarini • http://learnyousomeerlang.com by Fred • http://groups.google.com/group/erlang-programming • http://groups.google.com/group/erlang-russianSunday, December 16, 12
  48. 48. Что будет полезно? • ChicagoBoss — веб-фреймворк а-ля Rails 0.5 • https://github.com/doubleyou/dps Распределенный Comet серверSunday, December 16, 12
  49. 49. Итого • Rails — чудесный инструмент для сайтов • Rails становится непригоден для интерактивного веба • Eventmachine хороший мостик в новый веб • В Eventmachine есть нерешаемые проблемы • Erlang их чудесно решает. Написали и забыли.Sunday, December 16, 12
  50. 50. Вопросы? Макс Лапшин max@maxidoors.ru http://levgem.livejournal.comSunday, December 16, 12

×