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

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

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

12 ответов


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

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

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

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

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

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


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

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

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

  1. обработка транзакций (онлайн азартные игры, финансы, статистика, ставки, социальные медиа, телеком ...)
    • масштабирование, масштабирование, отказоустойчивость / Ха
  2. Service backend (любая отрасль, любое приложение)
    • остальные сервисы, SOAP, принятый в cometd и т. д.
    • действуйте как концентратор сообщений / уровень интеграции
    • масштабирование, масштабирование, отказоустойчивость / HA
  3. Snap-in параллелизм / параллелизм ( любое приложение )
    • правильно
    • просто работать и понимать
    • просто добавьте банки в существующий проект JVM (используйте Scala, Java, Groovy или JRuby)
  4. пакетная обработка ( любая отрасль )
    • интеграция Camel для подключения к источникам пакетных данных
    • актеры разделяют и покоряют пакетные рабочие нагрузки
  5. Communications hub (Телекоммуникации, веб-медиа, мобильные медиа )
    • масштабирование, масштабирование, отказоустойчивость / HA
  6. Игровой сервер (онлайн-игры, ставки)
    • масштабирование, масштабирование, отказоустойчивость / Ха
  7. BI / datamining / общецелевой хрустеть
    • масштабирование, масштабирование, отказоустойчивость / HA
  8. вставьте другие хорошие варианты использования здесь

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

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

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


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

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


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

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

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

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

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

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

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

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


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


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

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


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

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

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

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

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

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

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


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


Я пробовал свои руки на Akka (Java api). Я попытался сравнить модель параллелизма актера Akka с моделью простого параллелизма Java (java.утиль.параллельные классы).

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

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

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

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

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

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


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

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

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


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