🎄🎉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...
Un Acteur
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 :
- Un État (State) : il s'agit de ses données (ex: un compteur, une liste d’utilisateurs). C’est privé, et absolument personne de l’extérieur ne peut modifier cet état directement.
- Un Comportement (Behavior) : ce qu’il fait quand il reçoit un message (ex: ”Si on me dit ’Bonjour’, je réponds ’Salut’”).
- Une boîte aux lettres (Mailbox) : c'est là où arrive les messages.
Ainsi un acteur se base sur ces trois choses pour communiquer.
Peut-être est-il intéressant de parler de comment un acteur communique ?
La Communication
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 :
- L’acteur A envoie un message à l’acteur B et passe immédiatement à autre chose. Il n’attend pas la réponse bloqué devant son téléphone. Il s'agit d'un modèle asynchrone (Fire and Forget).
- On peut imaginer que les messages sont comme des lettres scellées. Une fois envoyés, on ne peut plus modifier le contenu. Cela garantit que l’information reçue est fiable. Il s'agit de l’immutabilité.
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.
La hiérarchie et la tolérance aux pannes ("Let it Crash")
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.
- Chaque acteur a un parent (celui qui l’a créé).
- Chaque acteur peut avoir des enfants. Le monde AKKA est régi par une philosophie de vie : "Let it crash".
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) :
- L’enfant meurt (crash).
- Son parent est immédiatement notifié.
- Le parent décide du sort de l’enfant selon une "stratégie de supervision" :
- Restart : "Redémarre à zéro (comme un reboot), on oublie tes problèmes passés." (un peu comme recommencer la partie dans un jeu vidéo quand on a perdu toutes nos vies...).
- Resume : "Ignore l’erreur et continue de traiter les messages suivants."
- Stop : ”Tu es trop malade, je te licencie (arrête définitivement.).”
- Escalate : "Je ne sais pas gérer ça, je demande à mon propre parent."
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".
La transparence de localisation
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.
Limites
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.
Conclusion
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 :
- Les systèmes à fort trafic (Streaming, IoT, Réseaux sociaux).
- Les applications qui ne doivent jamais s’arrêter (Finance, Télécoms).
- Les jeux vidéo multijoueurs (où chaque joueur est un Acteur qui gère son état).
Références et documentation additionnelle
Si vous désirez aller plus loin voici quelques ressources supplémentaires pour parcourir en détail le Monde d'AKKA 👇