Оригинал статьи: smyck.net/2012/04/22/why-erlang
Шансы, что вы читаете эту статью на устройстве с многоядерным процесcором, растут каждый день, вот почему все постоянно говорят про параллелизм (concurrency). Параллелизм для наших web приложений и API бэкендов, это когда вывод htop выглядит примерно как на картинке:
Я недавно был на великолепной Ruby конференции и три или четыре доклада были про параллелизм. Сообщество Ruby достаточно открыто и обсуждалось достаточно много возможностей: использовать потоки, использовать различные среды выполнения Ruby, чтобы обойти GIL, использовать больше процессоров, использовать модель акторов через библиотеки как Celluloid или даже использовать Akka через JRuby.
В то время как модель акторов, кажется, хорошо подходит для создания сетевых параллельных приложений, которые часто страдает от проблем, если среда выполнения, на которой реализовано приложение не имеет нативной поддержки. Существуют реализации для Ruby, Python и Java, но все они должны подстраиваться, чтобы достичь нормальной работы и не обязательно результат даёт наилучшую производительность. Это одна из многих причин, почему Erlang был бы намного лучшим выбором, но сначала, давайте немного уделим время модели акторов, чтобы понять, почему это так хорошо работает.
Вот неплохая цитата из wikipedia, для поверхностного понимания:
Несмотря на некоторое сходство между актороми и объектами, такими как: модулярность, инкапсуляция и возможность отправки сообщений; акторы имеют уникальную особенность — они могут выполнять свою работу в одно и тоже время.
Другими словами, отправка сообщений, чтобы делиться состоянием с другими актороми, работает параллельно допуская асинхронное взаимодействие, это означает, что отправителю не обязательно ждать ответа от получателя.
Другое большое отличие от мира ООП это то, что модель акторов не имеет глобального состояния и по-этому не разделяют общую память между актороми. В языках, таких как: Java, Ruby и Python всегда используется глобальное состояние и нити имеют доступ к общей памяти. Это обстоятельство часто становится проблемой в виде блокировок или гонок состояний и возможно является наибольшим неудобством
В модели акторов каждый актор имеет своё собственное внутренние состояние, который раздаётся только через сообщения. Таким образом актор действует в качестве сериализатора для доступа к своему состоянию, тем самым эффективно избегают блокировки и состояний гонки.
Необходимо так же отметить, что модель акторов очень хорошо подходит для функциональных языков программирования с концепцией неизменяемых данных (Immutable Data).
Есть много, что можно почитать про акторы, но я бы отметил наиболее важную вещь, которую необходимо знать. В общем случае, модель акторов позволяет разрабатывать параллельные приложения намного проще и быстрее.
Сперва я бы хотел сказать, что много лет я был страстным Ruby разработчиком. Мне действительно очень нравится этот язык и его сообщество. Но время от времени я чувствовал, что преодолеваю невидимые стены, когда дело доходит до сетевых приложений, веб приложений, веб серверов, прокси и т. д. То есть все те приложения, которые обрабатывают множественные запросы и/или выполняют не тривиальные задачи.
Erlang попал в поле моего зрения достаточно давно, но с высоты моей башни из слоновой кости и рубиновой крышой потребовалось много попыток, чтобы понять, что его стоит попробовать. Концептуально это имеет большое значение для меня и я уверен, что большенство людей читавшие про Erlang, согласятся со мной. Должен признаться, что был потрясён синтаксисом языка и это останавливало меня
от желания попробовать этот язык. Думаю, это было большой ошибкой, которая и мотивировала меня написать эту статью, сказать вам, что вы должны попробовать Erlang как можно быстрее.
Сначала позвольте дать описание Erlang в одну строку:
«Erlang — функциональный язык, реализованный на модели акторов для параллельных приложений.»
Этот язык был разработан компанией Ericsson для своих телекоммуникационных свитчей и целью было создать язык, который позволил бы разрабатывать отказоустойчивые и параллельные системы с высокой доступностью.
Вы можете почитать обо всём на wikipedia или великолепном сайте: learnyousomeerlang.com — Эти ребята сделали отличную работу описав язык.
Эта статья своеобразный толчок, я хочу побудить вас попробовать Erlang и буду стараться делать это рассказывая историю применения Erlang в Wooga.
Wooga делает социальные игры с миллионами активных игроков в день. Игры постоянно сообщают серверам изменить и удерживать состояние участников игры. Некоторые из наших игр были разработаны на Ruby и они работают неплохо. Ruby, как я уже говорил, действительно хороший язык и хотя не самый быстрый, но он может быть достаточно производительным, если вы знаете что делаете.
Наша самая большая игра, по числу пользователей, со сложной внутренней логикой, работает на серверах количеством от 80 и до 200. Они обрабатывают около 5000-7000 запросов каждую секунду и почти все запросы изменяют состояние игрока в самой игре. Должен отметить, хотя количество серверов и сохраняется в разумных пределах в момент пиковых нагрузок, но цифра, конечно же, не самая впечатляющая.
Когда пришло время создать новую игру со схожей логикой и сложностью, на этот раз мой коллега Paolo решил выбрать Erlang, он думал это будет правильным выбором. Мы наняли опытного разработчика на Erlang (Knut) и они вместе реализовали логику. Сейчас эта игра имеет около 50% игроков от остальных игр и количество серверов, необходимых обслуживать её, равно 1!..
Игра обслуживается двумя или тремя серверами для некоторой избыточности, но она может вполне идеально работать и на одном. Даже если игре действительно потребуется четыре сервера, всё равно это будет намного эффективнее и производительней, чем другие игры.
Конечно же они уже знали обо всех ошибках, сделаных в предыдущих играх и это не только отсутствие Erlang, это и помогло достичь такого прироста в производительности и способствовало в реализации логики, достигнуть поставленной цели было действительно легче с помощью модели акторов.
Говоря другим языком, они создали веб сервер для хранения состояния игроков, это значит, что каждый игрок, который ирает в данный момент, обслуживается отдельным актором внутри Erlang VM. Игрок, начиная игру, порождает актор с его состоянием. Последующие запросы, пока он играет, идут напрямую к актору, с которым он связан. Соответственно, пока состояние игры хранится в памяти, при этом исключаются любые обращения к базе, запросы обрабатываются и отвечают очень быстро.
Если актор падает, остальные акторы остаются «живыми» так как нет общего / глобального состояния. Когда игрок прекращает игру, актор сохраняет состояние игрока в постоянном хранилище и сборщик мусора (GC) удалит его из памяти. В тоже время, как мы помним, данные в Erlang не изменяются, что позволяет вернуть состояние игрока пока не произошли изменения и не пошло что либо не так.
Это действительно восхитительно и я могу рассказать намного больше. К счастью, Knut и Paolo рассказывали на нескольких конференциях про наш опыт и выложили свои слайды в открытый доступ. Вы можете просмотреть их по ссылкам:
* www.slideshare.net/wooga/erlang-factory-sanfran
* www.slideshare.net/hungryblank/getting-real-with-erlang
После того, как Paolo и Knut заразили вирусом Erlang всю компанию, мы сделали новую игру на Erlang и несколько дополнительных сервисов. Могу подтвердить, что чем больше ты изучаешь Erlang, тем больше понимаешь как делать правильно. Это заставляет меня немного сожалеть о тех, кто на конференциях Ruby боролись с различными библиотеками, чтобы можно было легко разрабатывать параллельные приложения, что обеспечивает Erlang в одном пакете. Пакет, который используется уже более 20 лет.
Трудная часть в изучении нового языка, это найти небольшой проект и принять в нём участие. Изучать, просто читая книги, всегда медленно и когда приступаешь к написанию кода, большая часть прочитанного забывается. Так же, странный синтаксис (сейчас я не считаю его странным), был для меня непреодолимой преградой, чтобы начать использовать Erlang в реальном проекте. По этому рекомендую выбрать небольшой проект и «поиграться» с Erlang. Думаю вы не пожалеете.
Надеюсь в скором будущем написать статью как я изучал Erlang и выложить её. Тем временем вы сами можете начать изучение, посетив ресурс learnyousomeerlang.com. Доверьтесь мне — это лучший выбор, чем любые книги по Erlang доступные на данный момент.
PS: Спасибо Elise Huard за корректуру! Если у вас есть замечания, изображения башен из слоновой кости с рубиновой крышей, чтобы сделать статью более красочной или какие либо пожелания, шлите мне их немедленно!
Шансы, что вы читаете эту статью на устройстве с многоядерным процесcором, растут каждый день, вот почему все постоянно говорят про параллелизм (concurrency). Параллелизм для наших web приложений и API бэкендов, это когда вывод htop выглядит примерно как на картинке:
Я недавно был на великолепной Ruby конференции и три или четыре доклада были про параллелизм. Сообщество Ruby достаточно открыто и обсуждалось достаточно много возможностей: использовать потоки, использовать различные среды выполнения Ruby, чтобы обойти GIL, использовать больше процессоров, использовать модель акторов через библиотеки как Celluloid или даже использовать Akka через JRuby.
В то время как модель акторов, кажется, хорошо подходит для создания сетевых параллельных приложений, которые часто страдает от проблем, если среда выполнения, на которой реализовано приложение не имеет нативной поддержки. Существуют реализации для Ruby, Python и Java, но все они должны подстраиваться, чтобы достичь нормальной работы и не обязательно результат даёт наилучшую производительность. Это одна из многих причин, почему Erlang был бы намного лучшим выбором, но сначала, давайте немного уделим время модели акторов, чтобы понять, почему это так хорошо работает.
Модель Акторов
Вот неплохая цитата из wikipedia, для поверхностного понимания:
«Модель акторов исходит из такой философии, что всё вокруг является акторами. Это похоже на философию объектно-ориентированного программирования, где всё вокруг является некоторыми объектами, но отличается тем, что в объектно-ориентированном программировании программы, как правило, выполняются последовательно, в то время как в модели акторов вычисления по своей сути совпадают по времени.»
Несмотря на некоторое сходство между актороми и объектами, такими как: модулярность, инкапсуляция и возможность отправки сообщений; акторы имеют уникальную особенность — они могут выполнять свою работу в одно и тоже время.
Другими словами, отправка сообщений, чтобы делиться состоянием с другими актороми, работает параллельно допуская асинхронное взаимодействие, это означает, что отправителю не обязательно ждать ответа от получателя.
Другое большое отличие от мира ООП это то, что модель акторов не имеет глобального состояния и по-этому не разделяют общую память между актороми. В языках, таких как: Java, Ruby и Python всегда используется глобальное состояние и нити имеют доступ к общей памяти. Это обстоятельство часто становится проблемой в виде блокировок или гонок состояний и возможно является наибольшим неудобством
В модели акторов каждый актор имеет своё собственное внутренние состояние, который раздаётся только через сообщения. Таким образом актор действует в качестве сериализатора для доступа к своему состоянию, тем самым эффективно избегают блокировки и состояний гонки.
Необходимо так же отметить, что модель акторов очень хорошо подходит для функциональных языков программирования с концепцией неизменяемых данных (Immutable Data).
Есть много, что можно почитать про акторы, но я бы отметил наиболее важную вещь, которую необходимо знать. В общем случае, модель акторов позволяет разрабатывать параллельные приложения намного проще и быстрее.
Хорошо, а что насчёт Erlang?
Сперва я бы хотел сказать, что много лет я был страстным Ruby разработчиком. Мне действительно очень нравится этот язык и его сообщество. Но время от времени я чувствовал, что преодолеваю невидимые стены, когда дело доходит до сетевых приложений, веб приложений, веб серверов, прокси и т. д. То есть все те приложения, которые обрабатывают множественные запросы и/или выполняют не тривиальные задачи.
Erlang попал в поле моего зрения достаточно давно, но с высоты моей башни из слоновой кости и рубиновой крышой потребовалось много попыток, чтобы понять, что его стоит попробовать. Концептуально это имеет большое значение для меня и я уверен, что большенство людей читавшие про Erlang, согласятся со мной. Должен признаться, что был потрясён синтаксисом языка и это останавливало меня
от желания попробовать этот язык. Думаю, это было большой ошибкой, которая и мотивировала меня написать эту статью, сказать вам, что вы должны попробовать Erlang как можно быстрее.
Сначала позвольте дать описание Erlang в одну строку:
«Erlang — функциональный язык, реализованный на модели акторов для параллельных приложений.»
Этот язык был разработан компанией Ericsson для своих телекоммуникационных свитчей и целью было создать язык, который позволил бы разрабатывать отказоустойчивые и параллельные системы с высокой доступностью.
Вы можете почитать обо всём на wikipedia или великолепном сайте: learnyousomeerlang.com — Эти ребята сделали отличную работу описав язык.
Практический пример использования Erlang в Wooga
Эта статья своеобразный толчок, я хочу побудить вас попробовать Erlang и буду стараться делать это рассказывая историю применения Erlang в Wooga.
Wooga делает социальные игры с миллионами активных игроков в день. Игры постоянно сообщают серверам изменить и удерживать состояние участников игры. Некоторые из наших игр были разработаны на Ruby и они работают неплохо. Ruby, как я уже говорил, действительно хороший язык и хотя не самый быстрый, но он может быть достаточно производительным, если вы знаете что делаете.
Наша самая большая игра, по числу пользователей, со сложной внутренней логикой, работает на серверах количеством от 80 и до 200. Они обрабатывают около 5000-7000 запросов каждую секунду и почти все запросы изменяют состояние игрока в самой игре. Должен отметить, хотя количество серверов и сохраняется в разумных пределах в момент пиковых нагрузок, но цифра, конечно же, не самая впечатляющая.
Когда пришло время создать новую игру со схожей логикой и сложностью, на этот раз мой коллега Paolo решил выбрать Erlang, он думал это будет правильным выбором. Мы наняли опытного разработчика на Erlang (Knut) и они вместе реализовали логику. Сейчас эта игра имеет около 50% игроков от остальных игр и количество серверов, необходимых обслуживать её, равно 1!..
Игра обслуживается двумя или тремя серверами для некоторой избыточности, но она может вполне идеально работать и на одном. Даже если игре действительно потребуется четыре сервера, всё равно это будет намного эффективнее и производительней, чем другие игры.
Конечно же они уже знали обо всех ошибках, сделаных в предыдущих играх и это не только отсутствие Erlang, это и помогло достичь такого прироста в производительности и способствовало в реализации логики, достигнуть поставленной цели было действительно легче с помощью модели акторов.
Говоря другим языком, они создали веб сервер для хранения состояния игроков, это значит, что каждый игрок, который ирает в данный момент, обслуживается отдельным актором внутри Erlang VM. Игрок, начиная игру, порождает актор с его состоянием. Последующие запросы, пока он играет, идут напрямую к актору, с которым он связан. Соответственно, пока состояние игры хранится в памяти, при этом исключаются любые обращения к базе, запросы обрабатываются и отвечают очень быстро.
Если актор падает, остальные акторы остаются «живыми» так как нет общего / глобального состояния. Когда игрок прекращает игру, актор сохраняет состояние игрока в постоянном хранилище и сборщик мусора (GC) удалит его из памяти. В тоже время, как мы помним, данные в Erlang не изменяются, что позволяет вернуть состояние игрока пока не произошли изменения и не пошло что либо не так.
Это действительно восхитительно и я могу рассказать намного больше. К счастью, Knut и Paolo рассказывали на нескольких конференциях про наш опыт и выложили свои слайды в открытый доступ. Вы можете просмотреть их по ссылкам:
* www.slideshare.net/wooga/erlang-factory-sanfran
* www.slideshare.net/hungryblank/getting-real-with-erlang
Больше Erlang в Wooga
После того, как Paolo и Knut заразили вирусом Erlang всю компанию, мы сделали новую игру на Erlang и несколько дополнительных сервисов. Могу подтвердить, что чем больше ты изучаешь Erlang, тем больше понимаешь как делать правильно. Это заставляет меня немного сожалеть о тех, кто на конференциях Ruby боролись с различными библиотеками, чтобы можно было легко разрабатывать параллельные приложения, что обеспечивает Erlang в одном пакете. Пакет, который используется уже более 20 лет.
Трудная часть в изучении нового языка, это найти небольшой проект и принять в нём участие. Изучать, просто читая книги, всегда медленно и когда приступаешь к написанию кода, большая часть прочитанного забывается. Так же, странный синтаксис (сейчас я не считаю его странным), был для меня непреодолимой преградой, чтобы начать использовать Erlang в реальном проекте. По этому рекомендую выбрать небольшой проект и «поиграться» с Erlang. Думаю вы не пожалеете.
Надеюсь в скором будущем написать статью как я изучал Erlang и выложить её. Тем временем вы сами можете начать изучение, посетив ресурс learnyousomeerlang.com. Доверьтесь мне — это лучший выбор, чем любые книги по Erlang доступные на данный момент.
PS: Спасибо Elise Huard за корректуру! Если у вас есть замечания, изображения башен из слоновой кости с рубиновой крышей, чтобы сделать статью более красочной или какие либо пожелания, шлите мне их немедленно!