Если вы опасаетесь, что ваш веб-сервис могут заDOSить нерадивые пользователи, или у вас просто слабенький сервер, то вы уже задумывались над ограничением количества запросов от каждого пользователя. По-хорошему — это только один из необходимых эшелонов обороны. Конечно, от серьёзной атаки такое ограничение не убережёт, но с точки зрения цена/качество вполне подходящее

Недавно я начал активно заниматься Эрлангом. Ну и, как обычно, для закрепления материала реализовал несложный веб-сервис на Mochiweb. Mochiweb — вполне достойный фреймворк для создания веб-приложений, но возможности лимитировать количество запросов от одного клиента я не нашёл. Вот и сделал это самостоятельно.

Т.к. функционал лимитирования скорости запросов вполне себе изолированный и не привязан к какой-то конкретной задаче, я выделил сделанный модуль в независимое приложение и решил выложить его исходный код.

Задача

Итак, имеем Erlang/OTP, Mochiweb, rebar. Хочется считать количество запросов от конкретного пользователя и отдавать ему 413 код ошибки, если запросы идут слишком часто. Клиент идентифицируется своим IP адресом. Тем самым, который отдает mochiweb_request:get(peer).

Задача не такая сложная, но, возможно, готовое решение сэкономит кому-то время.

Не так давно, в команду пришлось приглашать нового программиста и знакомить его с Erlang. Для ускорения процесса обучения я решил перевести уже давно лежавший у меня материал Erlang Programming Rules and Conventions. Чем в принципе и хочу поделиться с хабровчанами. Надеюсь что он будет полезен тем, кто собирается изучать или уже использует этот замечательный язык. Сразу скажу, что перевод вольный, так что не критикуйте сильно.

«Chicago Boss — бескомпромиссный веб-фреймворк, любимый дизайнерами, инженерами и этим парнем с пейджером.» — © chicagoboss.org

«Erlang — язык для создания отказоустойчивых распределенных приложений. Это — один из немногих функциональных языков, который давно и успешно применяется на практике. Например — в телекомах (Ericsson AXD-301 switch), банковских системах, системах автоматизации, высоконагруженных веб-приложениях (Facebook Chat). При этом Erlang — продукт с открытым исходным кодом и распространяется бесплатно.» — говорит нам сайт русскоязычного сообщества Erlang.

Данный пост предназначен для расширения аудитории Erlang программистов. Если до этого вы считали что функциональное программирование не может быть использовано для бытовых целей, то пора расширить ваш кругозор. Этот пост писался при поддержке моего товарища, лично знакомого с создателем данного фреймворка (Эван Миллер) и последнее время фанатеющего от данного языка.

По заверению обоих разработка веб-приложений на базе этого фреймворка ничуть не медленнее разработки на тех же рельсах (Ruby on Rails). А в чем-то даже быстрее. Я с функциональным программированием до этого особо знаком не был, но под давлением товарища решил попробовать. Хочу сказать, что опыт был весьма удачным и у меня получилось создать мой первый веб-сайт быстрее, чем год назад с тем же Ruby on Rails.

Disclaimer: Описываемый инструмент имеет спорную репутацию. Я не призываю использовать его где ни попадя, только знакомлю с используемыми понятиями, дабы уменьшить некоторым трепет перед технологией.

Написанные исходники, а также текстовую копию статьи можно найти на гитхабе.

Что такое parse_transform

parse_transform — механизм изменения AST перед компиляцией. Предназначен для изменения значения конструкций (семантики), не выходя за синтаксис Эрланга.

К сожалению, в Сети мало информации про это, что делает порог вхождения весьма высоким для не-гуру эрланга.

Что мы будем делать

В рамках данной статьи я немного рассказажу про AST эрланга, приведу пример простых трансформаций, а так же покажу процесс написания parse_transform для создания stateless gen_server-а (задача имеет не особо много смысла, но в качестве примера использования сгодится), а в конце дам ссылку на набор начинающего транформатора.

Я продолжаю свое погружение в Эрланг. Уже есть хитрый план переписать один из наших сервисов для мониторинга на Эрланге. Мы тут осваиваем облака Windows Azure и Amazon EC2 в качестве платформы для некоторых продуктов и внутренних задач типа QA, поэтому возможность использовать много ядер и машин без переписывания кода выглядить перспективно.

Итак, для начала простой, но реальный пример — есть проект ~2000 файлов. Надо составить список используемых переменных окружения. То есть найти вхождения строк «getenv(...)» и «GetVariable(...)» (это наш wrapper) и выдрать из них параметр.

Задача незамысловатая и давно решается программой на C++, которая даже обход каталогов не делает, а просто вызывает юниксовый «find», генерирующий список файлов по маске, и затем по списку лопатит файлы. На 2000 файлах работает пару секунд в один поток.

Теперь Эрланг. Тут хочется замутить что-нибудь более кучерявое, чем последовательный обход файлов. MapReduce как раз в тему — можно составить список файлов, затем анализ каждого файла делать параллельно (Map), аккумулируя найденных имена переменных, и в конце обработать все полученные входждение (Reduce), в нашем случае просто подсчитать количество вхождения каждой переменной.

Если какой-либо программе необходимо передать данные эрланговсому серверу, эти данные предварительно должны быть сериализованы. То есть преобразованы в бинарный вид, так, чтобы эрланг мог потом распаковать их обратно. Обычно это делают с помощью ASN.1, google protobuf, thrift и т.д. Все это без сомнения достойные продукты.

В качестве альтернативного варианта можно рассмотреть использование эрланговского external term format. В исполняемой системе эрланга есть две функции - term_to_binary() и binary_to_term(), которые эффективно и быстро могут запаковать/распаковать любые значения в этот формат, а сам формат хорошо описан в документации — www.erlang.org/doc/apps/erts/erl_ext_dist.html

Как это все работает.

Вот одна из распространённых проблем многопоточных(concurrent) систем: события возникают постоянно в разных частях программы в разное время, и у вас нет возможности контролировать причину и время их возникновения. Чтобы отследить проблему, мы зачастую можем воспользоваться диаграммой последовательностей. Например, такой (спасибо Wikipedia):



Предназначение данной диаграммы — показать взаимодействие между различными параллельными компонентами системы. В данном примере Fred, Bob, Hank и Renee в ресторане. Каждый может легко нарисовать подобную диаграмму на бумаге. Проблема в том, что наброски на бумаге могут отличаться от того, что происходит во время выполнения вашей программы.

Правда было бы здорово, если бы вы могли строить похожие диаграммы на основе данных трассировки программы автоматически? Что ж, Erlang вам в этом поможет.

Если вам нужна нестандартная функциональность от XMPP сервера ejabberd, вы не знаете, как это настроить штатными средствами и не нашли подходящего для этого модуля, то можно написать этот модуль самим.

Так я решил, когда начальство объявило войну пустой болтовней в jabber-е, для чего необходимо было запретить некоторым пользователям чатица с другими, но разрешить с третьими. И хотя у меня всё ещё есть смутное подозрение, что это можно настроить с помощью списков доступа, я решил написать модуль, которым мне будет удобно пользоваться. Этот модуль и послужит примером для рассказа.

Если вы по каким-либо причинам заинтересованы в разработке веб-приложения на Erlang, то у вас возникнет закономерный вопрос, какую из имеющихся технологий для этого использовать: взять один из существующих веб-серверов, таких как YAWS, Mochiweb, Misultin (назову их так, хотя некоторые из них называют себя фреймворком для построения веб-серверов) или воспользоваться чем-то готовым, например Zotonic CMS или Nitrogen.
Задавшись этим вопросом, вы наверняка найдёте этот пост на Stackoverflow, в котором довольно подробно рассмотрены все плюсы и минусы различных подходов.

В данной статье автор попытался раскрыть тему использования Webmachine для создания веб-ресурсов.

Это четвертая статья в серии «Введение в ОТП». Если вы только что присоединились к нам, рекомендую начать с первой части, в которой говорится о gen_server и закладывается фундамент нашей банковской системы. Если же вы способный ученик, можете взглянуть на готовые к настоящему моменту модули: eb_server.erl, eb_event_manager.erl, eb_withdrawal_handler.erl и eb_atm.erl.

Сценарий: Момент, который нам нравится в банках и банкоматах, заключается в том, что они всегда на том же месте. Используя банкомат, мы можем снять или положить деньги когда захотим, 24 часа в сутки. Или пойти в любое отделение банка, когда оно открыто, зная, что будем иметь полный доступ к нашим финансам. Чтобы гарантировать это, необходимо быть уверенным в том, что наша система автоматизации ErlyBank всегда остается рабочей: процессы должны быть запущены постоянно. ErlyBank поручил нам реализовать эту цель. Стопроцентный uptime! (Или настолько близкий, насколько мы сможем обеспечить)

Результат: Используя контролёр (supervisor) OTP, мы создадим процесс, чья обязанность — следить за запущенными процессами и удостовериться, что они активны.

В некоторых случаях бывает удобно скомпилировать определенные части программы во время работы приложения. Например, в мире явы так происходит компиляция веб сервером .jsp страниц в сервлеты. Другими возможными применениями подобной техники являются разные языки шаблонов, регулярные выражения и т.д.

В эрланге транслятор встроен в библиотеку времени исполнения, и позволяет полностью управлять всеми стадиями трансляции.

Как это сделать

От переводчика: попытаюсь подхватить флаг, брошенный tiesto из-за недостатка кармы (кстати, огромное ему спасибо за первые переводы; именно благодаря им я узнал об авторе, чей цикл статей надеюсь продолжить переводить).

Ссылки на предыдущие части можно найти в конце статьи.

Это третья статья в серии «Введение в ОТП». Рекомендую начать с первой части, в которой говорится о gen_server и закладывается фундамент нашей банковской системы, если вы до сих пор не сделали этого. С другой стороны, если вы способный ученик, можете взглянуть на готовые модули eb_atm.erl и eb_server.erl.

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

Результат: Мы создадим систему уведомлений, основанную на событиях, используя gen_event. Это даст нам базовый фундамент для создания в будущем и других уведомлений, в то же время позволяя легко интегрироваться в текущее серверное ПО.

Все, кто хоть раз занимался использованием dialyzer для своих приложений знает, что ему надо бы сперва подготовить plt файлы для основных аппликейшенов из поставки самого erlang'а.

Генерация идёт нагружая только одно ядро и довольно долго, в связи с чем появилось большое желание запускать генерацию параллельно.

Обновлено: добавлен патч (и отправлен пулл реквест, разумеется) к dialyzer добавляющий фичу мержа нескольких plt в один большой-и-толстый.

Введение

В замечательной статье с trapexit «Building a Non-blocking TCP server using OTP principles» рассказывается, как построить неблокирующий TCP сервер используя принципы OTP. Думаю, каждый, кто начинал изучать elrlang рано или поздно сталкивался с этой статьей. Для построения неблокирующего TCP сервера в указанной выше статье используется недокументированный функционал из модуля prim_inet.

Не буду филосовствовать хорошо или плохо использовать undocumented features, в некоторых «костыльных» решениях это действительно нужно, в продакшене я бы предпочел использовать проверенные средства. На заметку, даже в самой статье автор предупреждает: "Examining prim_inet module reveals an interesting fact that the actual call to inet driver to accept a client socket is asynchronous. While this is a non-documented property, which means that the OTP team is free to change this implementation, we will exploit this functionality in the construction of our server [1]."

www.youtube.com/watch?v=NisCkxU544c

Посмотрев презентацию Юрия (yrashk) с Erlang Conference о веб-фреймворках в эрланге я заинтересовался и решил сделать сайтик не на node.js, как намеревался изначально, а используя какой-нибудь эрланговский фреймворк.

В итоге я наткнулся на фреймворк Chicago Boss. Про сам фреймворк я слышал и раньше, но пользоваться пока не довелось.

В данной статье изложены размышления и фантазии на тему «как можно было бы скрестить Erlang и PHP, чтобы случилось вселенское счастье», а не описание готовой технологии или продукта. Впрочем, мы намерены это реализовать, скорее всего, в форме open-source проекта, если, конечно, уважаемая хабра-аудитория не отговорит :) Собственно, одна из главных задач этой статьи — понять, насколько идея интересна и потенциально полезна широкому PHP-сообществу. Кстати, некоторые из проблем, обсуждаемых в статье, справедливы и для других популярных скриптовых языков (тут я подразумеваю Ruby и Python), так что предлагаемое решение, возможно, будет актуально и для них.

Я прочитал очень-очень интересную статью «Стратегии управления памятью для Erlang VM». Она была написана в качестве диссертации Джеспером Вильхельмсоном. Я подумал, что было бы неплохо обсудить различия между управлением памятью в Erlang и Java VM от Oracle.

Эрланг отличная платформа для построения серверов, и в его стандартной библиотеке предусмотрены многие средства заметно облегчающие жизнь разработчика.

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

Это собственно является одним из ключевых отличий «наколенных» решений от «энтерпрайс». Настоящий, хорошо спроектированный сервер «в курсе», что он не может тратить ресурсы безгранично, ведет учет ресурсов и контролирует загрузку.

Как это делается?

Erlang Web — платформа с открытым исходным кодом для приложений, основанных на протоколе HTTP. В настоящий момент поддерживаются веб-серверы INETS и Yaws. Erlang Web разрабатывался в Erlang Training & Consulting Ltd. в течение прошлых трех лет и используется во многих коммерческих и открытых проектах.

Применение

Проекты, использующие Erlang Web:

• Erlang Solutions Ltd.
• ProTest-Project
• Erlang Web
• Streamfile
• Umbria Rentals
• Erlang Factory
• Erlang Programming (Book)

Erlang является уникальной по своим возможностям платформой, и не смотря на это, язык до сих пор является экзотикой. Причин существует несколько. Например, тугая арифметика, непривычность синтаксиса, функциональность. Это не недостатки. Это просто вещи, с которыми большинство программистов не могут или не хотят работать.

Несколько дней назад Jose Valim опубликовал в своем репозитории проект языка, построенного поверх Erlang. Этот язык обладает простой объектной моделью и Ruby-подобным синтаксисом. Под катом выжимки из документации и видео, демонстрирующее простой пример.

disclaimer: %username%, прежде чем делать выводы насчет того, что умеет, а что не умеет elixir, просьба глазами пройтись хотя бы по readme.