Я слышал много бред о Akka framework (платформа услуг Java/Scala), но до сих пор не видел много фактических примеров использования, на которые это было бы полезно. Поэтому мне было бы интересно узнать о том, что разработчики использовали его успешно.
Только одно ограничение: пожалуйста, не включайте случай написания чат-сервера. (почему? поскольку это было использовано в качестве примера для множества подобных вещей)
Я использовал его до сих пор в двух реальных проектах очень успешно. оба находятся в поле информации о дорожном движении в режиме реального времени (трафик, как в автомобилях на автомагистралях), распределяются по нескольким узлам, объединяются сообщения между несколькими сторонами, надежные бэкэнд-системы. Я не имею права давать подробные сведения о клиентах, когда я получу ОК, возможно, его можно добавить в качестве ссылки.
Акка действительно проделал эти проекты, хотя мы начали, когда это было на версии 0.7. (мы используем scala кстати)
Одним из больших преимуществ является легкость, с которой вы можете составить систему из актеров и сообщений, практически без котельных, она очень хорошо масштабируется без всех сложностей ручного проката, и вы получаете асинхронное сообщение, проходящее между объектами почти бесплатно.
Это очень хорошо при моделировании любого типа обработки асинхронных сообщений. Я бы предпочел написать любой тип (веб-сервис) системы в этом стиле, чем любой другой стиль. (Вы когда-нибудь пытались написать асинхронный веб-сервис (серверная сторона) с JAX-WS? Что много сантехники). Поэтому я бы сказал, что любая система, которая не хочет висеть на одном из своих компонентов, потому что все неявно называется синхронными методами и что один компонент блокирует что-то. Он очень стабилен, и решение "отказ от аварии" + "диспетчер" к отказу действительно работает хорошо. Все легко настраивается программно и не сложно для unit test.
Тогда есть отличные дополнительные модули. Модуль Camel действительно хорошо подключается к Akka и обеспечивает такую легкую разработку асинхронных сервисов с настраиваемыми конечными точками.
Я очень доволен каркасом и становится стандартом defacto для подключенных систем, которые мы создаем.
Отказ от ответственности: я являюсь PO для Akka
Помимо предложения concurrency smorgasbord, который намного проще рассуждать и получать правильные (актеры, агенты, поток данных concurrency) и с помощью concurrency управления в виде STM.
Вот несколько вариантов использования, которые вы можете рассмотреть:
Пример того, как мы его используем, будет в очереди приоритетов транзакций дебетовой/кредитной карты. У нас есть миллионы, и усилия работы зависят от типа входных строк. Если транзакция имеет тип CHECK, у нас очень мало обработки, но если это точка продажи, тогда есть много дел, таких как объединение с метаданными (категория, ярлык, теги и т.д.) И предоставление услуг (оповещения по электронной почте/смс, обнаружение мошенничества, низкий баланс средств и т.д.). На основе типа ввода мы составляем классы различных признаков (называемых mixins), необходимых для обработки задания, а затем выполняем работу. Все эти задания попадают в одну очередь в режиме реального времени из разных финансовых учреждений. После очистки данных он отправляется в разные хранилища данных для сохранения, аналитики или для подключения к сокетному соединению или для подхвата кометного актера. Рабочие участники постоянно балансируют нагрузку, поэтому мы можем как можно быстрее обрабатывать данные. Мы также можем оснастить дополнительные сервисы, модели настойчивости и stm для принятия важных решений.
Сообщение стиля Erlang OTP, переданное на JVM, создает отличную систему для разработки систем реального времени на плечах существующих библиотек и серверов приложений.
Akka позволяет вам выполнять передачу сообщений так же, как в традиционном esb, но со скоростью! Он также предоставляет вам инструменты в рамках управления огромным количеством пулов актеров, удаленных узлов и отказоустойчивости, которые необходимы для вашего решения.
Мы используем Akka для асинхронного обработки вызовов REST - вместе с асинхронным веб-сервером (Netty-based) мы можем добиться 10-кратного улучшения числа пользователей, обслуживаемых на node/server, по сравнению с традиционным потоком на модель пользовательского запроса.
Расскажите своему боссу, что ваш счет хостинга AWS упадет в 10 раз, и это нелегко! Shh... не скажи это Амазонке, хотя...:)
Если вы отмените чат-сервер до уровня, тогда вы получите ответ.
Akka предоставляет систему обмена сообщениями, которая сродни умению Эрланг "пусть он вредит".
Таким образом, примеры - это вещи, которые требуют разных уровней долговечности и надежности обмена сообщениями:
Хорошие вещи в Akka - это выбор, который он дает для сохранения, его внедрение STM, сервер REST и отказоустойчивость.
Не раздражайтесь примером чат-сервера, подумайте об этом как пример определенного класса решений.
Со всей своей превосходной документацией я чувствую, что этот пробел - это точный вопрос, примеры использования и примеры. Имея в виду примеры, нетривиальны.
(Написано только опытом просмотра видео и игры с источником, я ничего не реализовал с помощью akka.)
Мы используем Akka в крупномасштабном проекте Telco (к сожалению, я не могу раскрывать много деталей). Активные участники Akka развернуты и доступны удаленно с помощью веб-приложения. Таким образом, у нас есть упрощенная модель RPC, основанная на Google protobuffer, и мы достигаем parallelism с использованием Akka Futures. До сих пор эта модель работала блестяще. Одна нота: мы используем Java API.
Мы используем Akka в нескольких проектах на работе, наиболее интересная из которых связана с ремонтом автомобилей. В первую очередь в Великобритании, но теперь она распространяется в США, Азии, Австралии и Европе. Мы используем актеров для обеспечения того, чтобы информация об аварийном восстановлении предоставлялась в режиме реального времени, чтобы обеспечить безопасный и экономически эффективный ремонт транспортных средств.
Вопрос с Аккой действительно больше "что вы не можете сделать с Аккой". Его способность интегрироваться с мощными фреймворками, его мощная абстракция и все аспекты отказоустойчивости делают ее очень всеобъемлющим инструментарием.
Вы можете использовать Akka для нескольких разных вещей.
Я работал на веб-сайте, где я перенес стек технологии в Scala и Akka. Мы использовали его для почти всего, что произошло на веб-сайте. Даже если вы можете подумать, что пример чата плох, все они в основном одинаковы:
В частности, живые обновления просты, так как они сводятся к тому, что пример чата ist. Часть услуг - еще одна интересная тема, потому что вы можете просто использовать удаленные исполнители, и даже если ваше приложение не кластерно, вы можете легко развернуть его на разных машинах.
Я также использую Akka для приложения для автотрассировки печатной платы с идеей возможности масштабирования с ноутбука в центр обработки данных. Чем больше вы его дадите, тем лучше будет результат. Это очень сложно реализовать, если вы попытаетесь использовать обычный concurrency, потому что Akka дает вам также прозрачность местоположения.
В настоящее время в качестве проекта свободного времени я создаю веб-структуру, используя только актеров. Опять же, преимущества - это масштабируемость от одной машины до целого кластера машин. Кроме того, использование подхода, управляемого сообщениями, делает ваше программное обеспечение ориентированным с самого начала. У вас есть все эти приятные компоненты, разговаривающие друг с другом, но не обязательно знающие друг друга, живущие на одной машине, даже в том же центре обработки данных.
И поскольку Google Reader закрылся, я начал с чтения RSS, используя Akka, конечно. Для меня это касается инкапсулированных сервисов. В качестве вывода: сама модель актера - это то, что вы должны первыми принять, и Akka - очень надежная структура, помогающая вам реализовать ее с большим количеством преимуществ, которые вы получите на этом пути.
Мы используем akka с плагином для верблюдов, чтобы распределить наш анализ и обработку тренда на twimpact.com. Мы должны обрабатывать от 50 до 1000 сообщений в секунду. В дополнение к обработке multi- node с верблюдом он также используется для распределения работы на одном процессоре с несколькими рабочими для максимальной производительности. Работает неплохо, но требует некоторого понимания того, как обрабатывать скопления.
Я пробовал свои руки на 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: -)
Мы используем Akka в устных диалоговых системах (primetalk). И внутри, и снаружи. Для одновременного запуска большого количества каналов телефонии в одном кластере node, очевидно, необходимо иметь некоторую многопоточную структуру. Акка работает просто отлично. У нас был предыдущий кошмар с java- concurrency. А с Аккой это похоже на качели - это просто работает. Надежный и надежный. 24 * 7, без остановок.
Внутри канала есть поток событий в реальном времени, которые обрабатываются параллельно. В частности: - длительное автоматическое распознавание речи - выполняется с участием актера; - производитель аудиоданных, который смешивает несколько источников звука (включая синтезированную речь); - преобразование текста в речь - это отдельный набор участников, разделяемых между каналами; - семантическая и обработка знаний.
Чтобы сделать взаимосвязи сложной обработки сигналов, мы используем SynapseGrid. Он имеет преимущество во время компиляции данных DataFlow в сложных игровых системах.
Недавно я реализовал пример канонического отображения карты в Akka: количество слов. Так что это один случай использования Akka: лучшая производительность. Это был скорее эксперимент JRuby и Акка, чем все остальное, но также показывает, что Akka не только Scala или только Java: это работает на всех языках поверх JVM.