Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Give your microservices a bus ride with MassTransit

1 125 vues

Publié le

Microservices architecture is still a hot topic but many do not do it right. Challenges like cross-service dependencies, orchestration and load balancing require more and more bike-shedding instead of concentrating on the business capabilities. Using asynchronous messages, many of technical issues can be solved. Learn how to use advanced messaging patterns in your services.

Slides are from a workshop given at Progressive .NET Tutorials 2017. Repository is on Github: https://github.com/alexeyzimarev/ProgNet2017.MassTransit

Publié dans : Logiciels
  • Soyez le premier à commenter

Give your microservices a bus ride with MassTransit

  1. 1. Give your (micro)services a bus ride with MassTransit Alexey Zimarev - @Zimareff
  2. 2. Who I am • My name is Alexey Zimarev • I am programming since I was 14 • First languages were Focal and Assembler for PDP11 • Work as software architect as ABAX AS in Norway • Specialise in Domain-driven design, event-sourcing, reactive and event- driven systems • Contribute to MassTransit and RestSharp • Twitter: @Zimareff
  3. 3. Quick Recap
  4. 4. Microservices • Individually deployed • Loosely coupled • Highly cohesive • Organised around business capabilities • Autonomous
  5. 5. Now some diagrams
  6. 6. Huh? Shared database? Source: nginx.com
  7. 7. Let it REST Synchronously Source: nginx.com
  8. 8. Another major challenge with the Microservices Architecture pattern is implementing changes that span multiple services. For example, let’s imagine that you are implementing a story that requires changes to services A, B, and C, where A depends upon B and B depends upon C.
  9. 9. Temporal coupling Synchronous requests
  10. 10. Failures Data loss
  11. 11. Temporal coupling • Requestor and responder need to be alive at the same time • Requestor must wait for the response • When responder is down, requestor is effectively down as well • Autonomy is gone
  12. 12. Spatial coupling
  13. 13. Spatial coupling • Requestor needs to know the responder’s address • Centralised configuration or service discovery
  14. 14. Load balancing Is lying to you, essentially Source: nginx.com Push
  15. 15. Asynchronous Messaging
  16. 16. Published in 2004 Gregor Hohpe Bobby Woolf
  17. 17. Problem Statement An enterprise has multiple applications that are being built independently, with different languages and platforms. The enterprise needs to share data and processes in a responsive way. How can I integrate multiple applications so that they work together and can exchange information?
  18. 18. Pattern Use Messaging to transfer packets of data frequently, immediately, reliably, and asynchronously, using customizable formats. Asynchronous messaging is fundamentally a pragmatic reaction to the problems of distributed systems. Sending a message does not require both systems to be up and ready at the same time.
  19. 19. Furthermore, thinking about the communication in an asynchronous manner forces developers to recognize that working with a remote application is slower, which encourages design of components with high cohesion (lots of work locally) and low adhesion (selective work remotely).
  20. 20. Message broker • Reliable infrastructure • Guarantees message delivery • Different types of routing • Scalability • Fault tolerance
  21. 21. MassTransit • Messaging framework for .NET • Open Source • Type-based routing • Middleware support • Lifecycle management • Battle tested
  22. 22. No temporal coupling Almost…
  23. 23. No spatial coupling Using channels
  24. 24. Competing consumers Real load balancing
  25. 25. Resilience
  26. 26. Basic patterns • Fire and Forget commands • Request - Reply commands with response and queries • Publish - Subscribe events, sometimes commands too
  27. 27. Fire and forget
  28. 28. Request - reply
  29. 29. Event-driven architecture • Publish domain events • Subscribers have their own concerns • Publisher does not know subscribers (and how many) • Separation of concerns • Reactive systems
  30. 30. Publish - subscribe
  31. 31. Retries • Network is not reliable • Infrastructure is not reliable • Immediate retry can help with issues like deadlocks • Delayed retries can solve race conditions
  32. 32. Scheduling • Something to be done later • Recurrent operations • Batch job 2.0
  33. 33. Diagnostics • Logging • Audit • Performance monitoring • Error queue
  34. 34. Processes aka Sagas
  35. 35. Starbucks does not use two-phase commit Gregor Hohpe http://www.enterpriseintegrationpatterns.com/rambli ngs/18_starbucks.html
  36. 36. Orchestration Microsoft CQRS Journey: Saga on Sagas
  37. 37. Saga • Message-driven process manager • Get started by a message • Sends other messages • Collects responses • Keeps own persisted state • Correlated by identity (CorrelationId)
  38. 38. Workflows with messages
  39. 39. Persistence • SQL • Entity Framework • NHibernate
  40. 40. Persistence • Document • MongoDb • Marten (PostgreSQL JSONB storage) • RavenDb (external package)
  41. 41. Persistence • Key-value store • Redis
  42. 42. Persistence • Event-sourcing • EventStore (external package)
  43. 43. Transaction uence of activities that complete together or no
  44. 44. Routing slip • Activity as part of a transaction • Itinerary describes the sequence of activities • Itinerary is executed using a routing slip • Failed activities need compensation
  45. 45. http://www.masstransit-project.com

×