Bon cas d'utilisation pour Akka
J'ai beaucoup entendu parler de Akka framework (plate-forme de service Java/Scala), mais je n'ai pas encore vu beaucoup d'exemples concrets de cas d'utilisation pour lesquels il serait utile. Je serais donc intéressé à entendre parler de choses que les développeurs ont utilisées avec succès.
Une seule limitation: veuillez ne pas inclure le cas de l'écriture d'un serveur de discussion. (pourquoi? étant donné que cela a été trop utilisé comme exemple pour beaucoup de choses similaires)
Je l'ai utilisé jusqu'à présent dans deux projets réels avec beaucoup de succès. les deux sont dans le domaine des informations 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, systèmes dorsaux fiables. Je ne suis pas encore libre de donner des précisions sur les clients. Lorsque j'aurai le feu vert, il pourra peut-être être ajouté à titre de référence.
Akka a vraiment mené à bien ces projets, même si nous avions commencé avec la version 0.7. (nous utilisons scala au fait)
L’un des grands avantages est la facilité avec laquelle vous pouvez composer un système composé d’acteurs et de messages pratiquement dépourvus de passe-partout, il évolue extrêmement bien sans la complexité du filetage à la main et vous obtenez un message asynchrone qui passe presque gratuitement entre des objets.
Il est très bon pour la modélisation de tout type de traitement de message asynchrone. Je préférerais écrire n'importe quel type de système de services (Web) dans ce style plutôt que dans un autre style. (Avez-vous déjà essayé d'écrire un service Web asynchrone (côté serveur) avec JAX-WS? Cela demande beaucoup de plomberie). Je dirais donc à tout système qui ne veut pas s’accrocher à l’un de ses composants car tout est appelé implicitement à l’aide de méthodes synchrones et qu’un seul composant se verrouille sur quelque chose. Il est très stable et la solution de panne let-it-crash + supervisor fonctionne vraiment bien. Tout est facile à configurer par programme et pas difficile à tester à l’unité.
Ensuite, il y a les excellents modules additionnels. Le module Camel se connecte parfaitement à Akka et permet un tel développement facile de services asynchrones avec des points de terminaison configurables.
Je suis très satisfait du framework et il est en train de devenir un standard de facto pour les systèmes connectés que nous construisons.
Disclaimer: Je suis le PO pour Akka
En plus d’offrir un smorgasbord de concurrence qui est beaucoup plus simple à raisonner et à obtenir correct (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:
- Traitement des transactions (jeux en ligne, finances, statistiques, paris, médias sociaux, télécommunications, ...)
- scale-up, scale-out, tolérance aux pannes/HA
- Service backend (toute industrie, toute application)
- service REST, SOAP, cometd etc
- agir en tant que concentrateur de messages/couche d'intégration
- scale-up, scale-out, tolérance aux pannes/HA
- Accès simultané/parallélisme de composant logiciel enfichable (toute application)
- Correct
- Simple à travailler et à comprendre
- Ajoutez simplement les fichiers jar à votre projet JVM existant (utilisez Scala, Java, Groovy ou JRuby)
- 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
- Pôle de communication (télécom, média web, média mobile)
- scale-up, scale-out, tolérance aux pannes/HA
- Serveur de jeu (jeux en ligne, paris)
- scale-up, scale-out, tolérance aux pannes/HA
- BI/datamining/general purpose crunching
- scale-up, scale-out, tolérance aux pannes/HA
- insérer d'autres cas d'utilisation de Nice ici
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 fusionner avec des métadonnées (catégorie, étiquette, balises, etc.) et fournir des services (alertes par e-mail/sms). détection de fraude, faible solde financier, 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, puis effectuer le travail. Tous ces travaux arrivent dans la même file d'attente en mode temps réel à partir d'institutions financières différentes. Une fois que les données sont nettoyées, elles sont envoyées vers différents magasins de données à des fins de persistance, d'analyse, ou poussées vers une connexion de socket, ou vers Lift comet actor. Les acteurs qui travaillent sont constamment en train d’équilibrer leur charge afin que nous puissions traiter les données le plus rapidement possible. Nous pouvons également ajouter des services supplémentaires, des modèles de persistance et stm pour les points de décision critiques.
Le message de style Erlang OTP transmis sur la machine virtuelle Java constitue un excellent système pour développer des systèmes en temps réel sur les épaules de bibliothèques et de serveurs d'applications existants.
Akka vous permet de faire passer des messages comme vous le feriez dans un esb traditionnel mais avec rapidité! Il vous fournit également des outils dans la structure 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. En association avec un 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 requête par thread traditionnel par utilisateur. .
Dites-le à votre patron que votre facture d'hébergement AWS va baisser de 10 et que c'est une évidence! Chut ... ne le dis pas à Amazon si ... :)
Nous utilisons Akka dans le cadre d’un projet de télécommunication à 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 manière, nous avons un modèle RPC simplifié basé sur le protobuffer de Google et nous réalisons le parallélisme en utilisant Akka Futures. Jusqu'à présent, ce modèle a brillamment fonctionné. Une remarque: nous utilisons l'API Java.
Si vous abstenez le serveur de discussion 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.
Ainsi, les exemples nécessitent des niveaux de durabilité et de fiabilité différents de la messagerie:
- Serveur de chat
- Couche réseau pour un MMO
- Pompe de données financières
- Système de notification pour un iPhone/mobile/quelle que soit l'application
- Serveur REST
- Peut-être que quelque chose s'apparente à WebMachine (devinez)
Les bons côtés d’Akka sont les choix qu’il offre en matière de persistance, sa mise en œuvre STM, son serveur REST et sa tolérance aux pannes.
Ne soyez pas ennuyé par l'exemple d'un serveur de discussion, considérez-le comme un exemple d'une certaine classe de solutions.
Avec toute leur excellente documentation, je sens qu’une lacune est cette question exacte, des cas d’utilisation et des exemples. Gardant à l'esprit les exemples ne sont pas triviaux.
(Écrit avec pour seule expérience de regarder des vidéos et de jouer avec la source, je n’ai rien mis en œuvre avec akka.)
Nous utilisons Akka dans plusieurs projets au travail, le plus intéressant étant lié à la réparation des véhicules en cas de collision. Principalement au Royaume-Uni, mais maintenant aux États-Unis, en Asie, en Australasie et en Europe. Nous faisons appel à des acteurs pour nous assurer que les informations sur les réparations en cas de collision sont fournies en temps réel afin de permettre des réparations sûres et économiques des véhicules.
La question avec Akka est vraiment plus "que ne pouvez-vous pas faire avec Akka". Sa capacité à s’intégrer à des cadres puissants, son abstraction puissante et tous les aspects liés à la tolérance aux pannes en font un ensemble d’outils très complet.
Vous pouvez utiliser Akka pour différents types de choses.
Je travaillais sur un site Web, où j'ai migré la pile de technologies vers Scala et Akka. Nous l'avons utilisé pour à peu près tout ce qui s'est passé sur le site. Même si vous pensez qu'un exemple de chat est mauvais, ils sont fondamentalement les mêmes:
- Mises à jour en direct sur le site Web (vues, likes, etc.)
- Affichage des commentaires de l'utilisateur en direct
- Services de notification
- Recherche et tous les autres types de services
En particulier, les mises à jour en direct sont faciles car elles se résument à ce qu'un exemple de chat est. 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 PCB avec l'idée de pouvoir passer d'un ordinateur portable à un centre de données. Plus vous lui donnerez de puissance, meilleur sera le résultat. Cela est extrêmement difficile à mettre en œuvre si vous essayez d’utiliser la concurrence simultanée, car Akka vous donne également la transparence de localisation.
Actuellement, en tant que projet de temps libre, je construis un cadre Web en utilisant uniquement des acteurs. Là encore, les avantages sont l’évolutivité d’une machine unique à l’ensemble d’un cluster de machines. En outre, l'utilisation d'une approche basée sur les messages permet à votre service logiciel d'être orienté dès le début. Vous avez tous ces composants sympas, qui se parlent mais ne se connaissent pas nécessairement, vivent sur le même ordinateur, 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 Akka bien sûr. Il s’agit pour moi de services encapsulés. 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 vous aidant à le mettre en œuvre avec de nombreux avantages.
J'essayais Akka (Java Api). J'ai essayé de comparer le modèle de concurrence basé sur l'acteur d'Akka avec celui du modèle de concurrence simple Java (classes Java.util.concurrent).
Le cas d'utilisation était une simple carte canonique réduisant l'implémentation du nombre de caractères. Le jeu de données était un ensemble de chaînes générées aléatoirement (400 caractères) et calculait le nombre de voyelles qu'elles contiennent.
Pour Akka, j'ai utilisé un BalancedDispatcher (pour l’équilibrage de la charge entre les threads) et RoundRobinRouter (pour limiter le nombre d’acteurs de fonction). Pour Java, j’ai utilisé une technique simple de jonction fork (mise en œuvre sans aucun algorithme de vol de travail) qui permettrait de forker/réduire les exécutions et de joindre les résultats. Les résultats intermédiaires ont été obtenus en bloquant les files d'attente pour que même la jonction soit 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, dans lequel ils reçoivent des messages.
Observation: charges moyennes au till (~ 50000 entrées de chaîne), les résultats étaient comparables, variant légèrement selon les itérations. Cependant, si je augmentais ma charge à ~ 100 000, la solution Java se bloquait. J'ai configuré la solution Java avec 20 à 30 threads dans cette condition, qui a échoué lors de toutes les itérations.
Augmenter la charge à 1000000 était également fatal pour Akka. Je peux partager le code avec toute personne intéressée par un test de vérification.
Donc, pour moi, il semble qu'Akka évolue mieux que la solution multithread traditionnelle Java. Et la raison en est probablement la magie cachée de Scala.
Si je peux modéliser un domaine problématique en tant que message transmis par événement, Akka est un bon choix pour la machine virtuelle Java.
Test effectué sur: Java version: 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 permettaient :-)
Nous utilisons akka avec son plugin camel pour distribuer notre analyse et le traitement des tendances pour twimpact.com . Nous devons traiter entre 50 et 1000 messages par seconde. Outre le 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 assez bien, mais nécessite une certaine compréhension de la gestion des congestions.
Nous utilisons Akka dans les systèmes de dialogue parlés ( primetalk ). À la fois en interne et en externe. Afin de gérer simultanément un grand nombre de canaux de téléphonie sur un seul nœud de cluster, il est évidemment nécessaire de disposer d’un cadre multithreading. Akka fonctionne parfaitement bien. Nous avons déjà eu un cauchemar avec la concurrence Java. Et avec Akka, c’est comme une balançoire - cela fonctionne. 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: - la longue reconnaissance automatique de la parole - est effectuée avec un acteur; - producteur de sortie audio qui mélange quelques sources audio (y compris la parole synthétisée); - la conversion texte-parole est un ensemble séparé d'acteurs partagés entre des canaux; - traitement sémantique et connaissance.
Pour effectuer des interconnexions de traitement de signal complexe, nous utilisons SynapseGrid . Il présente l'avantage de vérifier au moment de la compilation le flux de données dans les systèmes d'acteurs complexes.
J'ai récemment implémenté l'exemple canonique de réduction de carte dans Akka: Nombre de mots. C'est donc un cas d'utilisation d'Akka: de meilleures performances. C'était plus une expérience de les acteurs de JRuby et d'Akka qu'autre chose, mais cela montre aussi qu'Akka n'est ni Scala ni Java: il fonctionne sur toutes les langues sur la JVM.