Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Async Messaging in CQRS: Part 2 - Akka.NET
Similar to Async Messaging in CQRS: Part 2 - Akka.NET (20)
Recently uploaded
Recently uploaded (20)
Async Messaging in CQRS: Part 2 - Akka.NET
- 1. ASYNC MESSAGING in CQRS PART 2: AKKA.NET DDD GREECE dotNETZone.gr Athens .NET
- 2. AKKA.NET
- 3. AKKA.NET ACTOR MODEL ▸ model for building systems that are ▸ distributed ▸ concurrent ▸ fault tolerant ▸ old concept (70’s) revisited ▸ Erlang/Elixir built-in support
- 4. AKKA.NET ACTOR ▸ fundamental abstraction ▸ analogy to the “object” in OO ▸ lifecycle ▸ state & behaviour ▸ live in a tree-like hierarchy ▸ created by its parent ▸ creates its children
- 6. AKKA.NET ACTOR HIERARCHY 2/2 ▸ actors have names ▸ hierarchy is an addressing model ▸ used to REFER to actors via path expressions: ▸ relative: ../z ▸ absolute: /A/w ▸ selective: /B/y/*
- 7. AKKA.NET TALKING TO ACTORS 1/3 3 // 2. 2. 2. / 2 2. 2. 1
- 8. AKKA.NET TALKING TO ACTORS 2/3 ▸ tell: fire-and-forget—like message sending ▸ ask: request/response-like message sending ▸ message delivery: Αt-Μost-Οnce WAIT … WHAT ?
- 9. AKKA.NET ASYNC & RELIABLE MESSAGING (AGAIN) ALL=CA .KI AK N ELDAK A AK AM N L KE AK ( A AE AK AM N L KE AK ) 1P D= CA - NANA ( NANA ) 1P D= CA . R ) -/3IK1KKIK ( A -/3IK = LC A E AKQ EL 142-.41 ( # , 2B LC EL IM - A Q MDA .KI AK = 1KKIK EL K=ELA E MDA A AK LC A E AKQ EL 142-.41 ) # , 2B LC EL IM - A IK = A Q MDA A AE AK MDA LC LM=QL E MDA NANA LC A E AKQ A MI A # EL - / , A AK EL I A =BMAK CAMME C MDA - LC A E AKQ EL 142-.41 # , NANAL = A AKLELMA M = KILL KI AK KALM=KML - = EM # 1 - 41 AAEA
- 10. AKKA.NET RELIABLY DELIVERY IN AKKA .NET ▸ abstractions provided (AtLeastOnceDeliveryReceiveActor) but: ▸ sending actor needs to: ▸ persist/recover (i.e. retry) outgoing messages ▸ handle confirmations ▸ receive actor needs to: ▸ send confirmations ▸ encapsulate in a reusable library
- 11. AKKA.NET (BACK TO) TALKING TO ACTORS 3/3 ▸ behaviour + state transitions happen only via messaging ▸ actors do NOT: ▸ share state ▸ refer to each other in any other way ▸ e.g. CLR refs
- 12. AKKA.NET COMMAND SENDING ▸ ActorSystem is single instance per process ▸ Context when inside Actor context ▸ references can be acquired using path expressions
- 14. AKKA.NET CONCURRENT ACTORS ▸ actors have a FIFO mailbox ▸ actor work is serialised ▸ no Threads, TPL etc.
- 15. AKKA.NET SUPERVISING ACTORS 1/3 ▸ hierarchy is also a supervision model ▸ directives: ▸ catch child(ren) exception(s) and .. ▸ resume or ▸ restart or ▸ escalate to parent or ▸ stop the faulty child(ren)
- 16. AKKA.NET SUPERVISING ACTORS 2/3 ▸ strategies ▸ one-for-one ▸ apply to the faulty child only ▸ all-for-one ▸ apply to all children
- 18. AKKA.NET HOSTING ACTORS 3 / 31432/2 443 / 31432/2 44 3 / 31432/2 44 3 / 31432/2 44 # / 44 3 # 3 # 3 4 /2 3 # # 3 /2./ TYPICALLY LONG- LIVING/ROUTING ACTORS TYPICALLY ERROR PRONE/SHORT LIVING ACTORS TYPICALLY PROCESS MANAGERS
- 19. AKKA.NET LOCATION TRANSPARENCY ‣ refer to an actor with relative paths (e.g. “/X/y”) from any host ‣ actual actor host is known by the runtime
- 21. AKKA.NET VS MASSTRANSIT ABSTRACTIONS ▸ Consumer ▸ = message handler ▸ Saga ▸ = process manager ▸ No routing abstraction ▸ Actor can be ▸ routers ▸ message handlers ▸ process managers ▸ supervisors MASSTRANSIT AKKA.NET
- 22. AKKA.NET VS MASSTRANSIT LIFECYLE ▸ Consumers/Sagas are: ▸ (re-)instantiated upon message dequeuing by the runtime ▸ disposed after message handling ▸ Actors are: ▸ instantiated and disposed by parent actors ▸ message handling decoupled from actor lifecycle MASSTRANSIT AKKA.NET
- 23. AKKA.NET VS MASSTRANSIT MESSAGING PATTERNS ▸ At-Most-Once ▸ No Built-in At-Least- Once support ▸ Tell, Ask ▸ No Built-In Pub/Sub support ▸ At-Least-Once ▸ Send, Request/Response, Pub/Sub AKKA.NETMASSTRANSIT
- 24. AKKA.NET VS MASSTRANSIT ROUTING ▸ Routing non-leaf level actors. ▸ Pools: create the actors (routees) messages will be routed to ▸ Groups: get routees by ref ▸ RoundRobin(Group), BroadCast(Group), ConsistentHashing(Group), OurOwn(Group) ▸ Routing topology auto- created ▸ Customise only via the transport API ▸ Message name(space)- based routing AKKA.NETMASSTRANSIT
- 25. AKKA.NET VS MASSTRANSIT ERROR HANDLING ▸ coordinated▸ per handler AKKA.NETMASSTRANSIT
- 26. AKKA.NET VS MASSTRANSIT IN-PROCESS PARALLELISM & CONCURRENCY ▸ Named Actor + Mailbox = Concurrency Checks “Avoidance” ▸ Re-use as-is in-process ▸ Threadpool ▸ Basic Parallelism ▸ Concurrency very Hard ▸ “Concurrency”Limit: ▸ = pool size ▸ No in-process support ▸ use TPL AKKA.NETMASSTRANSIT
- 27. AKKA.NET TYPICAL SYSTEM with CQRS + ASYNC PROCESSING / * -BBB 3 B BB # / A A * 3 BB # 3 A A BC A B A C A C B BC C B 2 3 AB BCB BC C CB B B A B B CB C B BB # B 3B C 2 3 A B C A 3 3 . 3 - 3 C 2 B BC C# / A A * ( 3 A A A 2 BB C 3 AB# C A 2 BB# C B B2A A# / A A * ) 2 ACB CB C A 3 3 2CB 3 AB BCB /A C 3
- 28. AKKA.NET FROM MASSTRANSIT TO AKKA.NET ▸ worker app serves as router for out-of-process event pub/sub ▸ command issuing apps: ▸ ref non-leaf level actors routing/life-cycle mgmt actors ▸ live in worker apps ▸ worker apps ▸ create actor hierarchy used for command and event handling
- 29. AKKA.NET VS MASSTRANSIT INDICATIONS FOR AKKA.NET 1/3 ▸ many aggregates and very often rehydrations ▸ “hot” aggregate instances via actor lifecycle control ▸ selective disposal via actor selection and supervision ▸ massively parallel but ordered command/event handling ▸ avoid concurrency check with named actors + one mailbox per actor
- 30. AKKA.NET VS MASSTRANSIT INDICATIONS FOR AKKA.NET 2/3 ▸ resource usage pattern vary significantly ▸ load-balanced routing ▸ infrastructure locality is important ▸ content-based routing ▸ coordination on infra error handling necessary ▸ policy-based supervision
- 31. AKKA.NET VS MASSTRANSIT INDICATIONS FOR AKKA.NET 3/3 ▸ transport infra (RabbitMQ, AzureServiceBus, etc.) infeasible ▸ own transport ▸ stressed transport broker(ing) adds latency ▸ own transport is p2p
- 33. RESILIENCE
- 34. RESILIENCY IS THE ABILITY TO WITHSTAND CERTAIN TYPES OF FAILURE AND YET REMAIN FUNCTIONAL FROM THE CUSTOMER PERSPECTIVE David Bills - Microsoft RESILIENCE
- 35. RESILIENCE CUSTOMER BILLING: REQUIREMENTS CUSTOMER BILLING PROCESS v1 ▸ on cargo delivery to destination location 1. collect payment 2. if payment succeeds A. issue an invoice B. notify the customer for payment success + attach invoice 3. otherwise notify the customer for payment failure
- 36. RESILIENCE CUSTOMER BILLING: INVARIANT ▸ Payment.Success AND ▸ InvoiceNumber != No.Invoice
- 37. RESILIENCE WARNING ASYNC MESSAGING != ASYNC/AWAIT
- 38. RESILIENCE ATTEMPT 1 - SYNC HANDLING OF DELIVERYSTATECHANGED
- 39. RESILIENCE ATTEMPT 2 - ASYNC + RETRY
- 40. RESILIENCE ATTEMPT 3 - ASYNC + RETRY + IDEMPOTENT 1/3 IDEMPOTENT PAYMENT COLLECTING
- 41. RESILIENCE ATTEMPT 3 - ASYNC + RETRY + IDEMPOTENT 2/3
- 42. RESILIENCE ATTEMPT 4 - ASYNC + RETRY + IDEMPOTENT + PROCESS DATA
- 43. RESILIENCE ATTEMPT 4 - DISCUSSION 1/2 ▸ need to persistently maintain process data: ▸ current process state ▸ Payment Executed, Issue Invoiced etc .. ▸ output of current action ▸ = input of next action
- 44. RESILIENCE ATTEMPT 4 - DISCUSSION 2/2 Action When State New State Data Needed Next Action Execute Payment None Payment Executed DeliveryState Changed Issue Invoice Issue Invoice Payment Executed Invoice Issued PaymentResult. Success & TransactionId Notify Customer Notify Customer Invoice Issued Customer Notified Invoice.Link Update Domain Update Domain Customer Notified Completed PaymentResult. Success & TransactionId, Invoice.Number N/A
- 45. RESILIENCE IDEA ▸ one handler per action ▸ sets the current state ▸ sends a command (to the next handler) ▸ incl. action output (needed for next action) STILL RESILIENT ?
- 46. RESILIENCE ATTEMPT 5 - ONE HANDLER PER ACTION
- 47. RESILIENCE ATTEMPT 5 - DISCUSSION ▸ handlers need to know the process context ▸ to set the current state ▸ to “invoke” the next action ▸ “UpdateDomain” Command ??? INCREASED COUPLING
- 48. RESILIENCE IDEA ▸ “action” handlers … handle only commands ▸ and emit events ▸ a “manager” handler ▸ issues the commands to the “action” handlers ▸ handles emitted events and … ▸ sets process state ▸ update the domain at the end “PROCESS MANAGER”
- 49. RESILIENCE ATTEMPT 6 - PROCESS MANAGER BC A A BC A E A C C E C C DBC A A BBD E BBD E A C DBC A A BB C A BB C A C A BB E C E BBD E C DBC A C E C
- 50. RESILIENCE PROCESS MANAGER in AKKA.NET BE FAIR: MASSTRANSIT SUPPORTS PROCESS MANAGERS (SAGAS)
- 51. RESOURCES
- 52. RESOURCES OTHER ACTOR-BASED FRAMEWORKS in .NET ▸ Orleans https://dotnet.github.io/orleans/ ▸ Virtual Actor: Cleaner syntax and semantics ▸ Less Control in Lifecycle, Supervision and Topology ▸ Proto.Actor http://proto.actor/ ▸ Closer to Orleans (Virtual Actors) but more on Supervision ▸ Lightweight and very Performant ▸ .NET Core, Go, Java and Kotlin
- 53. RESOURCES LEARNING 1/2 ▸ Reactive Applications with AkkaNET https://www.manning.com/books/reactive-applications-with-akka-net Anthony Brown ▸ To be published in November (?) 2017 ▸ Reactive Messaging Patterns with the Actor Model: Applications and Integration http://a.co/70rOL4C Vaughn Vernon ▸ Scala/Java Akka ▸ Focus on messaging/EAI
- 54. RESOURCES LEARNING 2/2 ▸ Pluralsight / Building Concurrent Applications with the Actor Model in Akka.NET https://goo.gl/KXsbYn Jason Roberts ▸ 8 courses in total ▸ Akka.NET Bootcamp https://github.com/petabridge/akka-bootcamp Petabridge ▸ Free
- 55. RESOURCES READINGS ▸ The Actor Model in 10 Minutes http://www.brianstorti.com/the-actor-model/ Brian Storti ▸ Refactoring Towards Resilience Series https://jimmybogard.com/refactoring-towards-resilience-a-primer/ Jimmy Bogard
- 56. Q&A