Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Controlling of messages
flow in Microservices
architecture
Architecture overview
High level overview
• One business domain = one microservice
• Each microservice has separate database
• Each microservice...
Logical components
• Has messaging interface for incoming/outgoing messages
• Use Case (unit of work) with single atomic b...
Additional requirements to logical components
• Should do all or nothing – if contain multiple actions, then
database tran...
Code examples
Following technologies used
• Masstransit – open source, lightweight message bus
http://masstransit-project....
Business process
across multiple
microservices
Incoming payment processing
1. Register new payment
For example import payment from payments file into system
Payments mic...
Simplest
implementation
Incoming payment processing
• Three console applications, could be hosted as windows
service
• Happy flow messages only
Payments service Main method
• Configure Masstransit Bus and consumers
• Start Bus
• Stop Bus on exit programm
Bus Configurator
• Configures RabbitMq Bus
• Parameters: RabbitMq Uri, Username and Password
• Executes action, allowing t...
Example of Consumer
• Implements Masstransit interface, specifying message type
• Access to message properties via consumi...
Initiation
Do Work
Work Done
Something happened – Do Work – Work Done
1. Worker subscribed to system event of known type
2. Each event of know type tri...
Unexpected exception in Do Work
Notify about failure, retry required
• Actually Initiator shouldn’t know about other microservices and
shouldn’t care abou...
Undelivered messages
In some cases messages could be lost
• Sender knows that message successfully sent
• Receiver never r...
Saga
Business Process Coordinator
Business process coordinator - Saga
Saga is stateless workflow, which:
• Defines expected message flow
• Contains failure ...
Saga initiation
• New payment saved in Payments database
• Event produced and Process Payment Saga initiated
• Saga is set...
Example of Saga with initiation only
Persisting Saga state
Three obligatory parts of Saga state
• CorrelationId – unique identifier of Saga instance
• CurrentS...
Fist step: Payment matching
• Payments microservice sends details for matching
• Payments matching microservice do matchin...
Payment matching: Matched
Manual matching required – known failure handling
• Operator finds Sagas in state “Manual matching required” and
matches p...
Manual matching required – known failure handling
During state “Payment registered” two cases possible:
• Payment matched ...
Unknown failure handling
• Generic failure message allows to use common approach for failures
• Simple approach for retry ...
Payment allocation
• Payment processing finished with payment allocation on Order
• Same approach can be used here for kno...
Described approach Pros and Cons
• Message flow is under controll
• At any point of time it is possible to
know state of b...
What we can do differently
• Do not host Saga separately – put into related microservice
For example Payments processing s...
Thank you
Upcoming SlideShare
Loading in …5
×

“Controlling of messages flow in Microservices architecture” by Andris Lubans from Intrum Global Technologies at .NET focused 63rd DevClub.lv

3,014 views

Published on

Microservices architecture has grown in popularity in recent years. It has many benefits like scalability, fault tolerance, independent deployability etc.
A common question that comes up is “Should I use orchestration or a reactive approach in my system?”. The talk will be about reactive approach with coordinator.
Andris is lead developer in Intrum Global Technologies, has experience in migrating live system to microservices architecture, .Net and Microsoft stack.

Published in: Technology
  • Be the first to comment

“Controlling of messages flow in Microservices architecture” by Andris Lubans from Intrum Global Technologies at .NET focused 63rd DevClub.lv

  1. 1. Controlling of messages flow in Microservices architecture
  2. 2. Architecture overview
  3. 3. High level overview • One business domain = one microservice • Each microservice has separate database • Each microservice has multiple logical components, one component = one business operation • Communication is done by messages via Message Queue Message Queue Microservice 1 Microservice 2 Microservice 3
  4. 4. Logical components • Has messaging interface for incoming/outgoing messages • Use Case (unit of work) with single atomic business operation • Data Access layer MSG Consumer Use Case (unit of work) DAL MSG Producer
  5. 5. Additional requirements to logical components • Should do all or nothing – if contain multiple actions, then database transaction must be used • Should be idempotent – in case of receiving same message again result must be same as for single message • Logical components must communicate only through message queue – no direct calls allowed
  6. 6. Code examples Following technologies used • Masstransit – open source, lightweight message bus http://masstransit-project.com/ • RabbitMQ – open source message broker https://www.rabbitmq.com/ Code examples will have simplifications: • In memory collections will be used instead fully functional DAL • All business logic will be part of message consumers - no separate classes
  7. 7. Business process across multiple microservices
  8. 8. Incoming payment processing 1. Register new payment For example import payment from payments file into system Payments microservice 2. Match payment with customer account Analyze payment details and try to find Customer or Order data Payments matching microservice 3. Process payment Allocate payment to Order Orders microservice
  9. 9. Simplest implementation
  10. 10. Incoming payment processing • Three console applications, could be hosted as windows service • Happy flow messages only
  11. 11. Payments service Main method • Configure Masstransit Bus and consumers • Start Bus • Stop Bus on exit programm
  12. 12. Bus Configurator • Configures RabbitMq Bus • Parameters: RabbitMq Uri, Username and Password • Executes action, allowing to register additional parameters, like receive endpoints with message consumers
  13. 13. Example of Consumer • Implements Masstransit interface, specifying message type • Access to message properties via consuming context • Publish success message with Payment Id
  14. 14. Initiation Do Work Work Done
  15. 15. Something happened – Do Work – Work Done 1. Worker subscribed to system event of known type 2. Each event of know type triggers execution of Business logic in Worker 3. Worker reports successful execution via Work Done event 4. Next Worker is optional
  16. 16. Unexpected exception in Do Work
  17. 17. Notify about failure, retry required • Actually Initiator shouldn’t know about other microservices and shouldn’t care about their failures • Handling of failures could require conditional decisions and other microservices involvement Who is responsible for retries and failure handling?
  18. 18. Undelivered messages In some cases messages could be lost • Sender knows that message successfully sent • Receiver never received message and doesn’t know about that Who should decide about resend lost messages?
  19. 19. Saga Business Process Coordinator
  20. 20. Business process coordinator - Saga Saga is stateless workflow, which: • Defines expected message flow • Contains failure handling rules • Allows to delay some steps • Allows to do conditional decisions • Has persisted current state Would be good to make Saga be responsible for message flow without knowing details
  21. 21. Saga initiation • New payment saved in Payments database • Event produced and Process Payment Saga initiated • Saga is set to sate “Registered”, meaning we have new payment to process
  22. 22. Example of Saga with initiation only
  23. 23. Persisting Saga state Three obligatory parts of Saga state • CorrelationId – unique identifier of Saga instance • CurrentState – current workflow state • PaymentId – natural key of original entity, could be more than one property in case of combined natural key Saga state should not contain Payment details
  24. 24. Fist step: Payment matching • Payments microservice sends details for matching • Payments matching microservice do matching and produces one of two messages – Matched / Not matched • If matched, Payments microservice consumes message and saves matching information and reports success to Saga • Saga consumes success message and is set to state Matched
  25. 25. Payment matching: Matched
  26. 26. Manual matching required – known failure handling • Operator finds Sagas in state “Manual matching required” and matches payment manually – produces same Payment Matched Msg
  27. 27. Manual matching required – known failure handling During state “Payment registered” two cases possible: • Payment matched and matching information saved • Payment not matched – need to be matched manually
  28. 28. Unknown failure handling • Generic failure message allows to use common approach for failures • Simple approach for retry is just produce Match Payment Trigger message from Saga, allowing matching steps to repeat from beginning • Trigger doesn’t require any knowledge about payments, only Id
  29. 29. Payment allocation • Payment processing finished with payment allocation on Order • Same approach can be used here for known or unknown failures handling
  30. 30. Described approach Pros and Cons • Message flow is under controll • At any point of time it is possible to know state of business process • Saga allows to make conditional decisions • Saga allows to delay some steps, and execute them later (Quartz plugin) • CorrelationId can be used to identify which entities belongs to same business flow in different microservices • Versioning can be implemented on business process level • Additional component to develop • Increased complexity • More messages and communication – more load to message queue • Code reusability is more complex, especially when we have some generic business operation and it must be used in multiple different Sagas
  31. 31. What we can do differently • Do not host Saga separately – put into related microservice For example Payments processing saga could be part of Payments microservice • Do not persist Saga state separately For example Payment entity can be used as Saga state • Use Courier instead or additionally to Sagas Routing slip pattern implementation – contains set of activities to execute
  32. 32. Thank you

×