designing distributed, scalable and reliable systems using nservicebus
TRANSCRIPT
http://particular.net
Introduction to NServiceBusand the Particular Platform
Mauro Servienti
Solution Architect @ Particular Software
Mauro Servienti
Solution Architect @ [email protected]
@mauroservienti
//milestone.topics.it
Microsoft MVP - Visual C#
Learn to build better systemsfrom Udi Dahan
Advanced Distributed Systems Design
2 days (out of 5) for FREE
Join us at the Particular booth
for more information
Agenda
• What is it all about?
• Long running workflows: what if you need state?
• Async monitoring of async processes
• What if something goes wrong?
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
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;
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;
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;
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;
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…;
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;
Supported transports
Transports needs be durable and reliable
in order to guarantee delivery
• MSMQ
• RabbitMQ
• Sql Server
• Azure ServiceBus
• Azure Storage Queues
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;
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;
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;
Recap
• ServiceInsight is a Developer / DevOps tool:• Provides debugging capabilities;
• Can be connected to live environments controlled by ServiceControl;
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;
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;