Give your microservices a bus ride with MassTransit
Download as PPTX, PDF6 likes1,880 views
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
![[오픈소스컨설팅]Kafka message system 맛보기](https://cdn.slidesharecdn.com/ss_thumbnails/kafkamessagesystem-180730044904-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Similar to Give your microservices a bus ride with MassTransit (20)
Ad
Recently uploaded (20)
Ad
Give your microservices a bus ride with MassTransit
- 1. Give your (micro)services a bus ride with MassTransit Alexey Zimarev - @Zimareff
- 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. Quick Recap
- 4. Microservices • Individually deployed • Loosely coupled • Highly cohesive • Organised around business capabilities • Autonomous
- 6. Huh? Shared database? Source: nginx.com
- 7. Let it REST Synchronously Source: nginx.com
- 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.
- 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. Spatial coupling
- 13. Spatial coupling • Requestor needs to know the responder’s address • Centralised configuration or service discovery
- 14. Load balancing Is lying to you, essentially Source: nginx.com Push
- 16. Published in 2004 Gregor Hohpe Bobby Woolf
- 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. 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. 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. Message broker • Reliable infrastructure • Guarantees message delivery • Different types of routing • Scalability • Fault tolerance
- 21. MassTransit • Messaging framework for .NET • Open Source • Type-based routing • Middleware support • Lifecycle management • Battle tested
- 23. No spatial coupling Using channels
- 24. Competing consumers Real load balancing
- 25. Resilience
- 26. Basic patterns • Fire and Forget commands • Request - Reply commands with response and queries • Publish - Subscribe events, sometimes commands too
- 27. Fire and forget
- 28. Request - reply
- 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
- 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. Scheduling • Something to be done later • Recurrent operations • Batch job 2.0
- 33. Diagnostics • Logging • Audit • Performance monitoring • Error queue
- 36. Starbucks does not use two-phase commit Gregor Hohpe http://www.enterpriseintegrationpatterns.com/rambli ngs/18_starbucks.html
- 37. Orchestration Microsoft CQRS Journey: Saga on Sagas
- 38. Saga • Message-driven process manager • Get started by a message • Sends other messages • Collects responses • Keeps own persisted state • Correlated by identity (CorrelationId)
- 40. Persistence • SQL • Entity Framework • NHibernate
- 41. Persistence • Document • MongoDb • Marten (PostgreSQL JSONB storage) • RavenDb (external package)
- 42. Persistence • Key-value store • Redis
- 43. Persistence • Event-sourcing • EventStore (external package)
- 45. Transaction uence of activities that complete together or no
- 46. 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