Bon cas d'utilisation pour Akka [fermé]

J'ai entendu beaucoup de délires sur le cadre Akka (plate-forme de service Java / Scala), mais jusqu'à présent, je n'ai pas vu de nombreux exemples réels de cas d'utilisation, ce serait bon. Je serais donc intéressé à entendre parler de ce que les développeurs ont utilisé avec succès.

Une seule limitation: veuillez ne pas inclure le cas de l'écriture d'un serveur de chat. (pourquoi? puisque cela a été abusé comme exemple pour beaucoup de choses similaires)

Je l'ai utilisé jusqu'à présent avec succès dans deux projets réels. les deux se situent dans le domaine de l'information sur le trafic en temps quasi réel (trafic comme dans les voitures sur les autoroutes), répartis sur plusieurs nœuds, intégrant des messages entre plusieurs parties, des systèmes backend fiables. Je ne suis pas encore libre de donner des détails sur les clients, quand j'obtiens le OK, il peut être ajouté comme référence.

Akka a vraiment réussi sur ces projets, même si nous avons commencé quand il était sur la version 0.7. (au fait, nous utilisons scala)

L'un des grands avantages est la facilité avec laquelle vous pouvez composer un système à partir d'acteurs et de messages avec presque aucun passe-partout, il évolue extrêmement bien sans toutes les complexités du filetage roulé à la main et vous obtenez un message asynchrone passant entre les objets presque gratuitement.

Il est très bon dans la modélisation de tout type de gestion de messages asynchrone. Je préférerais écrire n'importe quel type de système de services (Web) dans ce style que tout autre style. (Avez-vous déjà essayé d'écrire un service Web asynchrone (côté serveur) avec JAX-WS? C'est beaucoup de plomberie). Je dirais donc tout système qui ne veut pas s'accrocher à l'un de ses composants car tout est implicitement appelé à l'aide de méthodes synchrones, et qu'un composant se verrouille sur quelque chose. Il est très stable et la solution Let-it-crash + superviseur à l'échec fonctionne vraiment bien. Tout est facile à configurer par programme et pas difficile à tester.

Ensuite, il y a les excellents modules complémentaires. Le module Camel se connecte vraiment bien à Akka et permet un développement aussi simple de services asynchrones avec des points de terminaison configurables.

Je suis très satisfait du cadre et il devient une norme de facto pour les systèmes connectés que nous construisons.

Avertissement: je suis le bon de commande d'Akka

En plus d'offrir un smorgasbord de concurrence qui est beaucoup plus simple à raisonner et à obtenir correctement (acteurs, agents, concurrence de flux de données) et avec un contrôle de concurrence sous la forme de STM.

Voici quelques cas d'utilisation que vous pourriez envisager:

1. Traitement des transactions (jeux en ligne, finance, statistiques, paris, réseaux sociaux, télécoms, ...)
   • évoluer, évoluer, tolérance aux pannes / HA
2. Backend de service (toute industrie, toute application)
   • service REST, SAVON, cometd etc.
   • agir comme concentrateur de messages / couche d'intégration
   • évoluer, évoluer, tolérance aux pannes / HA
3. Simultanéité / parallélisme enfichable (n'importe quelle application)
   • Correct
   • Facile à travailler et à comprendre
   • Ajoutez simplement les jars à votre projet JVM existant (utilisez Scala, Java, Groovy ou JRuby)
4. Traitement par lots (toute industrie)
   • Intégration Camel pour se connecter aux sources de données par lots
   • Les acteurs divisent et conquièrent les charges de travail par lots
5. Pôle de communication (télécom, web média, média mobile)
   • évoluer, évoluer, tolérance aux pannes / HA
6. Serveur de jeux (jeux en ligne, paris)
   • évoluer, évoluer, tolérance aux pannes / HA
7. BI / datamining / crunching à usage général
   • évoluer, évoluer, tolérance aux pannes / HA
8. insérez ici d'autres jolis cas d'utilisation

Un exemple de la façon dont nous l'utilisons serait dans une file d'attente prioritaire de transactions par carte de débit / crédit. Nous en avons des millions et l'effort du travail dépend du type de chaîne d'entrée. Si la transaction est de type CHECK, nous avons très peu de traitement, mais s'il s'agit d'un point de vente, il y a beaucoup à faire, comme la fusion avec les métadonnées (catégorie, étiquette, tags, etc.) et fournir des services (alertes e-mail / sms, détection de fraude, solde de fonds bas, etc.). Sur la base du type d'entrée, nous composons des classes de divers traits (appelés mixins) nécessaires pour gérer le travail et ensuite effectuer le travail. Tous ces travaux entrent dans la même file d'attente en mode temps réel de différentes institutions financières. Une fois que les données sont nettoyées, elles sont envoyées à différents magasins de données pour la persistance, l'analyse, ou poussées vers une connexion socket, ou pour lever l'acteur comète. Les acteurs actifs équilibrent constamment le travail afin que nous puissions traiter les données le plus rapidement possible. Nous pouvons également intégrer des services supplémentaires, des modèles de persistance etstm pour les points de décision critiques.

Le message de style Erlang OTP transmis à la JVM constitue un excellent système pour développer des systèmes en temps réel sur les épaules des bibliothèques et des serveurs d'applications existants.

Akka vous permet de faire passer un message comme vous le feriez dans un traditionnel esbmais avec rapidité! Il vous fournit également des outils dans le cadre pour gérer la grande quantité de pools d'acteurs, de nœuds distants et de tolérance aux pannes dont vous avez besoin pour votre solution.

Nous utilisons Akka pour traiter les appels REST de manière asynchrone - avec le serveur Web asynchrone (basé sur Netty), nous pouvons améliorer de 10 fois le nombre d'utilisateurs servis par nœud / serveur, par rapport au modèle de demande de thread traditionnel par utilisateur.

Dites à votre patron que votre facture d'hébergement AWS va chuter du facteur 10 et c'est une évidence! Chut ... ne le dites pas à Amazon cependant ... :)

Nous utilisons Akka dans un projet Telco à grande échelle (malheureusement, je ne peux pas divulguer beaucoup de détails). Les acteurs Akka sont déployés et accessibles à distance par une application Web. De cette façon, nous avons un modèle RPC simplifié basé sur Google protobuffer et nous réalisons le parallélisme en utilisant Akka Futures. Jusqu'à présent, ce modèle a parfaitement fonctionné. Une remarque: nous utilisons l'API Java.

Si vous extrayez le serveur de chat d'un niveau, vous obtenez la réponse.

Akka fournit un système de messagerie qui s'apparente à la mentalité de "laisser tomber" d'Erlang.

Les exemples sont donc des choses qui nécessitent différents niveaux de durabilité et de fiabilité de la messagerie:

• Serveur de chat
• Couche réseau pour un MMO
• Pompe de données financières
• Système de notification pour iPhone / mobile / n'importe quelle application
• Serveur REST
• Peut-être quelque chose qui ressemble à WebMachine (devinez)

Les bonnes choses à propos d'Akka sont les choix qu'il offre pour la persistance, c'est l'implémentation STM, le serveur REST et la tolérance aux pannes.

Ne vous fâchez pas avec l'exemple d'un serveur de chat, pensez-y comme un exemple d'une certaine classe de solution.

Avec toute leur excellente documentation, j'ai l'impression qu'une lacune est cette question exacte, les cas d'utilisation et les exemples. Garder à l'esprit que les exemples ne sont pas anodins.

(Écrit avec une seule expérience de regarder des vidéos et de jouer avec la source, je n'ai rien mis en œuvre en utilisant akka.)

Nous utilisons Akka dans plusieurs projets au travail, dont le plus intéressant est lié à la réparation de crash de véhicule. Principalement au Royaume-Uni, mais s'étend désormais aux États-Unis, en Asie, en Australasie et en Europe. Nous utilisons des acteurs pour garantir que les informations sur les réparations après accident sont fournies en temps réel pour permettre la réparation sûre et rentable des véhicules.

La question avec Akka est vraiment plus «que ne pouvez-vous pas faire avec Akka». Sa capacité à s'intégrer à des frameworks puissants, sa puissante abstraction et tous les aspects de tolérance aux pannes en font une boîte à outils très complète.

Vous pouvez utiliser Akka pour plusieurs types de choses.

Je travaillais sur un site Web, où j'ai migré la pile technologique vers Scala et Akka. Nous l'avons utilisé pour à peu près tout ce qui s'est passé sur le site Web. Même si vous pensez qu'un exemple de chat est mauvais, tous sont fondamentalement les mêmes:

• Mises à jour en direct sur le site Web (par exemple vues, likes, ...)
• Affichage des commentaires des utilisateurs en direct
• Services de notification
• Recherche et tous autres types de services

En particulier, les mises à jour en direct sont faciles car elles se résument à ce qu'est un exemple de chat. La partie services est un autre sujet intéressant car vous pouvez simplement choisir d'utiliser des acteurs distants et même si votre application n'est pas en cluster, vous pouvez la déployer facilement sur différentes machines.

J'utilise également Akka pour une application de routage automatique de PCB avec l'idée de pouvoir passer d'un ordinateur portable à un centre de données. Plus vous lui donnez de puissance, meilleur sera le résultat. Ceci est extrêmement difficile à implémenter si vous essayez d'utiliser la simultanéité habituelle car Akka vous offre également une transparence de localisation.

Actuellement en tant que projet de temps libre, je construis un framework web utilisant uniquement des acteurs. Encore une fois, les avantages sont l'évolutivité d'une seule machine à un cluster entier de machines. De plus, l'utilisation d'une approche basée sur les messages rend votre service logiciel orienté dès le départ. Vous avez tous ces jolis composants, qui se parlent mais ne se connaissent pas nécessairement, vivent sur la même machine, pas même dans le même centre de données.

Et depuis la fermeture de Google Reader, j'ai commencé avec un lecteur RSS, en utilisant bien sûr Akka. Il s'agit pour moi de services encapsulés. En conclusion: le modèle d'acteur lui-même est ce que vous devez d'abord adopter et Akka est un cadre très fiable qui vous aide à le mettre en œuvre avec de nombreux avantages que vous recevrez en cours de route.

Nous utilisons akka avec son plugin camel pour distribuer notre analyse et notre traitement des tendances pour twimpact.com . Nous devons traiter entre 50 et 1000 messages par seconde. En plus du traitement multi-nœuds avec chameau, il est également utilisé pour distribuer le travail sur un seul processeur à plusieurs travailleurs pour des performances maximales. Fonctionne assez bien, mais nécessite une certaine compréhension de la façon de gérer les congestions.

J'essayais mes mains sur Akka (Java api). J'ai essayé de comparer le modèle de concurrence basé sur les acteurs d'Akka avec celui du modèle de concurrence Java simple (classes java.util.concurrent).

Le cas d'utilisation était une simple carte canonique réduisant la mise en œuvre du nombre de caractères. L'ensemble de données était une collection de chaînes générées de façon aléatoire (400 caractères de long) et calculait le nombre de voyelles qu'elles contiennent.

Pour Akka, j'ai utilisé un BalancedDispatcher (pour l'équilibrage de charge entre les threads) et RoundRobinRouter (pour garder une limite sur mes acteurs de fonction). Pour Java, j'ai utilisé une technique de jonction de fourche simple (mise en œuvre sans aucun algorithme de vol de travail) qui permettrait de mapper / réduire les exécutions et de joindre les résultats. Des résultats intermédiaires ont été conservés dans les files d'attente de blocage pour rendre même la jonction aussi parallèle que possible. Probablement, si je ne me trompe pas, cela imiterait en quelque sorte le concept de "boîte aux lettres" des acteurs Akka, où ils reçoivent des messages.

Observation: Jusqu'à des charges moyennes (~ 50000 entrée de chaîne), les résultats étaient comparables, variant légèrement selon les différentes itérations. Cependant, comme j'augmentais ma charge à ~ 100 000, cela bloquait la solution Java. J'ai configuré la solution Java avec 20-30 threads dans cette condition et elle a échoué dans toutes les itérations.

L'augmentation de la charge à 1000000 a également été fatale pour Akka. Je peux partager le code avec toute personne intéressée pour avoir une contre-vérification.

Donc pour moi, il semble qu'Akka évolue mieux que la solution multithread Java traditionnelle. Et probablement la raison en est la magie sous le capot de Scala.

Si je peux modéliser un domaine problématique comme un message événementiel en passant, je pense que Akka est un bon choix pour la JVM.

Test effectué sur: Version Java: 1.6 IDE: Eclipse 3.7 Windows Vista 32 bits. 3 Go de RAM. Processeur Intel Core i5, vitesse d'horloge de 2,5 GHz

Veuillez noter que le domaine problématique utilisé pour le test peut être débattu et j'ai essayé d'être aussi juste que mes connaissances Java le permettaient :-)

Nous utilisons Akka dans les systèmes de dialogue parlé ( primetalk ). En interne et en externe. Afin d'exécuter simultanément un grand nombre de canaux de téléphonie sur un seul nœud de cluster, il est évidemment nécessaire d'avoir un cadre multithreading. Akka fonctionne tout simplement parfait. Nous avons fait un cauchemar avec la java-simultané. Et avec Akka, c'est comme une balançoire - cela fonctionne simplement. Robuste et fiable. 24 * 7, non-stop.

À l'intérieur d'un canal, nous avons un flux d'événements en temps réel qui sont traités en parallèle. En particulier: - longue reconnaissance automatique de la parole - se fait avec un acteur; - producteur de sortie audio qui mélange quelques sources audio (y compris la parole synthétisée); - la conversion de texte en parole est un ensemble distinct d'acteurs partagés entre les canaux; - traitement sémantique et connaissance.

Pour effectuer des interconnexions de traitement de signaux complexes, nous utilisons SynapseGrid . Il présente l'avantage de la vérification à la compilation du DataFlow dans les systèmes d'acteurs complexes.

J'ai récemment implémenté l'exemple canonique de réduction de carte dans Akka: Word count. C'est donc un cas d'utilisation d'Akka: de meilleures performances. C'était plus une expérience des acteurs de JRuby et d'Akka qu'autre chose, mais cela montre également que Akka n'est pas seulement Scala ou Java: il fonctionne sur toutes les langues en plus de JVM.