Akka.NET

Präsentiert am 07.12.2017 in der .NET Usergroup Karlsruhe

Transcript

1. Akka.NET
2.  Lev Lehn @levlehn  Coder seit 1992  Auf der Suche nach Developer-Erleuchtung ◦ Basic, Pascal / Delphi, C++, (PHP / Js), C# & Typescript  Software-Architekt bei Kardex Remstar ◦ Produktlinien mit C# / Typescript /Angular ◦ Code Quality Missionar
3.  Gut kopieren ist besser als schlecht erfinden!  .NET-Port von Akka  Akka ist eine Implementierung des Aktormodells auf der JVM / Standard-Lib von Skala  Aktormodell – 1973 erfunden  Verwandt, ähnlich aber anders – MS Orleans („virtual actors“)  Grains leben ewig - kein richtiger lifecycle  await/async versteckt Message-Passing
4.  Gekapselte Ausführungseinheit  Aktoren kommunizieren mit Messages  Aktoren bilden eine Hierarchie  Eltern passen auf die Kinder auf  Aktoren laufen asynchron  Aktoren haben keinen nach außen sichtbaren Zustand  Lock-Free concurrency
5.  Demo
6.  ActorSystem ist „heavy“. Nur 1x pro System  ActorSystem.ActorOf()  Props  So lokal wie möglich (static method)  Props.Create(() => new MyActor(params))  IActorRef – der (lokale) Aktor  Tell()  Forward()  Ask() ◦ Langsam, nur für „Einmalsachen“
7.  Common:  Context ◦ ActorOf(), GetChildren(), …  Self, Parent, Sender  Lifecycle  SupervisorStrategy  UntypedActor  void OnReceive(object message)  ReceiveActor  void Receive<T>(Action<T> handler)
8.  Demo UntypedActor
9.  Akka ist ein fehlertolerantes System  Supervision  Eltern sind verantwortlich für ihre Kinder  Stürzt ein Aktor ab, entscheidet die Supervision-Strategie des Parents, was passiert  Default: Restart  Nützlich: X Mal Restart, danach Escalate  Möglich: Feingranulare Entscheidungen
10.  Jeder Aktor hat einen Parent.  Jeder Aktor kann beliebig viele Childaktoren erstellen.  Wird ein Aktor beendet, werden alle seine Childaktoren beendet, auch transitiv.  Die Hierachie kann man navigieren  Parent  Mit Pfaden
11.  Jeder Aktor hat einen Parent.  Jeder Aktor kann beliebig viele Childaktoren erstellen.  Wird ein Aktor beendet, werden alle seine Childaktoren beendet, auch transitiv.  Die Hierachie kann man navigieren  Parent  Mit Pfaden
12.  Aktoren anhand vom Pfad addressieren  ActorSelection(“/user/serviceA“)  Pfade sind absolut  /user/hello  Oder relativ  ../brother  Können Wildcards enthalten  /user/serviceA/*  *  /user/*/watchdog  Demo Supervision/Hierarchie/ActorSelection
13.  Lifecycle hooks  PreStart  PreRestart  PostRestart  PostStop  Aktoren anhalten  Context.Stop()  PoisonPill  Kill  Aktoren überwachen  Context.Watch()
14.  Zustellbedingungen  At-Most-Once  Reihenfolge pro Sender-Empfänger garantiert  At-Least-Once in Akka.Persistence  Bedingungen  Messages müssen immutable sein  Lokal, nichtlokal, egal*  Umsortieren möglich???  Retry, Forwarding, Routing
15.  Wo landen unzustellbare Messages?  DeadLetters  Context.System.EventStream  Ermöglich Publish  Explizites Subscribe/Unsubscribe  Danach wie normale Messages mit Receive()  Demo EventStream
16.  Nicht ewig auf Antwort warten  Ask hat Timeout  SetReceiveTimeout(timespan)  Nach timespan Inaktivitätszeit bekommt man einen ReceiveTimeout  Im Receive() handlen  Mit null abschalten  Demo
17.  Akka hat eingebaute Automaten  Become()  BecomeStacked()  UnbecomeStacked()  Demo
18.  Automaten werden oft schnell kompliziert, wenn man alle Fälle abdecken will  Stash/Unstash!  Erlaubt das Umsortieren von eigehenden Messages ◦ Try that with a normal API  Demo
19.  Pool Router  Routees sind Kinder  Group Router  Routees sind keine Kinder  Strategien:  RoundRobin  BroadCast  Random  ConsistentHash  TailChopping  ScatterGatherFirstCompleted  SmallestMailbox
20.  Integration mit Nicht-Aktoren  IActorRef.Ask()  Inbox ◦ Inbox.Create(ActorSystem) ◦ Inbox.Receive()
21.  Langlaufende Prozesse nicht im Aktor  Auslagern in Async-Aufrufe  Task<T> zu Aktor:  Task<Message> msgTask = DoSomething();  msgTask.PipeTo(Self);  Message landet in der Mailbox und kann wie andere Messages verarbeitet werden
22.  Akka.Remote  Explizites Handlen von Remote-Aktoren ◦ Remote-Pfade  "akka.tcp://my-sys@host.example.com:5678/user/service-b“  Polymorpher High-Perf Serializer  Akka.Cluster  „fault-tolerant, elastic, decentralized peer-to-peer network of Akka.NET applications with no single point of failure or bottleneck”  Cluster Singleton
23.  Akka.Persistence  Event sourcing „out of the box“ ◦ Cassandra, Sql Server, Sqlite  Persistente FSMs  Akka.Persistence.Query  Projections für Read Models im Event-Sourcing  Akka.Cluster.Sharding  Logische Adressierung von Aktoren
24.  Akka.Streams  Stream-Processing on Steroids  Reactive Streams – Push mit Back-Pressure  Reusable Flows  Time-Based Processing  …  Alleine damit kann man ein Buch füllen
25.  HOKON  JSON-Inspiriertes Config-Format ◦ App.Config unter .NET Framework ◦ 2 Zeilen Code in .Net-Core  Sehr viel ist konfigurierbar ◦ Logging ◦ Serializer ◦ Router ◦ Etc.
26.  Lock-Free Concurrency als Default  Architektur für Multicore-Systeme  Bewährtes Programmiermodell  8 Jahre alt, Standard-Scala-Lib  Skaliert von klein bis sehr groß  Raspberry Pi <> Twitter  Kommerzieller Support verfügbar  Schwäche: Doku verbesserungswürdig  Viel Fortschritt in letzter Zeit
27.  Transaction Processing  Concurrency / Parallele Prozesse  Simulation  Batch-Processing  Communication  Gaming and Wetten  BA / Data Mining  IoT  Event Stream Processing
28.  DDD  Aggregate Roots (AR)  Prozesse  ARs  Aktoren, Routing über die Id  Ersetzen DB-Transaktionen ◦ One Command at a time (ähnlich Row-Level-Lock)  ARs lesen nur 1x bei der 1. Nutzung ◦ Bleiben danach In-Memory ◦ Nur Updates werden persistiert
29.  Prozesse  Alles was zeitliche Aspekte hat kann kein AR sein  FSMs ideal um Prozesslogik abzubilden ◦ Viel weniger „Abfang-Code“  Child-Aktoren übernehmen einzelne Prozessschritte  Happy-Path trennen von Error-Handling  Error-Handling-Aktoren übernehmen im Fehlerfall