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
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
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
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
26. Basic patterns
• Fire and Forget
commands
• Request - Reply
commands with response and queries
• Publish - Subscribe
events, sometimes commands too
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
38. Saga
• Message-driven process manager
• Get started by a message
• Sends other messages
• Collects responses
• Keeps own persisted state
• Correlated by identity (CorrelationId)
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