Akka - gi.de · Locks, Mutexe, Semaphoren Konflikt-Stelle wird durch einen "Lock" geschützt...
Transcript of Akka - gi.de · Locks, Mutexe, Semaphoren Konflikt-Stelle wird durch einen "Lock" geschützt...
Akka.NETAktor basierte Programmierung in .NET
Taktfrequenzstagniert
zunehmendeAnzahl Kerne
CPU Entwicklung
Parallel ProgrammierungAufgabenstellung muss parallelisierbar sein
Kommunikation zwischen Ausführungs-Einheiten
Zugriff auf gemeinsame Ressourcen bzw. Daten regeln
Locks, Mutexe, SemaphorenKonflikt-Stelle wird durch einen "Lock" geschützt
eventuell warten andere Ausführungs-Einheiten auf Freigabe
Gefahr von Deadlocks
geringe Effizienz
Andere VerfahrenProblem: veränderliche Daten, gemeinsame Ressourcen
Funktionale Programmierung
Lambda Architektur
Channels, Streams
Actor Model
Aktor ModellErfinder: Carl Hewitt 1973
Programmiersprachen: Erlang, Elixir, D, Scala, ...
Toolkits: Akka (JVM), Akka.NET Frameworks: Service Fabric, Orleans…
Reactive!„menschlich“, natürlich
auf Ereignisse reagieren
eventuell Umwege gehen
Veränderungen mitteilen
http://reactivemanifesto.org/deAntwortbereit
Nachrichtenorientiert
Elastisch Widerstandsfähig
Reactive ManifestoAntwortbereit:unter allen Umständen antworten
Widerstandsfähig:bei Fehlern stabil bleiben
Elastisch:auch bei Last antwortbereit bleiben
Nachrichtenorientiert:entkoppelt, asynchrone Nachrichten
Was ist ein Aktor?Speicherungeines internen Zustandes
Verarbeitungeintreffender Nachrichten
Kommunikationmit anderen Aktoren
Aktor HierarchieEigene Aktoren unter /user
„Eltern haften für ihre Kinder“ (guardian)
oben: Verantwortung, unten: Risiko
Erzeugen:
system.ActorOf(…)
Context.ActorOf(…)
Aktor BestandteileAktor
Mailbox
Verhalten
Zustand
Überwachungs-Strategie
Kinder
1 2 3 4 5
Nachrichten -> Mailbox
sequentiell abarbeiten
immer nur ein Thread pro Aktor!
Aktor VerhaltenZustandsautomatinitial: Receive
Umschalten:
Become(NeuerZustand);
Je nach Zustand anderes Verhalten
unerwartete Nachrichten: Fehler, verwerfen oder "aufschieben"
Aktor ZustandAktor wird durch C# Klasse repräsentiert
Felder und Eigenschaften spiegeln Zustand wieder
Sobald Aktor „stirbt“: Zustand verlorenAusnahme: PersistentActor
Überwachungs Strategie"Eltern haften für ihre Kinder"
Optionen:
Resume: einfach weitermachen
Restart: neu starten (Standard)
Stop: anhalten
Escalate: an nächsthöhere Stelle melden
KinderPfad: tiefer in Hierarchiez.B. /user/A --> /user/A/Kind
Überwachungsstrategie wählbar
Benachrichtigung beim Kind-Beenden
In Hierarchie navigierbarChild("name") / Children() / Parent
Aktor SystemLaufzeitumgebung
/system, /user guardian
verwaltet Threads, steuert Aktoren
globale Dinge z.B. Log, EventStream
Steuerung via Konfiguration
Aktor ansprechenniemals über Objekte! Ortsunabhängigkeit!
via ActorRef (zeig mir den Weg dorthin)z.B. akka.tcp://hello@host:8080/user/x
via ActorSelection Muster von Pfaden ala Terminal /user/x/*
über vordefinierte Methodenz.B. Context.System.EventStream
Nachrichten sendenwahlweise via ActorRef
actor.Tell("huhu");
actor.Tell(42L);
actor.Tell(new MessageClass(...));
oder via ActorSelection
Context.ActorSelection("x/*").Tell(...);
Nachrichten-TypenCommand: Imperativ
HandleMeasure / StoreSomething
Event: Vergangenheit
MeasureHandled / SomethingStored
Document: Substantiv
Measure / Something
Umdenken!ausschließlich asynchrone Nachrichten
"Tell – don't Ask"
Kein Zugriff auf Eigenschaften
alle ausgetauschten Objekte müssen unveränderlich sein!
lange Operationen vermeiden
Patternsca. 100 verzeichnet
Aktor System in C#ActorSystem
anlegen
Actor
NuGet: Akka
Nachrichten verarbeitenBasisklasse
bestimmt Art der Verarbeitung
"Empfangs-bereitschaft"
Nachricht Typ
Verhalten. Lambda oder
Methodenaufruf
identisches Verhalten
identisches Verhalten
Aktor erzeugenProps: Argumente für Konstruktornotwendig wegen Ortsunabhängigkeit
Aktor erzeugen
Huhu – unsere erste Nachricht
wird an Konstruktor übergeben
Name in Hierarchie
AnwendungsgebieteParallelisierung
Kommunikationsintensive Vorgänge
Realisierung von technischen Abläufen
Modellierung von Geschäftsprozessen
Verteilte Anwendungen
ParallisierungAufteilung einer Aufgabe auf mehrere „Rechen-Aktoren“
dabei: parallele Verarbeitung
Resultat: schnell
Worker Worker Worker
Parallelisierung: RouterBerechnung Delegieren auf Router
Router entscheidet wer rechnet
Router leitet weiter, Worker antwortet
1
CalculatePi
4
double
Master
WorkerRouter3
CalculateRange
2
CalculateRange
WorkerWorker
via Forward
Parallelisierung: CodeWorker und Router anlegen:
Berechnung ausführen:
KommunikationBeispiel Event Storming
Kollaboration
aus Chaos wird Ordnung
Jeder leistet seinen Anteil
Kommunikation: SudokuAngaben werden nacheinander bestückt
Zelle kennt ihren Inhalt und teilt ihn mit81 Aktoren
Zeile, Spalte und Block zählt Ziffern27 Aktoren
Summe: 108 Aktoren
Kommunikation: Lösen
GeschäftsprozesseModellierung: Patterns von Domain-Driven Design
Realisierung: CQRS/ES
Schreibendes vs. lesendes Modell
Persistierung: Ereignisse
Wiederherstellung: Ereignis-Strom
CQRS
© Martin Fowler
CQRS/ES: CommandKommando wird validiert
Event wird persistiert (Event Sourcing)
Event wird angewandt
1
Command
Persistent Actor
2
Event
Persistent View
3
Event
CQRS/ES: View aktualisierenpassende Events gelangen zum View
dadurch aktueller Zustand
Persistent Actor
Persistent View
2
Event
4
Event
CQRS/ES: View abfragenVorhandene Daten
Abfrage preiswert
Persistent Actor
Persistent View
5
Query
6
Answer
CQRS/ES: Actorunsere Basisklasse
Akka.Persistence definiert PersistentActorZustand
Schlüssel
KommandosEreignisse
CQRS/ES: Actor AblaufDefinition
evtl. Validierung
Persistierung
Definition
Ausführung
Akka.NET – Fazituniversell einsetzbares Toolkit
viele Einsatzgebiete
neue Muster
hohe Zuverlässigkeit
zukunftsträchtig