Beide scheinen ein paralleles MPI-Kommunikationsnetz von Prozessen zu sein. Ich identifiziere Schauspieler mit Dienstleistungen. Sind die Akteure dynamischer (Sie können sie erstellen und töten, während das Servicenetz statischer ist) oder was?
Antworten:
Actor Model - ist ein mathematisches Modell für gleichzeitige Berechnungen und Microservices - eine Implementierung einer serviceorientierten Architektur. Die Ähnlichkeiten sind ganz zufällig.
Es ist sicherlich möglich, Microservices basierend auf einem Akteurmodell zu erstellen und eine Microservice-Architektur mit einem Akteurmodell zu modellieren, dies bedeutet jedoch nicht, dass diese äquivalent sind. Ersetzen Sie "microservice system" durch "email system" und es wird immer noch wahr sein. Ersetzen Sie "Actor Model" durch "Communicating Sequential Processes" (CSP), und es wird auch "true" sein, da CSP- und Actor Model-Systeme voneinander modelliert werden können.
Wenn Sie ein bestimmtes Darstellermodell haben, können Sie es mithilfe von Microservices, SOA oder sogar E-Mail implementieren. Dies bedeutet jedoch nicht, dass sie sich auf derselben Abstraktionsebene befinden, um wirklich zu vergleichen.
Das Akteurmodell betont auch die Puffer (kann als Nachrichtenwarteschlangen in der Microservices-Welt betrachtet werden), sodass einige Akteure / Microservices möglicherweise nicht bereit sind, während eine inhärent asynchrone Kommunikation weiterhin möglich ist.
Mit anderen Worten, der Vergleich mit dem Schauspielermodell kann einige kreative Einsichten auf einer sehr hohen Ebene bringen, aber meistens handelt es sich um Äpfel gegen Orangen.
Wenn das Ziel darin besteht, das mathematische Modell von SOA / Microservices mit dem Actor-Modell zu vergleichen, ist dies ebenfalls nicht trivial, da: 1) für SOA kein vereinbartes mathematisches Modell vorliegt, 2) das Modell normalerweise den Zweck enthält. Und die SOA / Microservices-Modellierung unterscheidet sich sehr wahrscheinlich vom Zweck des Akteurmodells. Ein Beispiel für den Versuch, hier SOA zu modellieren .
Natürlich kann man mit Microservices ein Akteurmodellsystem erstellen und jeden Dienst als Akteur bezeichnen (siehe strikte Definition des Akteurmodells). Dies bedeutet jedoch nicht, dass zwischen den beiden im Allgemeinen eine sinnvolle Beziehung besteht.
Mit Microservices können Sie Software organisieren, indem Sie jeden betroffenen Bereich in ein eigenes implementierbares Artefakt (ausführbare Datei, Skript, JAR, WAR usw.) aufteilen. Dies gibt Ihnen Flexibilität, indem Sie beispielsweise die Skalierung ermöglichen, indem Sie mehr Instanzen dort bereitstellen, wo sie benötigt werden. Angenommen, Benutzer verbringen mehr Zeit mit dem Betrachten Ihres Katalogs als mit dem Hinzufügen von Dingen zu einem Warenkorb. Ein implementierbares Artefakt übernimmt die Katalogfunktionen, ein anderes die Warenkorbfunktionen. Sie können mehr Kopien der Katalogservices ausführen, um die Last zu bewältigen.
Es isoliert sie auch von internen Änderungen. Angenommen, Sie wechseln von einer relationalen Datenbank zu einer Dokumentendatenbank, um Produktdaten zu speichern - Ihre Warenkorbdienste müssen sich wahrscheinlich nicht ändern.
Das Akteurmodell ist eine niedrigere Ebene als das bereitstellbare Artefakt. Es handelt sich eher um die Objekttypen, mit denen Sie den Service implementiert haben. Wenn Sie mit dem obigen Beispiel fortfahren, werden die Einkaufswagen in Ihrem System möglicherweise von Akteuren dargestellt, sodass der Einkaufswagen jedes Benutzers ein eigener Akteur ist. In Nachrichten wird er aufgefordert, Artikel hinzuzufügen, Artikel zu entfernen, mit dem aktuellen Inhalt zu antworten, Versand hinzuzufügen und auszuchecken usw. In diesem Fall haben Sie immer noch einen Microservice, der mit dem Actor-Modell implementiert ist.
Ich würde sagen, dass der Hauptunterschied in der Granularität liegt.
Für das Akteurmodell ist es relativ feinkörnig, da ein Akteur dazu neigt, das Äquivalent eines Objekts in OOP darzustellen.
Für Mikrodienste ist dies relativ grobkörnig, da ein einzelner Mikrodienst aus einer großen Anzahl von Akteuren oder Objekten bestehen kann.
Beachten Sie, dass Sie Ihre Vorstellungskraft nicht wirklich erweitern müssen, um zu behaupten, dass modernes Web bei noch größerer Granularität ("Makrodienste") dasselbe ist. und dass (z. B.) ein HTTP-Server ein Makrodienst, ein Datenbankserver ein Makrodienst, ein Webbrowser ein Makrodienst usw. ist.
Es ist alles in etwa dasselbe - isolierte Teile, die kommunizieren. Es ist nur die Größe der Teile (und damit die Anzahl der Teile), die sich ändern.
Microservices werden horizontal skaliert, indem mehrere Replikate erstellt werden, von denen jedes aufgrund des statusfreien Zustands des Dienstes Anforderungen bedienen kann. Sie sind aufgrund ihrer Staatenlosigkeit ausfallsicher.
Akteure werden skaliert, indem sie auf Partitionen mit weniger Last oder mehr verfügbaren Ressourcen verschoben werden. Sie sind staatlich . Sie sind ausfallsicher, da - je nach Akteur-Framework - ein anderer Akteur dynamisch hochgefahren werden kann oder jederzeit eine aktuelle Sicherung des Akteurs erstellt werden kann, um den Ausfall des primären Akteurs zu beheben.
Auch hier können Microservices zwar statusbehaftet sein, verstoßen jedoch gegen die Gestaltungsprinzipien von Microservices.