Question Bon cas d'utilisation pour Akka [fermé]


J'ai entendu beaucoup de délire à propos de Akka cadre (plate-forme de service Java / Scala), mais jusqu'à présent, n'ont pas vu beaucoup d'exemples réels de cas d'utilisation, il serait bon pour. Donc, je serais intéressé d'entendre parler de choses 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 discussion. (pourquoi? puisque ceci a été surexploité comme exemple pour beaucoup de choses semblables)


557
2017-12-20 19:15


origine


Réponses:


Je l'ai utilisé jusqu'à présent dans deux projets réels avec beaucoup de succès. les deux sont dans le champ d'information de 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 dorsaux fiables. Je ne suis pas encore libre de donner des détails sur les clients, quand j'obtiens l'OK peut-être peut-il être ajouté comme référence.

Akka a vraiment tiré parti de ces projets, même si nous avons commencé quand il était sur la version 0.7. (Nous utilisons scala en passant)

L'un des grands avantages est la facilité avec laquelle vous pouvez composer un système avec des acteurs et des messages pratiquement sans mise à plat, il évolue très bien sans toutes les complexités du threading roulé à la main et vous obtenez des messages asynchrones presque gratuitement.

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

Ensuite, il y a les excellents modules supplémentaires. Le module Camel s'intègre bien dans Akka et permet un développement aussi facile des services asynchrones avec des extrémités configurables.

Je suis très content du framework et il devient un standard de facto pour les systèmes connectés que nous construisons.


299
2017-12-20 22:17



Disclaimer: Je suis le PO pour Akka

En plus d'offrir un smorgasbord de concurrence qui est beaucoup plus simple à raisonner et à corriger (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 (en ligne jeu, finance, statistiques, paris, médias sociaux, télécoms, ...)
    • scale up, scale out, tolérance aux pannes / HA
  2. Service backend (toute industrie, toute application)
    • service REST, SOAP, cometd etc.
    • agir comme un concentrateur de messages / une couche d'intégration
    • scale up, scale out, tolérance aux pannes / HA
  3. Snap-in concurrence / parallélisme (n'importe quelle application)
    • Correct
    • Simple à travailler et à comprendre
    • Ajoutez simplement les fichiers jars à votre projet JVM existant (utilisez Scala, Java, Groovy ou JRuby)
  4. Traitement par lots (toute industrie)
    • Intégration de Camel pour se connecter avec des sources de données par lots
    • Les acteurs divisent et conquièrent les charges de travail par lots
  5. Plate-forme de communication (télécoms, médias web, médias mobiles)
    • scale up, scale out, tolérance aux pannes / HA
  6. Serveur de jeu (jeux en ligne, paris)
    • scale up, scale out, tolérance aux pannes / HA
  7. BI / datamining / croquage général
    • scale up, scale out, tolérance aux pannes / HA
  8. insérer d'autres cas d'utilisation agréable ici

210
2017-12-20 22:27



Un exemple de la façon dont nous l'utilisons serait sur 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 si c'est un point de vente, il y a beaucoup à faire comme fusionner avec des méta-données (catégorie, étiquette, tags, etc.) et fournir des services (alertes email / sms, détection de fraude, balance des fonds faibles, etc.). Basé sur le 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 emplois entrent dans la même file d'attente en temps réel de différentes institutions financières. Une fois les données 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 sont constamment en charge de l'auto-équilibrage du travail afin que nous puissions traiter les données aussi vite que possible. Nous pouvons également intégrer des services supplémentaires, des modèles de persistance et  pour les points de décision critiques.

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

Akka vous permet de faire passer des messages comme vous le feriez dans un traditionnel  mais avec de la vitesse! Il vous donne é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.


76
2017-12-20 22:16



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 desservis par nœud / serveur, par rapport au modèle de requête de threads par utilisateur.

Dites à votre patron que votre facture d'hébergement AWS va baisser d'un facteur 10 et c'est une évidence! Shh ... ne le dis pas à Amazon si ... :)


41
2017-11-17 15:10



Si vous faites abstraction du serveur de discussion, 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 éléments 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 une application iPhone / mobile / quelconque
  • 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 soyez pas ennuyé par l'exemple d'un serveur de chat, pensez-y comme un exemple d'une certaine classe de solution.

Avec toute leur excellente documentation, je me sens comme une lacune est cette question exacte, des cas d'utilisation et des exemples. Garder à l'esprit les exemples sont non-trivial.

(Écrit avec seulement l'expérience de regarder des vidéos et de jouer avec la source, je n'ai rien implémenté en utilisant akka.)


36
2017-12-20 21:54



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 le protobuffer de Google et nous obtenons un parallélisme avec Akka Futures. Jusqu'à présent, ce modèle a fonctionné avec brio. Une note: nous utilisons l'API Java.


36
2017-12-21 12:34



Nous utilisons Akka dans plusieurs projets au travail, le plus intéressant étant lié à la réparation d'un accident de véhicule. Principalement au Royaume-Uni mais maintenant en expansion aux États-Unis, en Asie, en Australasie et en Europe. Nous utilisons des acteurs pour s'assurer que les informations sur les réparations en cas d'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 "qu'est-ce que tu ne peux pas faire avec Akka". Sa capacité à s'intégrer à de puissants frameworks, sa puissante abstraction et tous les aspects de tolérance aux fautes en font un outil très complet.


23
2017-12-21 15:55



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 est arrivé sur le site. 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, mentions J'aime, ...)
  • Affichage des commentaires des utilisateurs en direct
  • Services de notification
  • Recherche et tous les autres types de services

Surtout 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 mise en grappe, vous pouvez la déployer sur différentes machines avec facilité.

J'utilise également Akka pour une application autorouter PCB avec l'idée d'être capable de passer d'un ordinateur portable à un centre de données. Plus vous donnez de puissance, meilleur sera le résultat. Ceci est extrêmement difficile à implémenter si vous essayez d'utiliser la concurrence habituelle car Akka vous donne également la transparence de l'emplacement.

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

Et depuis que Google Reader a fermé, j'ai commencé avec un lecteur RSS, en utilisant bien entendu Akka. Tout est une question de services encapsulés pour moi. En conclusion: Le modèle d'acteur lui-même est ce que vous devez adopter en premier et Akka est un cadre très fiable qui vous aide à le mettre en œuvre avec beaucoup d'avantages que vous recevrez en cours de route.


23
2017-08-09 12:00



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


18
2017-12-21 13:10



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

Le cas d'utilisation était une simple carte canonique réduisant l'implémentation du nombre de caractères. L'ensemble de données était une collection de chaînes générées aléatoirement (400 caractères de longueur), et calcule le nombre de voyelles qui s'y trouvent.

Pour Akka, j'ai utilisé un BalancedDispatcher (pour équilibrer la charge entre les threads) et RoundRobinRouter (pour garder une limite sur les acteurs de ma fonction). Pour Java, j'ai utilisé une simple technique de jointure de fourche (implémentée 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é tenus dans les files d'attente de blocage pour rendre même la réunion 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ées de cordes), les résultats étaient comparables, variant légèrement selon les différentes itérations. Cependant, comme j'ai augmenté ma charge à ~ 100000, la solution Java serait bloquée. J'ai configuré la solution Java avec 20-30 threads dans cette condition et il a échoué dans toutes les itérations.

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

Donc, pour moi, il semble que Akka soit plus performant que la solution multithread Java traditionnelle. Et probablement la raison est la magie sous le capot de Scala.

Si je peux modéliser un domaine de problème comme un message piloté par un événement en passant un, 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. Ram de 3 Go. Processeur Intel Core i5, fréquence d'horloge de 2,5 GHz

S'il vous plaît noter, le domaine du problème utilisé pour le test peut être débattu et j'ai essayé d'être aussi juste que mes connaissances Java permis :-)


17
2018-06-21 20:37



Nous utilisons Akka dans les systèmes de dialogues parlés (primetalk). À la fois interne et 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 une structure de multithreading. Akka fonctionne parfaitement. Nous avons un précédent cauchemar avec la concurrence java. Et avec Akka, c'est comme une balançoire - ça marche tout simplement. Robuste et fiable. 24 * 7, non-stop.

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

Pour faire des interconnexions de traitement de signal complexe, nous utilisons SynapseGrid. Il a l'avantage de vérifier le DataFlow à la compilation dans les systèmes d'acteur complexes.


16
2017-08-09 07:36