Akka dotnet presentation ndc 2017
•Descargar como PPTX, PDF•
3 recomendaciones•323 vistas
The slides for my presentation at NDC Oslo 2017 about building a near real time system with Akka.NET, React and Redux.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Akka dotnet presentation ndc 2017
Similar a Akka dotnet presentation ndc 2017 (20)
Último
Último (20)
Akka dotnet presentation ndc 2017
- 1. GETTING REAL(TIME) WITH AKKA.NET, REACT AND REDUX Francis Paulin paulinfrancis@gmail.com @paulin_francis github.com/paulinfrancis
- 2. SOME STATEMENTS • Distributed systems are hard • Writing applications that can scale on demand is hard • Threading and shared state can be a total nightmare
- 4. THE REACTIVE MANIFESTO http://www.reactivemanifesto.org/ Responsive (React to users) Message-driven (React to messages) Elastic (React to load) Resilient (React to failures)
- 5. WHAT IS THE ACTOR MODEL? • A conceptual model to deal with concurrent computation • A method of concurrency in which the universal primitive is an actor
- 6. WHAT IS AN ACTOR • «Anything» can be an actor • An actor is persistent (not like a thread) • Actors can have internal state • Has an address • An actor has a mailbox
- 7. WHAT CAN ACTORS DO? • Actors react to messages sent to the mailbox • An actor can send messages to other actors (and itself) • Create new actors • Decide what to do with the next message (behaviours)
- 8. SOME VERY IMPORTANT PRINCIPLES • Observe single responsibility principle • Only interact with an actor through messages • Exactly one message is processed at once • Messages must be immutable
- 9. ACTOR HIERARCHY • All actors have a parent that supervises them • An actor can send a message to any actor, independent of the hierarchy • Let children do dangerous things
- 10. ACTOR SUPERVISION / ERROR KERNEL http://getakka.net/docs/images/ErrorKernel.png
- 11. CREATING AN ACTOR SYSTEM
- 12. NON-ACTOR CODE THAT IS NOT SAFE
- 13. NON-ACTOR CODE WITH LOCK
- 14. ACTOR CODE WITHOUT LOCKS
- 15. CREATING ACTORS
- 16. ACTOR ADDRESSES • May be to a specific actor • Could also be to a load balancer/proxy • akka://DemoActorSystem/user/ClientBridge • Provides us with location transparency
- 17. SENDING MESSAGES • Tell vs. Ask
- 18. PARENTS KNOW ABOUT CHILDREN Parent Child 2Child 1
- 19. LIMIT KNOWLEDGE BETWEEN COUSINS Parent Child 2Child 1 Cousin 2Cousin 1
- 22. REMOTING • Actor selection by address of actor on remote machine • TLS in akka 1.2 • Serializable messages • Clustering
- 23. Demo
- 24. WHEN TO USE ACTORS & WHAT HAVE WE LEARNED? • Processing pipelines • Multi-user concurrency (actor per user) • Systems with requirements to stay available • Systems designed to scale horisontally
- 25. RESOURCES • https://gitter.im/akkadotnet/akka.net • https://petabridge.com/bootcamp/ • http://bartoszsypytkowski.com/ • https://github.com/paulinfrancis/akka-ndc-2017 (code for the demo) • Pluralsight courses
Notas del editor
- Introduce myself and mention akka, .NET Rocks and why I’m here. ASK if anyone has heard about the actor model and or Akka.net Before we go any further, some background information
- A couple of statements to get in the right state of mind
- Port of AKKA (JVM) to .NET Go to getakka.net to read more and see that «we are reactive»
- Compose large systems from many smaller ones; containment and single responsibility Repond in a timely mannner Resilience is achieved by Replication, Containment Isolation Delegation. RESILIENT: failures are contained within each component Elasticity: Prevent bottlenecks by scaling up and down on demand Location transparency
- As compared to OOP, where the universal primitive is the class. In many ways similar to OOP, but instead of reacting to method calls, reacts to messages. No shared state. Not a new idea; First published in 1973
- Actors are persistant, vs threads that finish as soon as the job is done. We will get into persistant actor later. Think of actors as people; people interact by speaking (message), or by sending emails to each other.
- Talk about actor behaviours later
- No race conditions in an actor, as the actor only processes one message at a time.
- Risky stuff in child actor is especially important when you have a stateful actor
- I mentioned performing risky operations in a child
- Expensive to create actor system object. Create sparingly. Provice config explicitely, og use “hocon” in web/app.config
- Before making our first actor, let’s look at some non actor code, and what can be problematic
- Locks are ugly, and just add noise
- Because one message processed at once; OK!
- Give actors names when possible Never ever call new Explicit control over actor deployment, not like other models with auto deploy
- Show picture of multiple actors behind same address
- Note that ASK will block the actor from processing other messages Forward -> pass through; shorthand for Tell using Sender IActorRef vs. an actor selection using an actors address
- They did make them afterall
- Communicate through the top
- // Overriding postRestart to disable the call to preStart() after restarts protected override void PostRestart(Exception reason) { }
- Get rid of conditional logic & complex internal state!
- Horizontal scaling by deploying to many machines Vertical scaling by deploying actor to monster machine – Main system running on little computer, but need to offload computation to other machine