Messaging Patterns with MassTransit

Slides for the MassTransit workshop

Transcript

1. Messaging Patterns with MassTransit
2. Cohesion Cohesion is an indication of how related and focused the responsibilities of an software element are. Coupling Coupling refers to how strongly a software element is connected to other elements.
3. Good Design High cohesion - single responsibility Low coupling - easier to change
4. Microservices Individually deployed Loosely coupled Highly cohesive Organised around business capabilities Autonomous
5. https://www.nginx.com/blog/introduction-to-microservices/
6. https://www.nginx.com/blog/introduction-to-microservices/ 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.
7. Coupling
8. Loose Coupling ...a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Components in a loosely coupled system can be replaced with alternative implementations that provide the same services.
9. Loose Coupling Reduce number of assumptions two parties make about each other when they exchange information F. Leymann - Loose Coupling and Architectural Implications
10. Behavioural The degree to which parties share assumptions regarding behaviors High behavioral coupling requires a provider to evolve its service offerings in response to changed consumer requirements. Temporal The degree to which the sending and handling of a message are connected in time A sender is dependent on a receiver being available when a message is sent http://iansrobinson.com/2009/04/27/temp oral-and-behavioural-coupling/
12. Coupling http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/
13. The availability of the overall system can be no more than that of the least available participant. The probability of failure is the joint probability of failure in any component or service. Michael Nygard - Release It!
14. Autonomy Caller and callee don’t know each other Time autonomy Caller and callee execute at their own pace Format autonomy Caller and callee may use different formats of data exchanged Platform autonomy Caller and callee may be in different environments, written in different languages,… Reference autonomy F. Leymann - Loose Coupling and Architectural Implications
15. Autonomy Reference: Send information to a logical address Time: Enhance channel with queuing capabilities F. Leymann - Loose Coupling and Architectural Implications
16. Published in 2004 Gregor Hohpe Bobby Woolf
17. Messaging 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. 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. Use Messaging to transfer packets of data frequently, immediately, reliably, and asynchronously, using customizable formats.
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. MassTransit Messaging framework for .NET Open Source Type-based routing Middleware support Lifecycle management Battle tested
21. Application code MassTransit Bus Client (RMQ) Message Bus (Broker)
22. Why use MassTransit? Concurrency Connection management Exception, retries, and poison messages Serialisation Message header and correlation Routing Consumer lifecycle management Rx.NET integration Unit testing Sagas Scheduling ...
23. Messaging Patterns Fire and Forget commands Request - Reply commands with response and queries Publish - Subscribe events, sometimes commands too
24. Message
25. public interface CustomerRegistered { string FirstName { get; } string LastName { get; } string Email { get; } string MobileNumber { get; } Address BillingAddress { get; } Address VisitingAddress { get; } }
26. Point-to-point Command Message
27. Commands High behaviour coupling Low reference autonomy Low temporal coupling High time autonomy High reliability with retries Load balancing with competing consumers
28. Retries Network is not reliable Infrastructure is not reliable Immediate retry can help with issues like deadlocks Delayed retries can solve race conditions
29. Retries in MassTransit Retry policy (first-level retry) Redelivery (second-level retry) Error queue Fault event
30. Request-Reply
31. Request-Reply High behaviour coupling Low reference autonomy High temporal coupling Low time autonomy High reliability with retries Load balancing with competing consumers
32. Publish-Subscribe Event Message
33. Event-driven architecture Publish domain events Subscribers have their own concerns Publisher does not know subscribers (and how many) Separation of concerns Reactive systems
34. Event-driven architecture Low behavioural coupling High reference autonomy Low temporal coupling High time autonomy High reliability with retries Load balancing with competing consumers
35. Diagnostics
36. Troubleshooting Logging Error queue Audit Performance monitoring