[Review] Actor Model @ DDDEU 2017

DDD Europe 2017

[Review] Actor Model @ DDDEU 2017

DDD Europe 2017

En février, c’était DDD Europe à Amsterdam, retour sur la conférence “Actor Model” avec Yoan

 

Si vous avez déjà implémenté des applications multithreaded, vous savez à quel point cela peut être difficile à gérer. Vous avez très certainement rencontré des problèmes liés à la gestion des threads et des locks.

Si vous êtes à la recherche d’une approche vous permettant de vous abstraire de ce genre de problématique, la session “Building Actor Model systems using Akka.NET“ d’Edwin van Wijk vous aurait intéressée.

 

Actor Model

Actor Model est un modèle conceptuel, présenté initialement par Carl Hewitt en 1973, qui traite les acteurs comme les primitives universelles des traitements concurrentiels.

Le modèle définit comment les composants du système doivent se comporter et interagir les uns avec les autres à travers l’échange de messages asynchrones.

 

Qu’est-ce qu’un acteur ?

Un acteur est simplement une « chose » qui va recevoir des messages et effectuer un traitement quelconque, basé sur celui-ci.

Un acteur se comporte de façon similaire à un objet dans la programmation orientée objet :

 

Acteur Objet
Reçoit un message Reçoit un appel à une de ses méthodes
Effectue un traitement en réponse à un message Effectue un traitement dépendant de la méthode appelée

 

Les grosses différences entre ces deux paradigmes sont que les acteurs sont complètement isolés des uns des autres (aucun partage de mémoire, tourne dans son propre thread).

Aucun acteur ne peut aller modifier l’état interne d’un autre acteur.

 

Mailboxes

La communication entre les acteurs se fait uniquement à travers l’échange de messages.

Chaque acteur va traiter ses messages de manière séquentielle dans l’ordre d’arrivée (FIFO).

Si plusieurs messages sont envoyés à un même acteur, ils seront alors stockés dans sa mailbox, cela permet de totalement balayer les problèmes d’accès concurrentiels.

 

Responsabilité des acteurs

Quand un acteur reçoit un message il peut :

  • Créer d’autres acteurs
  • Envoyer des messages à d’autres acteurs
  • Changer son état interne

DDD Europe 2017

 

Comme les acteurs peuvent créer d’autres acteurs et communiquer avec eux ; ceux-ci vont alors former une hiérarchie :

DDD Europe 2017

Actor Model et Domain Driven Design

Dans sa session “The Language of Actors”, Vaughn Vernon nous a montré à quel point l’Actor Model est bien adapté pour implémenter Domain Driven Design.

 

DDD Europe 2017

 

Comme on peut le voir sur le schéma ci-dessus, Actor Model nous permet d’implémenter assez facilement DDD et va résoudre pour nous une problématique majeure, celle « qu’un et un seul aggregate ne peut être modifié au sein d’une même transaction ».

 

Akka .NET

Akka est un toolkit et un runtime implémentant Actor Model. A l’origine disponible en Scala il est aussi disponible en .NET.

C’est le framework qui a été introduit par Edwin van Wijk lors de sa session.

 

Avantages

Distribution/scalability/resilience

Avec Actor Model et dans les systèmes orientés message en général, on ne se préoccupe pas de savoir si l’acteur à qui on envoie un message tourne localement ou sur un autre serveur/nœud.

En effet, puisqu’un acteur n’est qu’un petit morceau de code avec une mailbox et un état interne, peu importe de savoir où cet acteur est localisé du moment qu’on est capable d’assurer que les messages lui parviendront.

Cela va nous permettre de créer des systèmes de manière distribuée (sur n serveurs).

 

Fault tolerance

Comme nous l’avons vu précédemment chaque acteur va tourner à l’intérieur d’un process complètement isolé ; ainsi un acteur ne peut pas influencer le fonctionnement d’un autre acteur, sauf à lui envoyer un message.

En revanche, afin de pouvoir superviser ces acteurs/process nous allons retrouver la notion de supervisor. Un supervisor est un process indépendant qui est notifié et va pouvoir réagir lorsqu’un process crash (redémarrer l’acteur en question par exemple).

Ces principes vont donc nous permettre de créer des systèmes capables de se « guérir » eux-mêmes.

 

A retenir

  • Actor model nous permet d’implémenter Domain Driven Design facilement.
  • Il nous abstrait de nombreuses problématiques : accès concurrentiels, multithreading, …
  • On peut créer des systèmes orientés messages, distribuables et fault tolerant.
Maeva Pitou
1 Comment

Post a Comment

Comment
Name
Email
Website