Гарний випадок використання Akka [закрито]

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

Лише одне обмеження: будь ласка, не включайте випадки написання сервера чату. (чому? оскільки це було використано як приклад для багатьох подібних речей)

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

Akka справді працював над цими проектами, навіть якщо ми починали, коли він був у версії 0.7. (ми до речі використовуємо шкалу)

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

Це дуже добре при моделюванні будь-якого типу асинхронної обробки повідомлень. Я вважаю за краще писати будь-який тип (веб) служб у цьому стилі, ніж будь-який інший стиль. (Ви коли-небудь намагалися написати асинхронну веб-службу (сторону сервера) з JAX-WS? Це багато сантехніки). Тому я б сказав, що будь-яка система, яка не хоче зависати на одному зі своїх компонентів, тому що все неявно називається синхронними методами, і що один компонент щось замикає. Це дуже стабільно, і рішення про відмову керівника "нехай-крах" + відмовляє дійсно добре. Налаштувати все просто програмно і не важко для тестування.

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

Я дуже задоволений рамкою, і вона стає стандартом дефакто для підключених нами систем.

Відмова: Я - ОП для Акки

Окрім того, пропонуйте смуговий борд за одночасність, який набагато простіше міркувати та виправляти (актори, агенти, одночасність потоку даних) та керувати сумісністю у формі STM.

Ось кілька випадків використання, які ви можете врахувати:

1. Обробка транзакцій (онлайн-ігри, фінанси, статистика, ставки, соціальні медіа, телекомунікації ...)
   • збільшення масштабу, масштабування, відмовостійкість / HA
2. Сервісний сервіс (будь-яка галузь, будь-яка програма)
   • сервіс REST, SOAP, cometd тощо
   • виконувати роль концентраційного центру / рівня інтеграції
   • збільшення масштабу, масштабування, відмовостійкість / HA
3. Одночасне паралельність / паралелізм (будь-яка програма)
   • Правильно
   • Простий у роботі та розумінні
   • Просто додайте банки до існуючого проекту JVM (використовуйте Scala, Java, Groovy або JRuby)
4. Пакетна обробка (будь-яка галузь)
   • Інтеграція верблюдів для підключення до пакетних джерел даних
   • Актори ділять і підкорюють партійне навантаження
5. Центр зв'язку (телекомунікації, веб-медіа, мобільні медіа)
   • збільшення масштабу, масштабування, відмовостійкість / HA
6. Ігровий сервер (онлайн-ігри, ставки)
   • збільшення масштабу, масштабування, відмовостійкість / HA
7. BI / обробка даних / хрускіт загального призначення
   • збільшення масштабу, масштабування, відмовостійкість / HA
8. вставити сюди інші приємні випадки використання

Приклад того, як ми його використовуємо, буде на черзі пріоритетних операцій з дебетовою / кредитною карткою. У нас їх мільйони, а зусилля роботи залежать від типу вхідного рядка. Якщо транзакція має тип CHECK, ми обробляємо дуже мало, але якщо це точка продажу, то є багато чого зробити, наприклад об'єднати з метаданими (категорія, мітка, теги тощо) та надати послуги (сповіщення електронною поштою / sms, виявлення шахрайства, низький баланс коштів тощо). Виходячи з типу введення, ми складаємо класи різних ознак (звані міксинами), необхідні для виконання завдання, а потім виконання роботи. Усі ці робочі місця надходять в одну і ту ж чергу в режимі реального часу від різних фінансових установ. Після очищення даних вони надсилаються в різні сховища даних для наполегливості, аналітики, або підштовхуються до розетки або до актора комети Lift. Працюючі суб’єкти постійно самонавантажують балансування роботи, щоб ми могли обробити дані якомога швидше. Ми також можемо оснастити додаткові сервіси, моделі збереження таstm для критичних пунктів рішення.

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

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

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

Скажіть це своєму начальникові, що ваш рахунок на хостинг AWS знизиться в 10 разів, і це не просто! Шш ... не скажи це Амазонії, хоча ... :)

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

Якщо ви абстрагуєте сервер чату до рівня, то отримаєте відповідь.

Акка пропонує систему обміну повідомленнями, яка схожа на менталітет Ерланга "нехай вона зазнає краху".

Тому приклади - речі, для яких потрібен різний рівень довговічності та надійності обміну повідомленнями:

• Сервер чату
• Мережевий рівень для MMO
• Насос фінансових даних
• Система сповіщень для iPhone / мобільного / будь-якого додатка
• REST Server
• Можливо, щось схоже на WebMachine (здогадуйтесь)

Приємними речами в Akka є вибір, який він надає для постійності, це реалізація STM, сервер REST та стійкість до відмов.

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

Зважаючи на всю їх чудову документацію, я відчуваю, що це невідповідність саме цього питання, випадків використання та прикладів. Маючи на увазі, приклади нетривіальні.

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

Ми використовуємо Akka в кількох проектах на роботі, найцікавіший з яких пов'язаний з ремонтом аварійних ситуацій. Перш за все у Великобританії, але зараз поширюється на США, Азію, Австралазію та Європу. Ми використовуємо акторів, щоб забезпечити надання інформації про ремонт аварій у режимі реального часу для забезпечення безпечного та економічного ремонту транспортних засобів.

Питання з Аккою насправді більше "чого не можна зробити з Аккою". Його здатність інтегруватися з потужними рамками, потужна абстракція та всі аспекти відмовостійкості дають змогу зробити її дуже вичерпним інструментарієм.

Ви можете використовувати Акку для декількох речей.

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

• Актуальні оновлення на веб-сайті (наприклад, перегляди, подобається, ...)
• Показ живих коментарів користувачів
• Послуги оповіщення
• Пошук та всі інші види послуг

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

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

Зараз, будучи проектом у вільний час, я будую веб-рамки, використовуючи лише акторів. Знову переваги - масштабованість від однієї машини до цілої групи машин. Крім того, використання підходу, керованого повідомленнями, робить сервіс програмного забезпечення орієнтованим з самого початку. У вас є всі ті приємні компоненти, які розмовляєте один з одним, але не обов'язково знаєте один одного, живете на одній машині, навіть не в одному центрі обробки даних.

А оскільки Google Reader вимкнувся, я почав із RSS-зчитувача, звичайно, використовуючи Akka. Це все про інкапсульовані послуги для мене. Як висновок: сама модель актора - це те, що вам слід спершу прийняти, а Акка - це дуже надійна основа, яка допомагає вам реалізувати її з великою кількістю переваг, які ви отримаєте на цьому шляху.

Ми використовуємо akka з його верблюжним плагіном для розповсюдження нашого аналізу та тенденції обробки для twimpact.com . Ми маємо обробляти від 50 до 1000 повідомлень в секунду. На додаток до багатовузлової обробки верблюдом він також використовується для розподілу роботи на одному процесорі на декількох працівників для досягнення максимальної продуктивності. Працює досить добре, але вимагає певного розуміння того, як поводитися із заторами.

Я пробував свої руки на Akka (Java api). Я спробував порівняти модель одночасності на основі актора Акки з моделлю звичайної Java паралельної валюти (класи Java).

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

Для Akka я використовував BalancedDispatcher (для врівноваження навантаження між потоками) та RoundRobinRouter (щоб утримувати ліміт для моїх дійових осіб). Для Java я використовував просту техніку приєднання до вилки (реалізовану без будь-якого алгоритму крадіжки роботи), яка б розщеплювала / скорочувала виконання та приєднувалась до результатів. Проміжні результати були проведені в блокуванні черг, щоб зробити з'єднання максимально паралельним. Можливо, якщо я не помиляюся, це якось імітувало б концепцію "поштової скриньки" акторів Акки, де вони отримують повідомлення.

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

Збільшення навантаження до 1000000, також було фатальним для Akka. Я можу поділитися кодом з усіма зацікавленими, щоб пройти перехресну перевірку.

Тож для мене, здається, Акка виходить краще, ніж традиційні багатопотокові рішення Java. І, мабуть, причина - магія Скали під капотом.

Якщо я можу моделювати проблемний домен як повідомлення, що керується подією, передаючи повідомлення, я вважаю, що Акка - це хороший вибір для JVM.

Тест виконується на версії Java: 1.6 IDE: Eclipse 3.7 32-бітний Windows Vista. 3 Гб оперативної пам’яті. Процесор Intel Core i5, тактова частота 2,5 ГГц

Зауважте, проблемний домен, використаний для тесту, може бути обговорений, і я намагався бути настільки ж справедливим, наскільки дозволяють мої знання Java :-)

Ми використовуємо Akka в системах розмовного діалогу ( приклад ). Як внутрішньо, так і зовні. Для того, щоб одночасно запускати багато каналів телефонії на одному вузлі кластера, очевидно, необхідно мати декілька багатопотокових кадрів. Акка працює просто ідеально. У нас були попередні кошмари з java-одночасністю. А з Аккою це просто як гойдалка - вона просто працює. Міцний і надійний. 24 * 7, без зупинки.

Усередині каналу є потік подій, які обробляються в режимі реального часу. Зокрема: - тривале автоматичне розпізнавання мовлення - робиться з актором; - виробник аудіовиходу, який змішує декілька джерел звуку (включаючи синтезовану мову); - перетворення тексту в мовлення - це окремий набір дійових осіб, що ділиться між каналами; - семантична та обробка знань.

Для здійснення взаємозв'язків складної обробки сигналів ми використовуємо SynapseGrid . Він має перевагу в перевірці даних DataFlow під час збирання в складних системах актора.

Нещодавно я реалізував приклад канонічного зменшення карт у Akka: Кількість слів. Тож це один випадок використання Akka: краща продуктивність. Це був скоріше експеримент акторів JRuby та Akka, ніж будь-що інше, але він також показує, що Akka - це не тільки Scala чи Java: вона працює на всіх мовах, крім JVM.