🎄🎉C'est bientôt noël... et qui dit noël dit repas de famille !
Eh oui, un repas de famille comme on les aime où tout le monde parle en même temps, alors que mamie nous demande le sel qui est de l'autre de côté de la table, tandis que papa renverse le jus d'orange sur le plat de maman... Les enfants qui sont excités...
Quel ambiance n'est-ce pas ?
En Informatique ce "type" de diner de famille correspond à une approche classique appelé le Multi-threading traditionnel. On gère les ressources de manière manuelle avec ce qu'on appelle des Threads et des Locks... et c'est difficile, fragile et ça plante souvent.
Et maintenant, imaginez que chaque personne est assise à une petite table séparée. Pour demander un verre de jus d'orange, on ne tend pas le bras, on écrit une petite note sur un papier et on la fait passer.
Ainsi, personne ne crie, chacun lit ses notes une par une, calmement.
Un peu particulier voir inimaginable ?
En informatique c'est ce qu'on appelle la manière AKKA.
Ce modèle consiste "simplement" à concevoir des systèmes concurrents, scalables et résilients en évitant les problèmes classiques du Multi-threading traditionnel (les fameux Threads, locks etc.).
Il repose sur certains principes et on va les découvrir dans ce nouveau poste.
Bienvenue à vous la communauté👋, aujourd'hui on plonge dans le monde de l'AKKA pour en comprendre les règles qui y sont instauré et son univers complexe...
Commençons donc par la base.
Dans le modèle AKKA on parle d'acteur qui est une entité autonome que l'on peut symboliser par le cœur du système.
Cette entité possède trois choses que personne d’autre ne peut toucher :
Ainsi un acteur se base sur ces trois choses pour communiquer.
Peut-être est-il intéressant de parler de comment un acteur communique ?
Dans le monde d'Akka, on ne s’appelle pas au téléphone (synchrone) mais on s’envoie plutôt des SMS (asynchrone).
On peut résumer l'idée qu'un acteur communique de la sorte :
Et donc, concrètement, cela veut dire quoi ? l’envoyeur ne se bloque jamais, ainsi le CPU ne reste pas bloqué à attendre, il peut travailler sur d'autres tâches en parallèle.
Si on a déjà pu voir que le modèle AKKA peut étrangement et aisément se traduire par des images de vie courante, la partie que l'on va discuter ici est sans doute la plus humaine de toutes.
Les acteurs vivent dans une hiérarchie stricte, comme dans une entreprise ou une armée.
Dans le code classique, on essaie de tout protéger avec des try { ... } catch { ... } partout. C’est en quelque sorte une "micro-gestion défensive".
Avec Akka, si un acteur enfant rencontre une erreur grave (disque plein, bug critique) :
Ainsi, cela crée des systèmes autoguérisseurs (ou Self-healing systems), cela veut dire qu'aucune gestion extérieure n'est nécessaire.
Pour clarifier, avec AKKA, les acteurs peuvent être dits locaux (local actors), cela veut dire qu'ils sont situés au sein de la même machine. Ou ils peuvent être dits distribués (distributed actors), cela veut dire qu'ils s'étendent sur différentes machines.
Dans tous les cas, les acteurs ne communiquent que par messages, et cela ne change rien quant Ă leur fonctionnement.
On pourrait se poser la question de s'il y a quelque chose qui change entre envoyer un SMS Ă un voisin de palier ou Ă un ami au Japon ?
Et la réponse est non. Le geste est le même : "Écrire message -> Envoyer".
Dans AKKA, le code pour envoyer un message à un acteur local (dans la même RAM) est identique au code pour l’envoyer à un acteur sur un serveur à l’autre bout du monde.
Vous pouvez commencer avec votre application sur un seul serveur. Si elle devient virale, vous configurez AKKA pour lancer des acteurs sur 50 serveurs. Vous ne changez pas une ligne de votre logique métier. C’est le framework qui gère le réseau.
Et voilà , c'est ça AKKA !
Donc si vous ne devez retenir que trois choses du poste d'aujourd'hui, AKKA :
C'est une isolation totale : c'est-à -dire qu'un acteur est un peu comme une forteresse. Pas de partage de mémoire = pas de bugs de concurrence classiques.
Tout est message : on ne bloque jamais l’exécution. C’est fluide, rapide et réactif.
C'est une résilience structurelle : les parents surveillent les enfants. Si une partie du système plante, elle est redémarrée proprement sans faire tomber tout le serveur.
Même si sur la forme AKKA semble simple à comprendre, il reste complexe à implémenter. Car si, au sein d'une application, on réfléchit généralement sous forme de "fonctions" à appeler. Avec AKKA, on parle de messages et de flux asynchrones. Cela implique la bonne définition des types de messages à utiliser. Précisément, comme on n'a pas accès directement à l'acteur, il faut réaliser chaque interaction sous forme de message, ce qui peut rendre la chose relativement lourde.
Il est également difficile de déboguer, parfois plus difficile qu'un code impératif classique (surtout quand on cumule le nombre d'acteurs). Car l'asynchronisme impacte l'ordre d'arrivée des messages et la prédiction de ces derniers.
AKKA doit être utilisée de manière très minutieuse et attentive, sinon on peut se retrouver perdu dans son propre système.
Et donc, quand l'utiliser ?
Bien entendu, ça ne sert à rien d'utiliser AKKA pour faire un simple site web ”Hello World”, c’est comme vouloir utiliser un tank pour aller chercher le pain...
On utilise globalement Akka pour :
Si vous désirez aller plus loin voici quelques ressources supplémentaires pour parcourir en détail le Monde d'AKKA 👇
