Хороший вариант использования для Akka [закрыто]

605

Я слышал много восторженных отзывов об инфраструктуре Akka (сервисной платформе Java / Scala), но до сих пор не видел много реальных примеров использования, для которых это было бы хорошо. Поэтому мне было бы интересно услышать о вещах, которые разработчики успешно использовали.

Единственное ограничение: пожалуйста, не включайте случай написания чата на сервере. (почему? так как это использовалось как пример для многих подобных вещей)

— StaxMan
источник

10

Не проще ли начать с проблемы и найти решение для нее, чем иметь решение и искать проблему для ее решения? Я предполагаю, что вместо использования RMI, Akka и его актеры выглядят намного проще / проще для написания кода.

— Кеннет

67

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

— StaxMan

Есть связанный вопрос, но по поводу применения AKKA для существующего приложения + некоторые варианты использования: stackoverflow.com/questions/16595685/…

— ses

2

Akka является лучшим решением по сравнению с JMS или системой распределенных очередей сообщений в стиле MQ. Это лучший способ понять это для меня, который недавно задавал тот же вопрос: «Я понимаю, как его использовать, и вижу, где я могу его использовать, но я не вижу, где это даст реальное преимущество». Основные допущения при разработке Akka намного лучше, чем при JMS / MQ, особенно в отношении изоляции процессов, проектирования без блокировок и обработки повторных попыток / отказов. Во-вторых, API гораздо элегантнее, чем инструменты JMS / MQ.

— user2684301

2

@ user2684301 хммм. Я нахожу этот ответ немного несправедливым, в смысле от яблок к апельсинам. MQ - это (логически) простые строительные блоки, которые делают намного меньше, чем Akka, и я бы не стал сравнивать их рядом. Но я думаю, если бы я прочитал это как «по сравнению с распределенными системами, построенными с использованием JMS, написанными декларативно», тогда это имело бы больше смысла.

— StaxMan

321

Я использовал его в двух реальных проектах очень успешно. оба находятся в поле информации о трафике почти в реальном времени (трафик, как в автомобилях на автомагистралях), распределены по нескольким узлам, объединяя сообщения между несколькими сторонами, надежные серверные системы. Я не имею права давать конкретную информацию о клиентах, когда я получаю ОК, может быть, это можно добавить в качестве ссылки.

Акка действительно потянул за эти проекты, хотя мы начали, когда он был на версии 0.7. (кстати, мы используем scala)

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

Это очень хорошо в моделировании любого типа асинхронной обработки сообщений. Я предпочел бы написать любой тип (веб) системы услуг в этом стиле, чем любой другой стиль. (Вы когда-нибудь пытались написать асинхронный веб-сервис (на стороне сервера) с JAX-WS? Это очень сложная задача). Поэтому я бы сказал, что любая система, которая не хочет зависать на одном из своих компонентов, потому что все неявно вызывается с использованием синхронных методов, и что один компонент блокируется на чем-то. Он очень стабилен, и решение «откажись от сбоев + супервизор» действительно хорошо работает. Все легко настроить программно и не сложно для модульного тестирования.

Тогда есть отличные дополнительные модули. Модуль Camel действительно хорошо подключается к Akka и позволяет легко разрабатывать асинхронные службы с настраиваемыми конечными точками.

Я очень доволен фреймворком, и он становится стандартом де-факто для связанных систем, которые мы создаем.

— Раймонд Ростенбург
источник

14

Каково преимущество этого подхода по сравнению с использованием бэкэнда обмена сообщениями (например, ActiveMQ) для передачи сообщений, по вашему мнению?

— magiconair

27

Продукты MQ действительно предназначены для другого случая использования. разные гарантии и очень разные характеристики. Продукты MQ требуют большой настройки, вы не будете использовать очереди в таком продукте так же, как вы используете объекты. Актеры - это люди первого класса в akka, вы используете их по своему усмотрению, подобно тому, как вы бы использовали объекты, так что в вашей модели программирования и в настройках намного меньше накладных расходов. Продукты MQ, которые вы бы использовали в большей степени для интеграции с другими внешними системами, а не для создания «внутренних компонентов» системы, для которой вы бы использовали актеров.

— Рэймонд Ростенбург

26

Новый URL-адрес для тематического исследования DBP: downloads.typesafe.com/website/casestudies/…

— Bas

2

Создание @RaymondRoestenburg re: MQ систем и альтернатив. Например, RabbitMQ построен на актерском языке программирования Erlang. Это один из способов думать об отношениях (и различиях) между актером и MQ. Между тем Apache Spark не является ни рабочим, ни очередным, ни основанным на актерах , НО можно использовать с Akka: Typesafe демонстрирует, как использовать Spark Streaming с Akka .

— Ловец снов

6

@RaymondRoestenburg Вы забыли упомянуть, что модель Actor «как есть» продвигает структуру, похожую на спагетти. Книга «Акка в действии», которую вы написали, является лучшей демонстрацией этой «особенности». Примеры кода имеют дело с довольно простыми историями. Все же рабочий процесс очень труден для понимания и следования из кода. Связанная проблема заключается в том, что код Akka будет НЕОБРАТИМОЙ по всей вашей бизнес-логике самым навязчивым способом, который вы только можете себе представить. Гораздо больше, чем любая другая структура без актера. Просто невозможно написать основной рабочий процесс, не разбивая его на разные отдельные разделы.

— увлеченный

222

Отказ от ответственности: я ПО для Акка

Кроме предложения шведского стола для параллелизма, который намного проще рассуждать и получать правильные данные (актеры, агенты, параллелизм потока данных) и с контролем параллелизма в форме STM.

Вот несколько вариантов использования, которые вы могли бы рассмотреть:

Обработка транзакций (онлайн-игры, финансы, статистика, ставки, социальные сети, телеком, ...)
- масштабирование, масштабирование, отказоустойчивость / HA
Сервисный бэкэнд (любая отрасль, любое приложение)
- Служба ОТДЫХ, МЫЛО, комед
- выступать в качестве концентратора сообщений / уровня интеграции
- масштабирование, масштабирование, отказоустойчивость / HA
Snap-in параллелизм / параллелизм (любое приложение)
- Правильный
- Просто работать и понимать
- Просто добавьте jar в существующий проект JVM (используйте Scala, Java, Groovy или JRuby)
Пакетная обработка (любая отрасль)
- Интеграция Camel для соединения с источниками пакетных данных
- Актеры разделяют и покоряют пакетные рабочие нагрузки
Узел связи (телекоммуникации, веб-медиа, мобильные медиа)
- масштабирование, масштабирование, отказоустойчивость / HA
Игровой сервер (онлайн-игры, ставки)
- масштабирование, масштабирование, отказоустойчивость / HA
BI / обработка данных / переработка общего назначения
- масштабирование, масштабирование, отказоустойчивость / HA
вставьте другие хорошие варианты использования здесь

— Виктор Кланг
источник

10

Я понимаю преимущества Futures и STM, но не нахожу хороших вариантов использования для актеров. Для сервера игр или ставок, в чем преимущество использования Actors против нескольких серверов приложений за балансировщиком нагрузки?

— Мартин Коничек,

8

@ViktorKlang POs! = Технический лидер. Они работают вместе, но разные роли.

— taylorcressy

79

Примером того, как мы его используем, является приоритетная очередь транзакций по дебетовым / кредитным картам. У нас их миллионы, и трудозатраты зависят от типа входной строки. Если транзакция имеет тип CHECK, у нас очень мало обработки, но если это точка продажи, то есть много чего сделать, например слияние с метаданными (категория, метка, теги и т. Д.) И предоставление услуг (оповещения по электронной почте / смс, обнаружение мошенничества, низкий остаток средств и т. д.). Основываясь на типе ввода, мы составляем классы различных характеристик (так называемые миксины), необходимые для обработки задания и последующего выполнения работы. Все эти задания в режиме реального времени поступают в одну и ту же очередь из разных финансовых учреждений. После того как данные очищены, они отправляются в разные хранилища данных для сохранения, аналитики или помещаются в сокетное соединение или в кометный актер Lift. Рабочие субъекты постоянно самостоятельно балансируют нагрузку, чтобы мы могли обрабатывать данные максимально быстро. Мы также можем добавить дополнительные услуги, модели постоянства иСТМ для критических точек решения.

Передача сообщений в стиле Erlang OTP на JVM делает отличную систему для разработки систем реального времени на плечах существующих библиотек и серверов приложений.

Akka позволяет вам передавать сообщения, как вы это делаете в традиционном ESBно со скоростью! Он также предоставляет вам инструменты для управления огромным количеством пулов участников, удаленных узлов и отказоустойчивости, которые необходимы для вашего решения.

— Уэйд Арнольд
источник

1

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

— StaxMan

7

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

— Уэйд Арнольд

4

Событийная архитектура - это другой способ думать о проблемах. Стоит прочитать Erlang OTP в действии с manning, если вы думаете о кодировании в Akka. Erlang OTP влияет на многие конструкции в akka, и в книге даются принципы, почему Jonas Boner создал akka api так, как он это сделал. Акка - большая гора, на которой ты стоишь! Если субъекты являются постоянными через государственные изменения вам действительно нужно 10k пишет второй устойчивым

— Уэйд Арнольд

8

Уэйд, как вы, ребята, справляетесь с гарантиями сообщений? Вы упоминаете: (оповещения по электронной почте / смс, обнаружение мошенничества, низкий остаток средств и т. д.), я предполагаю, что они потенциально отправляются удаленным участникам? Как вы обеспечиваете эти операции на самом деле? Что делать, если во время обработки предупреждения о мошенничестве произошел сбой узла? Это навсегда? Есть ли у вас в конечном итоге последовательная система, которая очищает ее? Спасибо!

— Джеймс

2

Хороший вопрос, Джеймс. Очевидно, что он вписывается в систему, где ответ не требуется срочно. Например, вы можете обрабатывать счета кредитных карт; вычислить; отправить электронное письмо и т. д. Мне действительно интересно, как эти вещи (транзакции) обрабатываются, когда требуется ответ. В конце; если запрос сделан извне (пользователь интернета; представитель колл-центра и т. д.); он или она ждет ответа. Как я могу быть уверен, что подзадачи (которые выполняются асинхронно) выполняются; в транзакции XA, чтобы я мог вернуть ответ?

— Каан Гы

44

Мы используем Akka для асинхронной обработки вызовов REST - вместе с асинхронным веб-сервером (на основе Netty) мы можем достичь 10-кратного улучшения числа пользователей, обслуживаемых на узел / сервер, по сравнению с традиционным потоком на модель запроса пользователя.

Сообщите своему боссу, что ваш счет за хостинг в AWS уменьшится в 10 раз, и это не составит труда! Тссс ... не говорите это Амазонке, хотя ... :)

— piotrga
источник

3

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

— piotrga

8

Я предполагаю, что звонки с высокой задержкой, низкой пропускной способностью? Как делать звонки на другие серверы, ожидая ответа (прокси)?

— StaxMan

38

Мы используем Akka в крупномасштабном проекте Telco (к сожалению, я не могу раскрыть много деталей). Актеры Akka развертываются и доступны удаленно через веб-приложение. Таким образом, у нас есть упрощенная модель RPC, основанная на протобуфере Google, и мы достигаем параллелизма, используя Akka Futures. До сих пор эта модель работала блестяще. Одно замечание: мы используем Java API.

— Лучано Фиандезио
источник

Не могли бы вы рассказать нам немного больше, пожалуйста? Afaik Фьючерсы не могут быть отправлены по проводам (сериализовано). Ты используешь много фьючерсов и мало актеров или смесь двух или ...? Вы используете protobuf для всей сериализации и отправляете актёрам сообщения?

— Актау

Кажется, что это можно было бы сделать так же легко без Акки.

— Эрик Каплун

1

TDC является телекоммуникационной компанией в случае Фиддезио.

— Роман Каган

37

Если вы абстрагируете сервер чата до уровня, то вы получите ответ.

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

Итак, примеры - это вещи, которые требуют разных уровней надежности и надежности обмена сообщениями:

Чат-сервер
Сетевой уровень для MMO
Финансовый насос данных
Система уведомлений для iPhone / мобильного / любого приложения
REST Server
Может быть, что-то похожее на WebMachine (думаю)

Хорошая вещь об Akka - выбор, который он предоставляет для постоянства, это реализация STM, сервер REST и отказоустойчивость.

Не раздражайтесь на примере сервера чата, думайте об этом как о примере определенного класса решений.

Со всей их превосходной документацией, я чувствую, что пробел - это именно этот вопрос, варианты использования и примеры. Имея в виду, примеры нетривиальны.

(Написанный только с опытом просмотра видео и воспроизведения с источником, я ничего не реализовал, используя akka.)

— tylerweir
источник

2

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

— StaxMan

Хотите знать, как REST сервер подходит здесь? Вы упоминаете об этом в контексте асинхронного сервера в стиле Node.js? Спасибо, что поделились примерами использования. Я нашел их полезными.

— software.wikipedia

24

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

Вопрос с Akka действительно больше «что вы не можете сделать с Akka». Его способность интегрироваться с мощными средами, его мощная абстракция и все аспекты отказоустойчивости делают его очень полным набором инструментов.

— rossputin
источник

Итак, какой аспект вам нравится больше всего, если вам пришлось выбирать? Существующая интеграция для других платформ, автоматическая отказоустойчивость или что-то еще?

— StaxMan

6

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

— отдыхом

Не могли бы вы рассказать, как проходит поток сообщений? Является ли пользователь человеком в ремонтной мастерской и вводит подробности о сбое в http-форму, а затем отправляет данные на сервер. Создает ли это сообщение, которое обрабатывается akka? Что делать с этим сообщением? Извлечь введенную информацию для запроса к базе данных, а затем поставить в очередь ответ, чтобы отправить его обратно в веб-интерфейс?

— прибой

24

Вы можете использовать Akka для нескольких разных вещей.

Я работал над сайтом, где я перенес технологический стек в Scala и Akka. Мы использовали его практически для всего, что происходило на сайте. Даже если вы считаете, что пример чата плох, все они в основном одинаковы:

Живые обновления на сайте (например, просмотры, лайки, ...)
Показаны живые комментарии пользователей
Службы уведомлений
Поиск и все другие виды услуг

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

Я также использую Akka для приложения для автоматического определения печатной платы с возможностью масштабирования от ноутбука до центра обработки данных. Чем больше энергии вы дадите, тем лучше будет результат. Это очень трудно реализовать, если вы пытаетесь использовать обычный параллелизм, потому что Akka также дает вам прозрачность местоположения.

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

А после того, как Google Reader закрылся, я начал с чтения RSS, конечно же, используя Akka. Все дело в инкапсулированных услугах для меня. В заключение: модель актера сама по себе - это то, что вам следует принять в первую очередь, и Akka - очень надежная структура, помогающая вам реализовать ее с большим количеством преимуществ, которые вы получите в процессе работы.

— Джоа Эберт
источник

Здравствуйте, Джо, не могли бы вы объяснить, как сообщения используются для обновления сайта? У вас есть одна система для автора контента; он создает новую статью и нажимает сохранить. Создает ли это сообщение, которое отправляется на несколько серверов, которые обрабатывают входящий трафик. Каждый сервер обрабатывает сообщение об обновлении, как только может. Каждый свежий браузер-запрос получает обновленную версию страницы? Спасибо

— серфмагл

18

Мы используем akka с плагином для верблюдов, чтобы распространять результаты анализа и анализа трендов для twimpact.com . Мы должны обрабатывать от 50 до 1000 сообщений в секунду. В дополнение к многоузловой обработке с использованием верблюда, она также используется для распределения работы на одном процессоре среди нескольких рабочих для обеспечения максимальной производительности. Работает довольно хорошо, но требует некоторого понимания того, как справляться с заторами.

— Матиас Л. Югель
источник

Вы также используете отказоустойчивость Акки?

— Эрик Каплун

Как насчет Spark Streaming, если у нас есть доступ к кластеру Spark?

— Скьягини

18

Я пробовал свои силы на Akka (Java API). Я попытался сравнить модель параллелизма Akka на основе акторов с моделью простой параллелизма Java (классы java.util.concurrent).

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

Для Akka я использовал BalancedDispatcher (для балансировки нагрузки между потоками) и RoundRobinRouter (чтобы ограничить действующие субъекты функций). Для Java я использовал простую технику форка соединения (реализованную без какого-либо алгоритма кражи работы), которая бы раскручивала карту / сокращала выполнение и объединяла результаты. Промежуточные результаты содержались в блокирующих очередях, чтобы сделать соединение как можно более параллельным. Возможно, если я не ошибаюсь, это каким-то образом имитирует концепцию «почтового ящика» актеров Акки, где они получают сообщения.

Наблюдение: До средних нагрузок (~ 50000 входных струн) результаты были сопоставимы, слегка варьируя в разные итерации. Однако, поскольку я увеличил свою нагрузку до ~ 100000, это повлияло на решение Java. Я настроил решение Java с 20-30 потоками при этом условии, и оно не получилось на всех итерациях.

Увеличение нагрузки до 1000000 также оказалось роковым для Акки. Я могу поделиться кодом со всеми, кто хочет пройти перекрестную проверку.

Поэтому мне кажется, что Akka масштабируется лучше, чем традиционное многопоточное решение Java. И, вероятно, причина кроется в магии Скалы.

Если я могу смоделировать проблемную область как передачу сообщений, управляемую событиями, я думаю, что Akka - хороший выбор для JVM.

Тест проводился на: версии Java: 1.6 IDE: Eclipse 3.7 Windows Vista 32 бит. 3 ГБ оперативной памяти. Процессор Intel Core i5, тактовая частота 2,5 ГГц

Обратите внимание, проблемный домен, используемый для теста, можно обсудить, и я постарался быть настолько справедливым, насколько позволял мой уровень знания Java :-)

— сутану далуи
источник

3

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

— n1r3

3

Я также хотел бы код, вы можете опубликовать ссылку на GitHub?

— Гаутам

Спасибо за Ваш интерес. К сожалению, у меня есть некоторые проблемы с настройкой репозитория github. Если вы можете дать мне свою электронную почту, я могу отправить по исходному коду. И сожалеет о позднем ответе!

— Сутану Далуи

@sutanudalui У вас еще есть код, если можно, я могу поделиться своей электронной почтой?

— Джей

16

Мы используем Akka в разговорных диалоговых системах ( primetalk ). Как внутри, так и снаружи. Для одновременного запуска большого количества телефонных каналов на одном узле кластера, очевидно, необходимо иметь многопоточную инфраструктуру. Акка работает просто отлично. У нас был предыдущий кошмар с java-параллелизмом. А с Аккой это как качели - просто работает. Надежный и надежный. 24 * 7, нон-стоп.

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

Для создания взаимосвязей сложной обработки сигналов мы используем SynapseGrid . Он имеет преимущество проверки во время компиляции DataFlow в сложных системах акторов.

— Арсений Жижелев
источник

14

Я недавно реализован каноническое отображение-свертка пример в Акко: количество слов. Так что это один из вариантов использования Akka: лучшая производительность. Это было больше экспериментом с актерами JRuby и Akka, чем с чем-либо еще, но это также показывает, что Akka - это не только Scala или Java: он работает на всех языках поверх JVM.

— Даниэль Рибейро
источник

Знаете ли вы, что отвечает за лучшую производительность (а также по сравнению с какой альтернативой)? Это связано с использованием JRuby в JVM (против нативного Ruby), скалибилией из-за неблокирующего ввода-вывода или чего-то еще?

— StaxMan

2

Сравнение, которое я написал, было следующим: Jruby - это последовательный VS Jruby с актерами. Поэтому единственное, что может нести ответственность за более быстрое исполнение - это участие актеров. В экспериментах не было ввода-вывода (файл загружается с диска, но это делается до того, как будет установлен таймер эталонного теста).

— Даниэль Рибейро

Недавно я также реализовал пример уменьшения карты, но это просто ванильная java github.com/chaostheory/jibenakka

— chaostheory