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