Quelle est la différence entre le modèle Actor et les microservices?

Les deux ressemblent à un réseau de processus de communication MPI parallèle. J'identifie les acteurs avec des services. Les acteurs sont-ils plus dynamiques (vous pouvez les créer et tuer en respirant alors que le réseau de services est plus statique) ou quoi?

Modèle d'acteur - est un modèle mathématique pour les calculs simultanés et les microservices - une implémentation d'une architecture orientée services. Les similitudes sont assez fortuites.

Il est certainement possible de créer des microservices basés sur un modèle d'acteur et de modéliser une architecture de microservice avec un modèle d'acteur, mais cela ne signifie pas qu'ils sont équivalents. Remplacez «système de microservices» par «système de messagerie», et ce sera toujours vrai. Remplacez «modèle d'acteur» par «processus séquentiels communicants» (CSP), et ce sera également «vrai», car les systèmes de modèle CSP et d'acteur peuvent être modélisés les uns par les autres.

Étant donné le modèle d'acteur, vous pouvez aller l'implémenter à l'aide de microservices, ou SOA, ou même par courrier électronique, mais cela ne signifie pas qu'ils sont au même niveau d'abstraction pour vraiment comparer.

En outre, le modèle d'acteur met l'accent sur les tampons (peut être considéré comme des files d'attente de messages dans le monde des microservices), de sorte que certains acteurs / microservices peuvent ne pas être prêts alors qu'une communication intrinsèquement asynchrone est toujours possible.

En d'autres termes, la comparaison avec le modèle d'acteur peut apporter des idées créatives à un niveau de considération très élevé, mais il s'agit principalement de pommes vs d'oranges.

Si le but est de comparer le modèle mathématique SOA / microservices au modèle Actor, il n'est pas non plus trivial, car: 1) il n'y a pas de modèle mathématique convenu pour SOA, 2) le modèle inclut généralement l'objectif. Et la modélisation SOA / microservices est très probablement différente de l'objectif du modèle d'acteur. Un exemple de tentative de modélisation SOA ici .

Bien sûr, on peut créer un système de modèle d'acteur avec des microservices et appeler chaque service un acteur (se référer à la définition stricte de ce qu'est le modèle d'acteur). Mais cela ne signifie pas qu'il existe une relation significative entre les deux au sens général.

Les microservices sont un moyen d'organiser les logiciels en divisant chaque domaine de préoccupation en son propre artefact déployable (exécutable, script, JAR, WAR, etc.). Cela vous donne de la flexibilité, par exemple en vous permettant d'évoluer en déployant plus d'instances là où elles sont nécessaires. Supposons que les utilisateurs passent plus de temps à regarder votre catalogue qu'à ajouter des éléments à un panier d'achat; un artefact déployable gère les fonctions de catalogue, un autre gère les fonctions de panier d'achat - vous pouvez exécuter plus de copies des services de catalogue pour gérer la charge.

Il les isole également des changements internes. Supposons que vous passez d'une base de données relationnelle à une base de données de documents pour stocker les données sur les produits - il y a de fortes chances que vos services de panier d'achat n'aient pas besoin de changer.

Le modèle d'acteur est un niveau inférieur à l'artefact déployable, plus sur les types d'objets avec lesquels vous avez implémenté le service. En continuant avec l'exemple ci-dessus, les paniers de votre système peuvent être représentés par des acteurs, de sorte que le panier de chaque utilisateur est un acteur distinct, et les messages lui disent d'ajouter des articles, de supprimer des articles, de répondre avec le contenu actuel, d'ajouter des frais d'expédition, de vérifier , etc. Dans ce cas, vous disposez toujours d'un microservice et il est implémenté avec le modèle d'acteur.

Je dirais que la principale différence est celle de la granularité.

Pour le modèle d'acteur, il est relativement fin, en ce sens qu'un acteur a tendance à représenter l'équivalent d'un objet dans la POO.

Pour les micro-services, il est relativement grossier, en ce sens qu'un même micro-service peut être composé d'un grand nombre d'acteurs ou d'objets.

Notez que vous n'auriez pas vraiment besoin d'étirer trop votre imagination pour dire que le web moderne est exactement la même chose à une granularité encore plus grande ("macro-services"); et que (par exemple) un serveur HTTP est un macro-service, un serveur de base de données est un macro-service, un navigateur Web est un macro-service, etc.

C'est à peu près la même chose - des pièces isolées qui communiquent. Ce n'est que la taille des pièces (et donc le nombre de pièces) qui change.

Les microservices évoluent horizontalement en créant plusieurs répliques, chacune étant capable de répondre aux demandes en raison de la nature sans état du service. Ils résistent à l'échec en raison de leur nature apatride.

Les acteurs évoluent en les déplaçant vers des partitions avec moins de charge ou plus de ressources disponibles. Ils sont avec état . Ils résistent à l'échec car, selon le cadre de l'acteur, un autre acteur peut être dynamisé ou une sauvegarde à chaud de l'acteur peut être maintenue à tout moment pour faire face à l'échec de l'acteur principal.

Encore une fois, les microservices pourraient également être dynamiques, mais cela va à l'encontre des principes de conception des microservices.