Добро пожаловать обратно
Прошло много времени с моего последнего поста. За это время я работал в различных проектах и поделился бы с вами некоторым опытом разработки веб-приложения, которое можно «просто» масштабировать до распределенной системы.
Идея в этом посте взята из разных источников, которые вы можете найти в ссылке выше, но следует особо упомянуть Ino, который показывает мне первые шаги в этом направлении.
Этот пост был впервые опубликован на сайте Code Beam Stockholm. Этот пост о презентации, которую я сделал первый раз в Милане и второй раз в Стокгольме. Презентации похожи на программное обеспечение, и они сгниют, если мы не позаботимся об этом. Таким образом, эта презентация была немного другой в Стокгольме, а также кодовая база, которая относится к этому периоду, была изменена в течение этого периода и, я надеюсь, также в будущем. Я планирую создать семинар по этой теме, который поможет новым разработчикам лучше ознакомиться с этой концепцией.
Почему этот разговор
Я занимался разработкой программного обеспечения в прошлом тысячелетии, и я вижу, как появляются и исчезают множество шаблонов и моделей развития. Я большой поклонник заражения, потому что некоторые закономерности распространены в некоторых сообществах, но не используются или полностью игнорируются в других.
В Италии есть поговорка «paese che vai usanza che trovi» (когда в Риме поступают, как римляне). В каждом сообществе часто есть шаблоны, которые новички должны изучить, чтобы лучше использовать и понимать платформу и язык, который они используют.
Сообществу Elixir очень повезло, потому что оно может воспользоваться преимуществами Erlang и шаблонов виртуальной машины BEAM, которые «закалены в боях» за более чем 20-летнюю историю. В настоящее время существует большой интерес к тому, как эти проблемы решаются в среде BEAM (с использованием модели Actor) и как некоторые общие шаблоны, такие как Supervisor или GenServer, используются в других языках или фреймворках, например Akka.
Этот пост является первым из серии, в которой будут объяснены некоторые закономерности и некоторые отношения, которые распространены в мире BEAM, но могут быть необычными также для опытных разработчиков, которые никогда раньше не встречались с Erlang.
Немного истории
Вначале веб-разработка была очень «простой», был веб-сервер, набор скриптов и база данных. Каждый HTTP-запрос транслировался в SQL-запросы, которые загружали или записывали данные в БД, результатом часто было создание HTML-страницы и ничего более. Если бы мы были в «сложной среде», у нас также были бы некоторые фоновые задачи, часто выполняемые чем-то похожим на cron. Наша БД была правдой, и все было в одном месте, у всего было начало (приход http-запроса) и конец (доставка http-ответа). Эта процедура развивала подход к разработке, при котором мы создавали все связанные объекты (мы, вероятно, принимали язык ООП) в начале нашей работы и уничтожали все в конце. Нам «не разрешалось» хранить данные и объекты в памяти, потому что все начиналось и заканчивалось за время существования http-запроса.
Однако со временем Интернет превратился в платформу для разработки «приложений», в которых состояние не может храниться в одной базе данных и в одном процессе (вы можете услышать тихий голос, шепчущий «микросервисы»…). Теперь операции охватывают длину одного HTTP-запроса, и теперь нам нужна возможность связываться с множеством разных систем и отслеживать их состояния. Действительно, растущий интерес к BEAM и паттернам, которые BEAM может дать нам, действительно естественен.
Итак, мы можем задать нам вопрос, небольшую риторику:
Как мы можем создать веб-приложение, которое использует характеристики BEAM, используя ресурсы одного узла, и в конечном итоге масштабируется до многоузлового приложения?
Что мы увидим
В этом выступлении и в следующих сообщениях мы попытаемся создать простую электронную коммерцию, которая выявит некоторые классические проблемы, которые мы решим с помощью некоторого шаблона BEAM, и мы также увидим, как эти шаблоны могут помочь нам перейти от единого node приложение в кластерное приложение с помощью библиотеки, такой как riak-core.
Если вы хотите начать копаться в коде, это репо, и это ссылка на мой доклад в Милане и Стокгольме. Если что-то непонятно или у вас есть вопросы, не стесняйтесь оставлять комментарии.
