Pull to refresh
  • by relevance
  • by date
  • by rating

Реактивный манифест

System Analysis and Design *Concurrent computing *
Translation
В последние годы требования к приложениям значительно изменились. Десятки серверов, время отклика в несколько секунд, оффлайновое обслуживание, которое могло длиться часами, гигабайты данных — такими были большие приложения буквально несколько лет назад. Сегодня же приложения работают абсолютно на всём, начиная с простых мобильников и заканчивая кластерами из тысячи процессоров. Пользователи ожидают миллисекундного времени отклика и стопроцентного аптайма, в то время как данные выросли до петабайтов.

Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.

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

Однако прогресс не стоит на месте. Архитектура приложений эволюционировала в соответствии с изменившимися требованиями. Приложения, разработанные на основе этой архитектуры, мы называем Реактивными Приложениями. Такая архитектура позволяет программистам создавать событийно-ориентированные, масштабируемые, отказоустойчивые и отзывчивые приложения — приложения, работающие в реальном времени и обеспечивающие хорошее время реакции, основанные на масштабируемом и отказоустойчивом стеке и которые легко развернуть на многоядерных и облачных архитектурах. Эти особенности критически важны для реактивности.

Читать дальше →
Total votes 24: ↑21 and ↓3 +18
Views 47K
Comments 15

Концепция Message Passing. Агенты и актёры

ХостТрекер corporate blog .NET *Functional Programming *
Данная статься начитает серию публикаций о технологиях, которые мы используем и изучаем для разработки сервиса мониторинга веб сайтов HostTracker. Надеемся, наш опыт окажется полезным.

Message passing является одной из популярных концепций параллельного программирования. Она часто используется при создании сложных распределенных систем с высокой степенью параллелизма. Реализация этой концепции представлена в языках программирования в качестве актёров (actor) или агентов (agent).


Расспределенные агенты HostTracker. Быстрая проверка с http://updownchecker.com

Читать дальше →
Total votes 26: ↑18 and ↓8 +10
Views 7.1K
Comments 26

Message Passing в F#. Применение MailboxProcessor

ХостТрекер corporate blog .NET *Functional Programming *F# *
Данная статься продолжает серию публикаций о технологиях, которые мы используем для разработки сервиса проверки доступности веб сайтов HostTracker.
Сегодня речь пойдет о…

MailboxProcessor


image

Читать дальше →
Total votes 8: ↑6 and ↓2 +4
Views 3.6K
Comments 0

Из опыта использования SObjectizer: акторы в виде конечных автоматов – это плохо или хорошо?

Open source *Programming *C++ *

Познакомив читателей с фреймворком SObjectizer, его возможностями и особенностями, можно перейти к рассказу о некоторых уроках, которые нам довелось усвоить за более чем четырнадцать лет использования SObjectizer-а в разработке C++ного софта. Сегодня поговорим о том, когда агенты в виде конечных автоматов не являются хорошим выбором, а когда являются. О том, что возможность создания большого количества агентов – это не столько решение, сколько сама по себе проблема. И о том, как первое соотносится со вторым...

Читать дальше →
Total votes 13: ↑13 and ↓0 +13
Views 2.8K
Comments 6

SObjectizer: проблема перегрузки агентов и средства борьбы с ней

Open source *Programming *C++ *

В предыдущих статьях мы несколько раз упоминали о такой проблеме, как перегрузка агентов. Что это такое? Чем это грозит? Как с этим бороться? Обо всем этом мы и поговорим сегодня.


Проблема перегрузки агентов возникает, когда какому-то агенту отсылается больше сообщений, чем он успевает обрабатывать. В результате очереди сообщений постоянно увеличиваются в размерах. Растущие очереди расходуют память. Расход памяти ведет к замедлению работы приложения. Из-за замедления проблемный агент начинает обрабатывать сообщения дольше, что увеличивает скорость роста очередей сообщений. Что способствует более быстрому расходу памяти. Что ведет к еще большему замедлению приложения. Что ведет к еще более медленной работе проблемного агента… Как итог, приложение медленно и печально деградирует до полной неработоспособности.


Проблема усугубляется еще и тем, что взаимодействие посредством асинхронных сообщений и использование подхода fire-and-forget прямо таки провоцирует возникновение перегрузок (fire-and-forget – это когда агент A получает входящее сообщение M1, выполняет его обработку и отсылает исходящее сообщение M2 агенту B не заботясь о последствиях).

Читать дальше →
Total votes 16: ↑16 and ↓0 +16
Views 3K
Comments 6

Нежная дружба агентов и исключений в SObjectizer

Open source *Programming *C++ *
Рано или поздно в программе что-нибудь идет не так. Не открылся файл, не создалась рабочая нить, не выделилась память… И с этим нужно как-то жить. В небольшом однопоточном приложении довольно просто: можно прервать всю работу и рестартовать. Это один из факторов, благодаря которому Erlang снискал себе заслуженную популярность, ведь идеология fail fast является одним из краеугольных камней Erlang-а с его легковесными процессами. Если же приложение большое, сложное и многопоточное, то не разумно рестартовать все приложение, если лишь одна из его нитей столкнулась с проблемами. Еще хуже в ситуации с реализациями Модели Акторов, в которых сотни тысяч акторов могут работать на десятках рабочих нитей. Проблема одного актора вряд ли должна сказываться на всех остальных акторах.

В данной статье мы расскажем, как мы подошли к обработке ошибок в своем фреймворке SObjectizer.

Исключениям – да, кодам возврата – нет!


Когда SObjectizer-4 появился в 2002-ом году, мы сделали большую ошибку – предпочли использовать коды возврата исключениям. И весь последующий опыт разработки на SObjectizer-4 снова и снова убеждал в одной простой истине: если ошибка может быть прогнорирована разработчиком, то она будет им проигнорирована. Поэтому при создании SObjectizer-5 мы решили использовать исключения для информирования об ошибках.
Читать дальше →
Total votes 11: ↑9 and ↓2 +7
Views 4K
Comments 4

Модель Акторов и C++: что, зачем и как?

Open source *Programming *C++ *

Данная статья является доработанной текстовой версией одноименного доклада с конференции C++ CoreHard Autumn 2016, которая проходила в Минске в октябре прошлого года. Желание сделать эту статью возникло под впечатлением о том, что в мире C++ разработчики как бы делятся на два больших и не пересекающихся лагеря. В первом лагере находятся матерые спецы, которые все видели, все знают и все умеют, за плечами у которых десятки собственноручно написанных реализаций Модели Акторов, внутрях у которых хитрые, конечно же самостоятельно сделанные, lock-free очереди и state-of-the-art механизмы обслуживания сообщений. Такие проффи сами часами могут рассказывать про тонкости многопоточного программирования (только почему-то редко это делают). Во втором лагере — зеленые новички, которых волею судьбы занесло в мир C++, которые пока слабо представляют себе различия между unique_ptr и shared_ptr, про шаблоны только слышали, а в области многопоточности имеют поверхностное впечатление только о std::thread, std::mutex и, может быть, std::condition_variable. Для людей из первого лагеря я вряд ли что-нибудь интересное расскажу, а вот разработчикам из второго лагеря попробую вкратце рассказать о том, что Модель Акторов в C++ — это нормально. И что есть ряд готовых инструментов, на примере которых можно увидеть, что же это такое.

Читать дальше →
Total votes 24: ↑24 and ↓0 +24
Views 31K
Comments 29

Подводные камни для самодельной распределенности «из коробки» в С++ном акторном фреймворке

Open source *Programming *C++ *Development of communication systems *

В комментариях к последней статье про шишки, которые нам довелось набить за 15 лет использования акторов в C++, вновь всплыла тема отсутствия в SObjectizer-5 распределенности «из коробки». Мы уже отвечали на эти вопросы множество раз, но очевидно, что этого недостаточно.


В SObjectizer-5 нет распределенности потому, что в SObjectizer-4 поддержка распределенности была, но по мере того, как расширялся спектр решаемых на SObjectizer задач и росли нагрузки на SObjectizer-приложения, нам пришлось выучить несколько уроков:


  • Под каждый тип задачи желательно иметь свой специализированный протокол. Потому что обмен большим количеством мелких сообщений, потеря части которых не страшна, сильно отличается от обмена большими бинарными файлами;
  • Реализация back-pressure для асинхронных агентов — это сама по себе непростая штука. А когда сюда еще и примешивается общение по сети, ситуация становится гораздо хуже;
  • Сегодня какие-то куски распределенного приложения обязательно будут написаны на других языках программирования, а не на C++. Поэтому требуется интероперабильность и наш собственный протокол, заточенный под C++ и SObjectizer, мешает разработке распределенных приложений.

Далее в статье попробуем раскрыть тему подробнее.

Читать дальше →
Total votes 12: ↑12 and ↓0 +12
Views 6.2K
Comments 23

Научиться перехватывать необработанные сообщения или пример того, как SObjectizer обрастает новыми фичами…

Open source *Programming *C++ *
Нам очень приятно, когда в SObjectizer добавляются новые возможности, возникшие в результате подсказок и/или пожеланий пользователей SObjectizer-а. Хотя далеко не всегда это оказывается просто. Ведь, с одной стороны, у нас, как у команды разработчиков и старых пользователей SObjectizer-а, уже есть собственные стереотипы о том, как SObjectizer принято использовать. И не всегда получается сразу оценить «свежий взгляд со стороны», понять что реально хочет видеть пользователь во фреймворке и почему он не удовлетворен имеющимися средствами. С другой стороны, SObjectzer не такой уж и маленький фреймворк, добавление новых возможностей требует определенной осмотрительности. Нужно, чтобы новая функциональность не конфликтовала с уже имеющимися фичами. И, тем более, чтобы после добавления чего-то нового не сломалось то, что уже есть и давно работает. Плюс к тому, у нас есть пунктик по поводу сохранения совместимости между версиями SObjectizer-а, поэтому мы сильно против кардинальных изменений…

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

Под катом небольшой рассказ о том, как в SObjectizer добавлялась одна новая фича. Может быть кому-то из читателей будет интересно посмотреть, как старый фреймворк адаптируется под запросы новых пользователей.
Читать дальше →
Total votes 8: ↑8 and ↓0 +8
Views 1.8K
Comments 2

Давайте попробуем поговорить про иерархические конечные автоматы вообще и их поддержку в SObjectizer-5 в частности

Open source *Programming *C++ *
Конечные автоматы — это, пожалуй, одно из самых основополагающих и широко используемых понятий в программировании. Конечные автоматы (КА) активно применяются во множестве прикладных ниш. В частности, в таких нишах, как АСУТП и телеком, с которыми доводилось иметь дело, КА встречаются чуть реже, чем на каждом шагу.

Поэтому в данной статье мы попробуем поговорить о КА, в первую очередь об иерархических конечных автоматах и их продвинутых возможностях. И немного рассказать о поддержке КА в SObjectizer-5, «акторном» фреймворке для C++. Одном из тех двухнескольких, которые открыты, бесплатны, кросс-платформенны, и все еще живы.

Даже если вам не интересен SObjectizer, но вы, скажем, никогда не слышали про иерархические конечные автоматы или о том, насколько полезны такие продвинутые возможности КА, как обработчики входа-выхода для состояний или история состояния, то вам может быть интересно заглянуть под кат и прочесть хотя бы первую часть статьи.
Читать дальше →
Total votes 15: ↑14 and ↓1 +13
Views 4.2K
Comments 2

Строительные блоки распределенных приложений. Нулевое приближение

System Analysis and Design *Erlang/OTP *Functional Programming *Distributed systems *


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

Читать дальше →
Total votes 10: ↑10 and ↓0 +10
Views 3K
Comments 0

Строительные блоки распределенных приложений. Первое приближение

System Analysis and Design *Erlang/OTP *Functional Programming *Distributed systems *


В прошлой статье мы разобрали теоретические основы реактивной архитектуры. Пришло время поговорить о потоках данных, путях реализации реактивных Erlang/Elixir систем и шаблонах обмена сообщениями в них:


  • Request-response
  • Request-Chunked Response
  • Response with Request
  • Publish-subscribe
  • Inverted Publish-subscribe
  • Task distribution
Читать дальше →
Total votes 15: ↑15 and ↓0 +15
Views 3.3K
Comments 0

Строительные блоки распределенных приложений. Второе приближение

System Analysis and Design *Erlang/OTP *Functional Programming *Distributed systems *

Анонс


Коллеги, в середине лета я планирую выпустить еще один цикл статей по проектированию систем массового обслуживания: “Эксперимент VTrade” — попытка написать фреймворк для торговых систем. В цикле будет разобрана теория и практика построения биржи, аукциона и магазина. В конце статьи предлагаю проголосовать за наиболее интересные вам темы.



Это завершающая статья цикла по распределенным реактивным приложениям на Erlang/Elixir. В первой статье можно найти теоретические основы реактивной архитектуры. Вторая статья иллюстрирует основные шаблоны и механизмы построения подобных систем.


Сегодня мы поднимем вопросы развития кодовой базы и проектов в целом.

Читать дальше →
Total votes 17: ↑17 and ↓0 +17
Views 2.3K
Comments 0

Что нового в SObjectizer-5.7.0 и ждет этот проект дальше?

Open source *Programming *C++ *

SObjectizer — это относительно небольшой C++17 фреймворк, который позволяет использовать в С++ программах такие подходы, как Actor Model, Publish-Subscribe и Communicating Sequential Processes (CSP). Что существенно упрощает разработку сложных многопоточных приложений на C++. Если читатель в первый раз слышит о SObjectizer-е, то составить впечатление о нем можно по этой презентации, или из этой уже достаточно старой статьи.


Вообще говоря, подобных открытых, все еще живых и все еще развивающихся инструментов для C++ не так уж и много. Можно вспомнить разве что QP/C++, CAF: C++ Actor Framework, actor-zeta и совсем молодой еще проект rotor. Выбор есть, но не сказать, что большой.


Недавно стала доступна очередная "мажорная" версия SObjectizer-а, где наконец-то появилась штука, о которой разговоры ходили давно, и к реализации которой я несколько раз безуспешно подступался. Можно сказать, что достигнута знаковая веха. Это также повод, чтобы рассказать о том, что ждет SObjectizer после релиза версии 5.7.0.


Поддержка send_case в select()


Итак, самое важное нововведение, которое появилось в v.5.7.0 и ради которого даже сломана совместимость с вышедшей в прошлом году v.5.6 (а совместимость мы просто так не ломаем) — это поддержка send_case в функции select(). Что сделало SObjectizer-овский select() гораздо более похожим на select из языка Go. Теперь посредством select() можно не только читать сообщения из нескольких CSP-шных каналов, но и отсылать исходящие сообщения в те каналы, которые оказались готовы для записи.

Читать дальше →
Total votes 15: ↑15 and ↓0 +15
Views 1.9K
Comments 7

Релиз акторного фреймворка rotor v0.09 (c++)

Crazy Panda corporate blog Open source *Programming *C++ *

actor system


rotorненавязчивый С++ акторный микрофремворк, похожий на своих старших братьев — caf и sobjectizer. В новом релизе внутреннее ядро полностью было переделано с помощью механизмов плагинов, так что это затронуло жизненный цикл акторов.

Читать дальше →
Total votes 10: ↑10 and ↓0 +10
Views 3.7K
Comments 1

Не хочется ждать в очереди? Напишем свой диспетчер для SObjectizer с приоритетной доставкой

Open source *Programming *C++ *


SObjectizer — это небольшой фреймворк для C++, который дает возможность разработчику использовать такие подходы, как Actor Model, Communicating Sequential Processes и Publish/Subscribe.


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


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


Сегодня мы еще раз поговорим об этом. На примере уже другой задачи. Да и реализация будет отличаться, поскольку за прошедшее время SObjectizer успел обновиться сперва до версии 5.6, а затем и 5.7. И в этих версиях много отличий от версии 5.5, про которую в основном и рассказывалось в прошлом. В том числе и в механизме диспетчеров.


О решаемой задаче в двух словах


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


Сообщения msg_status могут идти большим потоком. Например, на одно msg_result может приходиться до 1000 msg_status. И нам бы хотелось, чтобы когда в очереди уже стоит 900 сообщений msg_status, новое сообщение msg_result вставало не в конец очереди, а в самое ее начало. Чтобы msg_result не ждало, пока разгребутся 900 старых msg_status.

Читать дальше →
Total votes 11: ↑10 and ↓1 +9
Views 992
Comments 4

Обзор последних изменений в rotor'е (v0.10… v0.14)

Open source *Programming *C++ *

actor system


rotorненавязчивый С++ акторный микрофремворк с возможностью создания иерархий супервайзеров, похожий на своих старших братьев — caf и sobjectizer. В последних релизах с момента последнего анонса накопились существенные улучшения, которые хотелось бы осветить.

Читать дальше →
Total votes 2: ↑2 and ↓0 +2
Views 1.5K
Comments 2

Предсказание растворимости молекул с помощью графовых сверточных нейросетей

Питерская Вышка corporate blog Python *Machine learning *Biotechnologies

Пару недель назад мы начали рассказывать о проектах, которые стали победителями Школы по практическому программированию и анализу данных НИУ ВШЭ — Санкт-Петербург и компании JetBrains.

Второе место заняла команда одиннадцатиклассников из СУНЦ МГУ. Ребята реализовали модель, которая предсказывает растворимость веществ, основываясь на SMILES представлении молекул. Что это такое, какие методы машинного обучения можно использовать в этой задаче, и согласуются ли полученные результаты с реальными химическими экспериментами, авторы проекта рассказали в этом посте. 

Читать далее
Total votes 7: ↑7 and ↓0 +7
Views 2.7K
Comments 22
1