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