Reactive Programming in .Net - actorbased computing with Akka.Net
•
3 recomendaciones•492 vistas
Im Entwickler-Alltag finden wir uns oft in Situationen wieder in denen wir mit parallelen, nebenläufigen Systemen kämpfen. Hier kann Actorbased Programming helfen dieser Herr zu werden. Akka.Net, welches sich selbst als „toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications“ bezeichnet erlaubt es Entwicklern dieses Paradigma für sich zu nutzen.Akka.Net ist eine Portierung des von Typesafe entwickelten Actor-Framework.In der Java/Scala Welt hat es bereits einen durchschlagenden Erfolg. Akka.Net bietet nun diese Möglichkeiten für .Net-Entwickler.Im Wesentlichen soll der Vortrag auf die Basics des Actorbased Computings eingehen, sowie Parallelen zu verwandten Thematiken wie Agentbased Computing und verwandten Design-Patterns herstellen.An kleinen abstrakten Szenarien wird das Framework und eine minimale Anwendung eines Actor-Systems vorgestellt. Zum Abschluss ist geplant nochmals auf die essentielle Kommunikationspattern eingegangen.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (9)
Similar a Reactive Programming in .Net - actorbased computing with Akka.Net
Similar a Reactive Programming in .Net - actorbased computing with Akka.Net (20)
Último
Último (20)
Reactive Programming in .Net - actorbased computing with Akka.Net
- 1. akka.net
- 3. Reactive Manifest und Akka.Net
- 4. Wie kommen wir da hin? Reactive Manifesto
- 5. event Handling data flow graph processing System Architecure zuverlässige skalierbare elastic message-driven resilient responsive http://www.reactivemanifesto.org/de
- 6. Elastic react to load Message-Driven Services / Components Interaction Resilient react to failures Responsive react to users Reactive System goal methods concepts
- 11. at first, dry theory…
- 13. Carl Hewitt (1973), Actor Model of Computation: Scalable Robust Information Systems
- 17. …jetzt.
- 18. • Typesafe: Actor-Framework • Scala (JVM) => Java • ausgereiftes, erprobtes Framework • Akka.Net • Portierung von Akka (2013) • Aaron Stannard Roger Johansson • http://getakka.net akka.net
- 19. Concurreny Scalability Fault-tolerance Simpler Programming Model Managed Runtime Open Source Distribution …with a single unified
- 25. PM> Install-Package Akka nuget using Akka.Actor; using (var actorSystem = ActorSystem.Create("MyActorSystem")) { // universe } nur innerhalb dieses Blocks „leben“ Aktoren var actorSystem = ActorSystem.Create("MyActorSystem")); // universe actorSystem.WhenTerminated.Wait(); // wait for termination-task actorSystem.AwaitTermination(); // deprecated oder
- 26. // universe IActorRef myActor = actorSystem.ActorOf( Props.Create(() => new MyActor()) ); using (var actorSystem = ActorSystem.Create("MyActorSystem")) { } // talk to the actor myActor.Tell(new SomeMessage("rise up slave...")); erzeuge AktorSystem fordere spezifischen Aktor an sprich mit dem erhaltenen Aktor
- 27. public class SomeMessage { public SomeMessage(string name) { Name = name; } public string Name { get; private set; } } public class MyActor : ReceiveActor { public MyActor() { Receive<string>(message => { Sender.Tell(message); }); Receive<SomeMessage>(message => { // react to message }); } } alle Nachrichten sind immutable Nachrichten werden prinzipiell nach ihrem Typ unterschieden * * es geht fein-granularer und abstrakter
- 28. Receive<string>(s => Console.WriteLine("Received string: " + s)); //1 Receive<int>(i => Console.WriteLine("Received integer: " + i)); //2 IActorRef sender = Sender;
- 29. //Receive using Funcs Receive<string>(s => { if (s.Length > 5) { Console.WriteLine("1: " + s); return true; } return false; }); Receive<string>(s => Console.WriteLine("2: " + s)); //predicates Receive<string>(s => s.Length > 5, s => Console.WriteLine("1: " + s)); //1 Receive<string>(s => s.Length > 2, s => Console.WriteLine("2: " + s)); //2 Receive<string>(s => Console.WriteLine("3: " + s)); //handler priority Receive<string>(s => s.Length > 5, s => Console.WriteLine("1: " + s)); //1 Receive<string>(s => s.Length > 2, s => Console.WriteLine("2: " + s)); //2 Receive<string>(s => Console.WriteLine("3: " + s)); //3
- 31. public class MyActor : ActorBase { public MyActor() { //nothing todo } protected override bool Receive(object _message) { //handle different messages var message = _message as SomeMessage; if(message != null) { return false; } return false; } } Nachrichten werden prinzipiell nach ihrem Typ unterschieden * * es geht fein-granularer und abstrakter
- 32. using Akka.Actor; public class MyUntypedActor : UntypedActor { protected override void OnReceive(object message) { var msg = message as Messages.InputError; if (msg != null) { // cool, its for me } else { Unhandled(message); //from ActorBase } } } • anders als beim ReceiveActor müssen nicht behandelte Nachrichten selbst als solche markiert werden
- 33. IActorRef friend = Context.ActorOf(Props.Create(() => new MyReceiveActor())); sender.Tell(new SomeMessage("Re: " + message.Name)); IActorRef friend = ... friend.Tell(new SomeMessage("Forward: " + message.Name), sender); IActorRef friend = ... friend.Forward(new SomeMessage("Forward: " + message.Name)); forward tell + explicit sender tell
- 34. Nicht die da, andere….
- 35. event-driven thread Actor Behavior Mailbox State Childs Supervisor-Strategy ActorRef 1 2 34 Transport [Akka] IActorRef myActor = ... myActor.Tell(new Message("four")); • IActorRef: handle oder reference auf einen Actor • Nachrichten werden niemals direkt an einen Actor gesendet • ActorSystem fügt Metadaten (Sender, Empfänger) hinzu • ActorSystem garantiert Ankunft jeder Nachricht *
- 36. IActorRef • Actor Namen sind optional • best practise: named actors Create Look up IActorRef myActor = actorSystem.ActorOf( Props.Create(() => new MyActor()), "myactor1" ); • adressierbar über ActorPath • Actoren bilden eine Hierarchy Parent Children Sender ActorSelection randomActor = actorSystem.ActorSelection("akka://ActorSys/user/myactor1");
- 37. Props props1 = Props.Create(typeof(MyActor)); Props props2 = Props.Create(() => new MyActor()); Props props3 = Props.Create<MyActor>(); typeof Syntax lambda Syntax generic Syntax • einzigerWeg um Parameter zu übergeben • unsicher Context.ActorOf(props2); actorSystem.ActorOf(props2); aus einem Actor heraus: direkt im ActorSystem: -> erzeugt HierarchieVerwendung
- 40. /syst em Guardians /a1 /a2 top level actor /b1 /c1 /cx /b2 /c2 /cx akka://ActorSystem/user akka://ActorSystem/user/a1 akka://ActorSystem/user/a1/b2 akka://ActorSystem/user/a1/*/cx /user /
- 42. parent parent Failure SupervisionStrategy • Restart, Stop, Resume, Escalate • 2 Default-Strategien: One-For-One und All-For-One
- 43. • erklärtes Ziel ist es Fehler einzugrenzen: • localizing the failure: fehleranfälligen Code The critical thing to know here is that *whatever action is taken on a parent propagates to its children*. If a parent is halted, all its children halt. If it is restarted, all its children restart.
- 44. protected override SupervisorStrategy SupervisorStrategy() { // immer die gleiche Entscheidung return new OneForOneStrategy( maxNrOfRetries: 10, withinTimeRange: TimeSpan.FromSeconds(30), localOnlyDecider: exception => { Console.WriteLine("*** Supervision: Restart"); return Directive.Restart; } ); }
- 47. public class MvcApplication : HttpApplication { protected void Application_Start() { //ASP.Net Stuff: Filters, Routes, ... //Akka init GameActorSystem.Create(); } void Application_End() { GameActorSystem.Shutdown(); } }
- 48. public static class GameActorSystem { private static ActorSystem ActorSystem; private static IGameEventsPusher _gameEventsPusher; public static void Create() { _gameEventsPusher = new SignalRGameEventPusher(); ActorSystem = Akka.Actor.ActorSystem.Create("GameSystem"); ActorReferences.GameController = ActorSystem.ActorOf<GameControllerActor>(); ActorReferences.SignalRBridge = ActorSystem.ActorOf( Props.Create(() => new SignalRBridgeActor(_gameEventsPusher, ActorReferences.GameController)), "SignalRBridge„ ); } public static void Shutdown() { ActorSystem.Shutdown(); ActorSystem.AwaitTermination(TimeSpan.FromSeconds(1)); } public static class ActorReferences ... }
- 49. class SignalRGameEventPusher : IGameEventsPusher { private static readonly IHubContext _gameHubContext; static SignalRGameEventPusher() //static CTOR { _gameHubContext = GlobalHost.ConnectionManager.GetHubContext<GameHub>(); } public void PlayerJoined(string playerName, int playerHealth) { _gameHubContext.Clients.All.playerJoined(playerName, playerHealth); } public void UpdatePlayerHealth(string playerName, int playerHealth) { _gameHubContext.Clients.All.updatePlayerHealth(playerName, playerHealth); } } GameHub [SignalR] ActorSystem [Akka] playerJoined updatePlayerHealth Clients Clients Clients
- 50. public class GameHub : Hub { public void JoinGame(string playerName) { GameActorSystem .ActorReferences .SignalRBridge .Tell(new JoinGameMessage(playerName)); } public void Attack(string playerName) { GameActorSystem .ActorReferences .SignalRBridge .Tell(new AttackPlayerMessage(playerName)); } } GameHub [SignalR] join attack ActorSystem [Akka]
Notas del editor
- shared nothing, almost maximum isolation between services no shared state (including persistence) no shared domain model or logic easy scale out & easy failover share non-functional infrastructure code network access, serialization, failover, … ---- These changes are happening because application requirements have changed dramatically in recent years. Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data. Today applications are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today's demands are simply not met by yesterday’s software architectures.
- http://www.reactivemanifesto.org/ Elastizität (im Unterschied zu Skalierbarkeit) Englisch: elasticity (in contrast to scalability) Elastizität bedeutet, dass der Durchsatz eines Systems automatisch erhöht oder vermindert werden kann, um sich an sich verändernde Lastbedingungen anzupassen. Voraussetzung hierfür ist die Skalierbarkeit des Systems, damit der Durchsatz von vermehrten Ressourcen profitieren kann. Elastizität erweitert also den Begriff der Skalierbarkeit um automatisches Ressourcenmanagement.
- Responsiveness = React to users / clients in timely manner (lags, „the system is down“) Avoid slow responses often means: tied up resources in calling and called system Disk IO, Out of Memory, … slow systems aren‘t usable a responsive System depends on Resilient and Elastic one
- Responsiveness = React to users / clients in timely manner (lags, „the system is down“) Avoid slow responses often means: tied up resources in calling and called system Disk IO, Out of Memory, … slow systems aren‘t usable a responsive System depends on Resilient and Elastic one
- Resilient = A resilient system react to failures it keeps processing transactions, even when there are: transient impulses persistent stresses or component failures disrupting normal processing often meant by people that say stability --- in realworld: redundancy supervisor bulk head delegation low coupled components --- Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.
- Elastic = A elastic system can allocate / deallocate resources for every indivdual component (service) dynamically to match demands --- Elasticity is about resources (resources are constraint) [CPUs, Memory, VMs, …] good Idea: share N resources between M applications --- They achieve elasticity in a cost-effective way on commodity hardware and software platforms. --- Vertikale Skalierung (scale up) -> become bigger Horizontale Skalierung (scale out) -> become more --- Scalability Haiku Avoid all shared resources if you can‘t avoid it: try to batch and never block Abstraction Thread vs. Task Locking vs. Hiding & Proxying Isolation and Abstraction over Resources and State with Message-Driven Architecture
- Resilient = A resilient system react to failures it keeps processing transactions, even when there are: transient impulses persistent stresses or component failures disrupting normal processing often meant by people that say stability --- in realworld: redundancy supervisor bulk head delegation low coupled components --- Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.
- Following Hewitt, Bishop, and Steiger's 1973 publication, Irene Greif developed an operational semantics for the Actor model as part of her doctoral research.[4] Two years later, Henry Baker and Hewitt published a set of axiomatic laws for Actor systems.[5][6] Other major milestones include William Clinger's 1981 dissertation introducing a denotational semantics based on power domains[3] and Gul Agha's 1985 dissertation which further developed a transition-based semantic model complementary to Clinger's.[7] This resulted in the full development of actor model theory. CSP: Communicating Sequential Processes / Theoretical Communicating Sequential Processes (TCSP) „Calculus of Communicating Systems“ „Algebra of Communicating Processes“ Pi-Kalkül
- Following Hewitt, Bishop, and Steiger's 1973 publication, Irene Greif developed an operational semantics for the Actor model as part of her doctoral research.[4] Two years later, Henry Baker and Hewitt published a set of axiomatic laws for Actor systems.[5][6] Other major milestones include William Clinger's 1981 dissertation introducing a denotational semantics based on power domains[3] and Gul Agha's 1985 dissertation which further developed a transition-based semantic model complementary to Clinger's.[7] This resulted in the full development of actor model theory. CSP: Communicating Sequential Processes / Theoretical Communicating Sequential Processes (TCSP) „Calculus of Communicating Systems“ „Algebra of Communicating Processes“ Pi-Kalkül
- Following Hewitt, Bishop, and Steiger's 1973 publication, Irene Greif developed an operational semantics for the Actor model as part of her doctoral research.[4] Two years later, Henry Baker and Hewitt published a set of axiomatic laws for Actor systems.[5][6] Other major milestones include William Clinger's 1981 dissertation introducing a denotational semantics based on power domains[3] and Gul Agha's 1985 dissertation which further developed a transition-based semantic model complementary to Clinger's.[7] This resulted in the full development of actor model theory. CSP: Communicating Sequential Processes / Theoretical Communicating Sequential Processes (TCSP) „Calculus of Communicating Systems“ „Algebra of Communicating Processes“ Pi-Kalkül
- An actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other actors; create a finite number of new actors; designate the behavior to be used for the next message it receives. There is no assumed sequence to the above actions and they could be carried out in parallel. Decoupling the sender from communications sent was a fundamental advance of the Actor model enablingasynchronous communication and control structures as patterns of passing messages.[9] Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created. The Actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronousmessage passing with no restriction on message arrival order. -------- functions, coroutines, processes, numbers, lists, databases, and devices should be represented as actors
- An actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other actors; create a finite number of new actors; designate the behavior to be used for the next message it receives. There is no assumed sequence to the above actions and they could be carried out in parallel. Decoupling the sender from communications sent was a fundamental advance of the Actor model enablingasynchronous communication and control structures as patterns of passing messages.[9] Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created. The Actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronousmessage passing with no restriction on message arrival order. -------- The actor theory requires that everything in the system, functions, coroutines, processes, numbers, lists, databases, and devices should be represented as actors, and be capable of receiving messages. This may seem at first a little dogmatic, but there are important practical benefits that arise from having a totally actor-oriented system.
- Never think in terms of shared state, state visibility, threads, locks, concurrent collections, thread notifications etc. Low level concurrency plumbing BECOMES SIMPLE WORKFLOW - you only think about how messages flow in the system You get high CPU utilization, low latency, high throughput and scalability - FOR FREE as part of the model Proven and superior model for detecting and recovering from errors ------ Actors are location transparent & distributable by design Scale UP and OUT for free as part of the model You get the PERFECT FABRIC for the CLOUD elastic & dynamic fault-tolerant & self-healing adaptive load-balancing, cluster rebalancing & actor migration build extremely loosely coupled and dynamic systems that can change and adapt at runtime
- Never think in terms of shared state, state visibility, threads, locks, concurrent collections, thread notifications etc. Low level concurrency plumbing BECOMES SIMPLE WORKFLOW - you only think about how messages flow in the system You get high CPU utilization, low latency, high throughput and scalability - FOR FREE as part of the model Proven and superior model for detecting and recovering from errors ------ Actors are location transparent & distributable by design Scale UP and OUT for free as part of the model You get the PERFECT FABRIC for the CLOUD elastic & dynamic fault-tolerant & self-healing adaptive load-balancing, cluster rebalancing & actor migration build extremely loosely coupled and dynamic systems that can change and adapt at runtime
- Never think in terms of shared state, state visibility, threads, locks, concurrent collections, thread notifications etc. Low level concurrency plumbing BECOMES SIMPLE WORKFLOW - you only think about how messages flow in the system You get high CPU utilization, low latency, high throughput and scalability - FOR FREE as part of the model Proven and superior model for detecting and recovering from errors ------ Actors are location transparent & distributable by design Scale UP and OUT for free as part of the model You get the PERFECT FABRIC for the CLOUD elastic & dynamic fault-tolerant & self-healing adaptive load-balancing, cluster rebalancing & actor migration build extremely loosely coupled and dynamic systems that can change and adapt at runtime
- Transaction processing (Online Gaming, Finance/Banking, Trading, Statistics, Betting, Social Media, Telecom) Scale up, scale out, fault-tolerance / HA Service backend (any industry, any app) Service REST, SOAP, Cometd, WebSockets etc Act as message hub / integration layer Scale up, scale out, fault-tolerance / HA Concurrency/parallelism (any app) Correct Simple to work with and understand Just add the jars to your existing JVM project (use Scala, Java, Groovy or JRuby) Simulation Master/Worker, Compute Grid, MapReduce etc. Batch processing (any industry) Camel integration to hook up with batch data sources Actors divide and conquer the batch workloads Communications Hub (Telecom, Web media, Mobile media) Scale up, scale out, fault-tolerance / HA Gaming and Betting (MOM, online gaming, betting) Scale up, scale out, fault-tolerance / HA Business Intelligence/Data Mining/general purpose crunching Scale up, scale out, fault-tolerance / HA Complex Event Stream Processing Scale up, scale out, fault-tolerance / HA
- NOTE: When creating Props, ActorSystem, or ActorRef you will very rarely see the new keyword. These objects must be created through the factory methods built into Akka.NET. If you're using new you might be making a mistake.
- NOTE: When creating Props, ActorSystem, or ActorRef you will very rarely see the new keyword. These objects must be created through the factory methods built into Akka.NET. If you're using new you might be making a mistake.
- NOTE: When creating Props, ActorSystem, or ActorRef you will very rarely see the new keyword. These objects must be created through the factory methods built into Akka.NET. If you're using new you might be making a mistake.
- With an UntypedActor, unhandled messages are not logged as unhandled unless you manually mark them as such, like so: However, in a ReceiveActor—which we cover in Unit 2—unhandled messages are automatically sent to Unhandled so the logging is done for you.
- Anmerkung: Messages SIND immutable ------ Messages Are Immutable Time for a fun developer buzzword that will make you sound really smart:immutability! So what’s an “immutable” object? An immutable object is an object who’s state (i.e. the contents of its memory) cannot be modified once it’s been created. If you’re a .NET developer, you’ve used the string class. Did you know that in .NETstring is an immutable object? Let me give you an example: var myStr = "Hi!".ToLowerInvariant().Replace("!", "?"); In this example, the following occurs in this order: .NET allocates a const string with the content Hi!” and then ToLowerInvariant() is called, which copies the original “Hi!” string and modifies the copy to become all lowercase and returns the modified copy (which now reads as “hi!”) Then .Replace(string,string) is called, which copies the “hi!” string returned byToLowerInvariant and modifies the copy to substitute ! with ? and returns the modified copy, with the final result reading as “hi?” Since the original string is immutable, all of these operations had to make a copy of the string before they could make their changes. Immutable messages are inherently thread-safe. No thread can modify the content of an immutable message, so a second thread receiving the original message doesn’t have to worry about a previous thread altering the state in an unpredictable way.
- You do talk to them, just not directly :) You have to talk to them via the intermediary of the ActorSystem. It gives you better information to work with and messaging semantics. The ActorSystem wraps all messages in anEnvelope that contains metadata about the message. This metadata is automatically unpacked and made available in the context of your actor. It allows "location transparency": this is a fancy way of saying that you don't have to worry about which process or machine your actor lives in. Keeping track of all this is the system's job. This is essential for allowing remote actors, which is how you can scale an actor system up to handle massive amounts of data (e.g. have it work on multiple machines in a cluster). More on this later.
- *CAUTION*: Do NOT call new MyActorClass() outside of Props and the ActorSystem to make an actor.
- There are two key reasons actors exist in a hierarchy: To atomize work and turn massive amounts of data into manageable chunks To contain errors and make the system resilient Since parents supervise their children, this means that every actor has a supervisor, and every actor can also BE a supervisor.
- / - The Root Guardian /user – Root Actor Actor path == actor position in hierarchy
- Here's the sequence of events when an error occurs: Unhandled exception occurs in child actor (c1), which is supervised by its parent (b1). c1 suspends operations. The system sends a Failure message from c1 to b1, with the Exception that was raised. b1 issues a directive to c1 telling it what to do. Life goes on, and the affected part of the system heals itself without burning down the whole house. The critical thing to know here is that *whatever action is taken on a parent propagates to its children*. If a parent is halted, all its children halt. If it is restarted, all its children restart.Kittens and unicorns, handing out free ice cream and coffee to be enjoyed while relaxing on a pillowy rainbow. Yay! ---- Restart the child (default): this is the common case, and the default. Stop the child: this permanently terminates the child actor. Escalate the error (and stop itself): this is the parent saying "I don't know what to do! I'm gonna stop everything and ask MY parent!" Resume processing (ignores the error): you generally won't use this. Ignore it for now.
- Here's the sequence of events when an error occurs: Unhandled exception occurs in child actor (c1), which is supervised by its parent (b1). c1 suspends operations. The system sends a Failure message from c1 to b1, with the Exception that was raised. b1 issues a directive to c1 telling it what to do. Life goes on, and the affected part of the system heals itself without burning down the whole house. The critical thing to know here is that *whatever action is taken on a parent propagates to its children*. If a parent is halted, all its children halt. If it is restarted, all its children restart.Kittens and unicorns, handing out free ice cream and coffee to be enjoyed while relaxing on a pillowy rainbow. Yay! ---- Restart the child (default): this is the common case, and the default. Stop the child: this permanently terminates the child actor. Escalate the error (and stop itself): this is the parent saying "I don't know what to do! I'm gonna stop everything and ask MY parent!" Resume processing (ignores the error): you generally won't use this. Ignore it for now.