Designing distributed, scalable and reliable systems using NServiceBus

1. http://particular.net
Introduction to NServiceBus
and the Particular Platform
Mauro Servienti
Solution Architect @ Particular Software

2. Mauro Servienti
Solution Architect @ Particular
mauro.servienti@particular.net
@mauroservienti
//milestone.topics.it
Microsoft MVP - Visual C#

3. Learn to build better systems
from Udi Dahan
Advanced Distributed Systems Design
2 days (out of 5) for FREE
Join us at the Particular booth
for more information

4. Agenda
• What is it all about?
• Long running workflows: what if you need state?
• Async monitoring of async processes
• What if something goes wrong?

5. Tenets
• NServiceBus is built around and enforces the following tenets:
• Boundaries are explicit
• Services are autonomous
• Services share schema & contract, not class
• Service compatibility is based upon policy

6. Messages, commands and events
• Messages:
• An atomic piece of information;
• Used to drive the system forward;
• Commands:
• Are imperative messages;
• Are directed to a well known receiver;
• Events:
• Are an immutable representation of something that occurred in the past;
• Are directed to anyone interested;
• Commands and Events are messages with a semantic meaning:
• NServiceBus enforces the semantic of commands and events;

7. Messaging patterns

8. Request / Response
• A message is sent to a destination;
• The receiver of the message can reply back;
• The sender knows the receiver perfectly:
• Knows where the receiver is;
• Knows what to send;
• The receiver:
• Does not necessarily know where the sender is;
• Knows what the sender expects: what to reply;
• There is coupling between the sender and the receiver;

9. Publish / Subscribe
• An actor in the system acted on something:
• The actor can broadcast an event to the entire system;
• The publisher is not interested in who is interested in the event;
• Another actor in the system can be interested in an event:
• The actor will subscribe to the interesting event(s);
• The intent is on the subscriber’s side;
• The subscriber knows the publisher, not the other way round;
• The publisher will deliver a copy of the event to each subscriber;
• There is less coupling between the publisher and the subscriber;

10. Message handlers
what can we do with messages?

11. Handling messages
• Each time a message is received a handler is invoked;
• A handler is the “container” (class) that hosts our code;
• A handler is stateless:
• Each time a message is received a new handler is created and invoked;

12. Endpoints & Hosting
Handlers home

13. Where do handlers live?
• Handlers are grouped by service (a logical concept);
• Services are hosted in Endpoints;
• Endpoint instances run on Windows machines:
• As Windows Services:
• Can be self hosted;
• Can leverage the NServiceBus.Host;
• Self-hosted in any application type, web, console, WPF, etc…;

14. Demo

15. Recap
• We saw what Endpoints, Messages and Handlers are;
• How to configure an endpoint using the BusConfiguration;
• How to exchange messages:
• using the request/response pattern;
• using the publish/subscribe pattern;
• How message routing works;

16. What about the transport?

17. Supported transports
Transports needs be durable and reliable
in order to guarantee delivery
• MSMQ
• RabbitMQ
• Sql Server
• Azure ServiceBus
• Azure Storage Queues

18. What if you need state?
Long running workflows

19. Sagas
• Sagas are durable, state full, reliable workflows:
• Can be scaled out;
• Can survive failures;
• Are highly available and fault tolerant;
• Sagas guarantee state persistence across message handling;
• Guarantee state consistency in a scaled out environment;
• Allow to express message and state correlation;
• Empower “timeouts” to make decisions in an async world;

20. Demo

21. Recap
• Persistence can be:
• RavenDB;
• any RDBMS via NHibernate;
• Azure Storage Tables;
• Sagas:
• Are orchestrators that coordinate the work among multiple endpoints;
• Can be started by commands or events;
• Can be started by multiple messages;

22. Async monitoring
…of async processes

23. Auditing
• In a system composed of multiple actors can be easy to lose control:
• Of the overall status of the system;
• Of the status of each actor in the system, especially if distributed;
• NServiceBus has auditing ‘on’ by default via “Audit” queues;
• An audit queue is just a queue;
• ServiceControl is the under the hood tool that monitors Audit queues;
• ServiceInsight is one of the monitoring tools we supply;

24. Demo

25. Recap
• ServiceInsight is a Developer / DevOps tool:
• Provides debugging capabilities;
• Can be connected to live environments controlled by ServiceControl;

26. If something goes wrong?
Design with failure in mind

27. Handling async failures can be hard
• When a system is driven by messages we cannot lose anything:
• Losing a message equals to a corrupted system;
• We need to face 2 main types of error:
• transient failures;
• business errors;
• If a message fails:
• -> First level retries;
• -> Second Level retries;
• -> Error queue;
• ServiceControl is the under the hood tool that monitors error queues;
• ServicePulse is the Ops / DevOps monitoring tool;

28. Demo

29. Recap
• That wasn't so hard;
• ServicePulse is the monitoring tool to monitor the entire system;
• The system itself can react to failures using ServiceControl events;

30. Q&A
Thanks