Designing distributed, scalable and reliable systems using NServiceBus

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;

Messaging patterns

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;

Message handlerswhat can we do with messages?

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;

Endpoints & HostingHandlers home

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…;

Demo

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;

What about the transport?

Supported transports

Transports needs be durable and reliable

in order to guarantee delivery

• MSMQ

• RabbitMQ

• Sql Server

• Azure ServiceBus

• Azure Storage Queues

What if you need state?Long running workflows

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;

Demo

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;

Async monitoring…of async processes

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;

Demo

Recap

• ServiceInsight is a Developer / DevOps tool:• Provides debugging capabilities;

• Can be connected to live environments controlled by ServiceControl;

If something goes wrong?Design with failure in mind

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;

Demo

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;

Q&AThanks