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

515

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

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

  • 10
    Не проще ли начать с проблемы и найти решение для нее, чем иметь решение и искать проблему для ее решения? Я предполагаю, что вместо использования RMI, Akka и его актеры выглядят намного проще / проще для написания кода.
  • 62
    Да, если бы у меня была конкретная проблема, которую нужно решить. Я не ищу «предлога для использования Akka» каким-либо образом, но мне интересно узнать немного больше. Это также может помочь решить будущие проблемы, но в основном это для непрерывного процесса обучения.
Показать ещё 5 комментариев
Теги:
asynchronous
akka
use-case

12 ответов

286
Лучший ответ

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

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

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

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

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

Я очень доволен каркасом и становится стандартом defacto для подключенных систем, которые мы создаем.

  • 12
    В чем, на ваш взгляд, преимущество этого подхода по сравнению с использованием бэкэнда обмена сообщениями (например, ActiveMQ) для передачи сообщений?
  • 26
    Продукты MQ действительно предназначены для другого случая использования. разные гарантии и очень разные характеристики. Продукты MQ требуют большой настройки, вы не будете использовать очереди в таком продукте так же, как вы используете объекты. Актеры - это люди первого класса в akka, вы используете их по своему усмотрению, подобно тому, как вы бы использовали объекты, поэтому в вашей модели программирования намного меньше издержек, как в настройке. Продукты MQ, которые вы бы использовали в большей степени для интеграции с другими внешними системами, а не для создания «внутренних компонентов» системы, для которой вы бы использовали актеров.
Показать ещё 3 комментария
179

Отказ от ответственности: я являюсь PO для Akka

Помимо предложения concurrency smorgasbord, который намного проще рассуждать и получать правильные (актеры, агенты, поток данных concurrency) и с помощью concurrency управления в виде STM.

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

  • Обработка транзакций (онлайн игры, финансы, статистика, ставки, социальные сети, телекоммуникации,...)
    • масштабирование, масштабирование, отказоустойчивость /HA
  • Бэкэнд службы (любая отрасль, любое приложение)
    • служба REST, SOAP, cometd и т.д.
    • действует как уровень концентратора сообщений/интеграции
    • масштабирование, масштабирование, отказоустойчивость /HA
  • Snap-in concurrency/parallelism (любое приложение)
    • Правильно
    • Простота работы и понимания
    • Просто добавьте банки в существующий проект JVM (используйте Scala, Java, Groovy или JRuby)
  • Пакетная обработка (любая отрасль)
    • Интеграция верблюдов для подключения к источникам пакетных данных
    • Актеры разделяют и захватывают пакетные рабочие нагрузки
  • Коммуникационный концентратор (телекоммуникации, веб-медиа, мобильные носители)
    • масштабирование, масштабирование, отказоустойчивость /HA
  • Игровой сервер (онлайн-игры, ставки)
    • масштабирование, масштабирование, отказоустойчивость /HA
  • BI/datamining/хруст общего назначения
    • масштабирование, масштабирование, отказоустойчивость /HA
  • вставьте другие приятные варианты использования здесь.
  • 9
    Я понимаю преимущества Futures и STM, но не нахожу хороших вариантов использования для актеров. В чем преимущество использования Actors против нескольких серверов приложений за балансировщиком нагрузки для игры или сервера ставок?
  • 3
    Что такое «ПО»?
Показать ещё 1 комментарий
72

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

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

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

  • 1
    Так что справедливо ли говорить, что это случай (некоторых) запросов с большой задержкой, когда один поток на запрос не будет хорошо масштабироваться?
  • 7
    Я думаю, что важной частью программирования актера в целом является поток сообщений. Как только вы начинаете концептуализацию потоков данных, которые не имеют побочных эффектов, вы просто хотите, чтобы на каждом узле происходило как можно больше потоков. Это сильно отличается от высокопроизводительных вычислений, если у вас есть полуоднородные задания, которые не отправляют сообщения и занимают много времени для обработки. Я думаю, что реализация Фибоначчи, основанная на актерах, является очень ограничивающим примером, поскольку она не демонстрирует, зачем использовать актеров, а только то, что актеры парализуют такты. Подумайте о архитектуре на основе событий для вариантов использования.
Показать ещё 5 комментариев
35

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

Расскажите своему боссу, что ваш счет хостинга AWS упадет в 10 раз, и это нелегко! Shh... не скажи это Амазонке, хотя...:)

  • 3
    И я забыл упомянуть, что монадная природа фьючерсов akka, которая приводит к намного более чистому параллельному коду, сэкономила нам тысячи на обслуживании кода ...
  • 7
    Я предполагаю, что звонки с высокой задержкой, низкой пропускной способностью? Как делать звонки на другие серверы, ожидая ответа (прокси)?
32

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

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

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

Akka предоставляет систему обмена сообщениями, которая сродни умению Эрланг "пусть он вредит".

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

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

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

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

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

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

  • 2
    Спасибо - я не имел ввиду, что чат-сервер обязательно плохой, просто мне нужны дополнительные примеры; легче получить лучшее представление о потенциале.
  • 0
    Хотите знать, как REST сервер подходит здесь? Вы упоминаете об этом в контексте асинхронного сервера в стиле Node.js? Спасибо, что поделились примерами использования. Я нашел их полезными.
20

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

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

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

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

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

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

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

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

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

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

  • 0
    Так какой аспект вам нравится больше всего, если вам пришлось выбирать? Существующая интеграция для других платформ, автоматическая отказоустойчивость или что-то еще?
  • 6
    С личной точки зрения это повышенный уровень абстракции, который Акка приносит на стол, который мне нравится больше всего. С точки зрения предприятия это возможности интеграции. Надо зарабатывать на жизнь, и Акка очень хорошо занимается бизнесом и отдыхом :-)
Показать ещё 1 комментарий
17

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

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

Я пробовал свои руки на Akka (Java api). Я попытался сравнить модель concurrency с акк-актером на основе модели Java concurrency модели (java.util.concurrent).

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

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

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

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

Итак, для меня, похоже, Akka масштабируется лучше, чем традиционное многопоточное решение Java. И, вероятно, причина в том, что под магией капота Scala.

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

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

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

  • 3
    «Я могу поделиться кодом со всеми, кто хочет пройти перекрестную проверку». Я хотел бы, если вы не возражаете.
  • 3
    Я также хотел бы код, вы можете опубликовать ссылку на GitHub?
Показать ещё 2 комментария
15

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

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

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

13

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

  • 0
    Знаете ли вы, что отвечает за лучшую производительность (а также по сравнению с какой альтернативой)? Это связано с использованием JRuby в JVM (против нативного Ruby), скалибилией из-за неблокирующего ввода-вывода или чего-то еще?
  • 2
    Сравнение, которое я написал, было следующим: Jruby - это последовательный VS Jruby с актерами. Поэтому единственное, что может нести ответственность за более быстрое исполнение - это участие актеров. В экспериментах не было ввода-вывода (файл загружается с диска, но это делается до того, как будет установлен таймер теста).
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню