Akka.NET Remoting 17.08.2020, 00:00 Uhr

Verteilte Aktoren

Mit Akka.NET lassen sich typische Multithreading-Probleme lösen oder vermeiden.
(Quelle: Autor)
Akka.NET [1] löst die gängigen Probleme in der Entwicklung nebenläufiger Anwendungen. Die Bibliothek ist schon ein Gewinn, wenn man sich nicht im Umfeld verteilter Systeme bewegt. Sind aber mehrere Prozesse an einem System beteiligt, hat man schnell die gleichen Probleme wieder am Hals – nur noch etwas schlimmer. Hier hilft das Erweiterungspaket Akka.Remote. Das Paket ergänzt ein Aktor-System um folgende Fähigkeiten [2]:
  • Standorttransparenz (location transparency): Die Kommunikation zwischen Aktoren auf unterschiedlichen Maschinen verläuft dabei für die Aktoren transparent – der einzelne Aktor merkt nicht, dass er mit einem entfernten Aktor spricht, was bedeutet, dass sich auch der Code für die Kommunikation nicht ändert, wenn bestimmte Aktoren „plötzlich“ auf einem anderen Server angesiedelt sind.
  • Fernadressierung (remote addressing): Um entfernte Aktoren ansprechen zu können, müssen diese adressierbar sein. In einem lokalen Aktor-System hat jeder Aktor einen eindeutigen ActorPath, eine Adresse, über die dieser Aktor ausgewählt und angesprochen werden kann. Bei der Verwendung von Remoting wird dieser Pfad um die Informa­tion erweitert, wo ein Aktor im Netzwerk zu finden ist.
  • Fernbereitstellung (remote deployment): Normalerweise entstehen neue Aktoren innerhalb eines Aktor-Systems dadurch, dass ein bereits existierender Aktor einen Kind-Aktor erzeugt. Durch die Nutzung von Remoting ist es möglich, einen Aktor auf einem entfernten System zu erzeugen.
  • Verschiedene Netzwerktransporte (multiple network transports): Zur Kommunikation zwischen den Aktor-System auf unterschiedlichen Maschinen im Netzwerk wird ein Kommunikationsprotokoll benötigt, das in Akka.NET als Transport bezeichnet wird. Der Standardtransport ist TCP. Man kann weitere Transporte integrieren.
  • Der Ansatz „distributed by default“ klingt wunderbar: Es gibt praktisch gar kein API für das Remoting, mit ein bisschen Konfiguration läuft alles wunderbar. So einfach ist es aber nicht. Allem voran sollte man die „Fallacies of Distributed Computing“ beherzigen [3]. Des Weiteren müssen Nachrichten serialisierbar sein und dürfen auch nicht zu groß werden. Dass jedwede Kommunikation asynchron stattfindet, gehört zum Wesen von Akka.NET sowie anderen nachrichtenbasierten Systemen.
  • Die Kommunikation zwischen Aktor-Systemen ist nach dem Peer-to-Peer-Muster ausgelegt. Das bedeutet, dass die Kommunikation zwischen zwei Aktor-Systemen A und B symmetrisch ist: Wenn A mit B sprechen kann, muss B auch mit A sprechen können. Das ist anders als etwa bei HTTP-Aufrufen, wo der Server (abgesehen von Web Sockets oder Ähnlichem) nicht in der Lage ist, eine Kommunikation mit dem Client aufzubauen. Reine Client-Server-Setups sind in Akka.Remote also nicht möglich. Dementsprechend symmetrisch sind auch die Rollen beim Aufbau von Verbindungen: Jedes System kann Verbindungen initiieren und Verbindungen entgegennehmen.

Jetzt 1 Monat kostenlos testen!

Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
  • + Digitales Kundenkonto,
  • + Zugriff auf das digitale Heft,
  • + Zugang zum digitalen Heftarchiv,
  • + Auf Wunsch: Weekly Newsletter,
  • + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar