NServiceBusintroduction to a message based distributed

architecture

Mauro ServientiCTO @ Mastreeno, LTD

mauro.servienti@mastreeno.com@mauroservienti

//milestone.topics.it//github.com/mauroservienti

NServiceBus trainer/supportRavenDB trainer

Microsoft MVP – Visual C#

Resources

• Slides on SlideShare://slideshare.net/mauroservienti

• Samples on GitHub://github.com/mauroservienti

– Repository: Conferences– Branch: 2014/DDDEastAnglia

SO…YOU’D LIKE TO SCALE…

Scale out and HA

• Basically means: horizontal scale & distribute;• It can also mean:

– Async;– Non coupled:

• we need to escape from the monolith;

– Non temporally coupled:• Where makes sense we should not rely on two portion

of the system to be live at the same time to work as expected

Distribution & RPC #1

Given that we have occasionally connected moving parts:

Web Frontend ShippingWCF Service

Standard RPC call to WCF

If the «Shipping» service fails, because of an hardware failure:• We can lose information;• We need to handle failures and retries manually;

Distribution & RPC #2

Given that we have network with medium to high latency:

If the connection with the «Shipping» service fails, is slow or timeouts:• We can lose information;• We slow down the whole system;

Web Frontend ShippingWCF Service

Standard RPC call to WCF

Messages

A message can be shipped to a remote service via a queue

Web Frontend #1 Shipping Endpoint #1

queueWeb Frontend #2 Shipping Endpoint #2

com

petin

g co

nsum

ers

• If one endpoint fails messages will be picked by the other(s);• On slow connections or slow endpoints the entire system is not slowed;

issues and hiccups

• “Distributed”:– We cannot rely on subsequent calls;– We cannot rely on ordering to drive the system;– We cannot rely on transactions;

• “Async”:– Async errors;– Auditing;– Retries;– Timeouts;

NServiceBusPlease welcome:

NServiceBus?

• A toolkit:– reduce the friction of async and distributed

development based on messages on top of queues;

– Transport independent;– And much more, much :-)

• A Platform:– A set of tools to designs, administer and monitor

production solutions;

Concepts

• Message– An atomic piece of information that has a semantic meaning in

the business;• Component

– Something that can handle a message;• Service

– A set of components grouped by context;• Endpoint

– A set of services grouped by:• SLA(s);• Infrastructure concerns;• Etc..;

DEMO

Recap

• Request/reply pattern;• “Easy peasy” setup with the "Host";• “Unubotrusive” mode:

– reduce versioning problems across endpoints;• Receiver doesn’t know anything of the sender:

– no coupling in the configuration;• The sender is configured to send messages

– Based on mappings in the configuration;

Concepts #2

• Command: A message that semantically identifies something to be done (imperative):– "CreateNewUser";

• Event: A message that semantically identifies something happened and immutable (past):– "NewUserCreated";

• Subscription: The notion that an endpoint is interested in an event;

DEMO

Recap

• Event based pattern;• Events are “copied” per subscriber;• Subscriptions defined in the mappings config:• Subscriptions stored in RavenDB, by default:

– Other options supported out-of-the-box• Events are, can be, .net interfaces:

– Evolution and versioning is easier: interfaces can be composed;

TRANSPORT

Transports?

• The “wire” that connects endpoints;• Supported transports (OOTB):

• MSMQ;• RabbitMQ;• Sql Server;• Azure ServiceBus & Table Queues;

• Transport independent;• In v4.x both parties must agree on the serialization format;

under the hood

• At the Sender (or publisher):– Message serialization;– Push on the transport;

• At the receiver– Message deserialization;– Component (Handler) lookup & invoke;

• Wrapped in a “transaction”:– v4 requires the DTC, v5 won’t :-);

• I hate the DTC :-P

HANDLING FAILURESShit happens…

Async failures

• First Level Retries:– Message handling is wrapped in a transaction;– By default is retried in sequence for 5 times;

• Second Level Retries:– If FLR fails all the attempts, SLR kicks in;– 5s delay -> FLR, 10s delay -> FLR, 15s delay -> FLR;

• Do not rely on hope: there is the error queue;

What are retries for and not for?

• Transient failures:– E.g. Mail server down or third party services not

available;• Bugs:

– We deployed a bug, I did :-), and we do not lose anything

• Not there to handle business exceptions:– they can, obviously, but their main target are the

DevOps guys;

DEMO

Recap

• “Easy peasy”;• Do not wrap your code in a try/catch block;• Keep your handlers small and idempotent:

– They can be retried;– The more complex they are the harder will be to

be idempotent;• The Particular Platform:

– Tool chain to handle failures;

SCALE-OUTDidn’t we start speaking about scalability?

DEMO

Recap

• Messages are an atomic piece of information:– They can be handled by one of the endpoints;

• Multiple endpoints means:– More power to the business;– Much easier to be highly available;– Upgrade without shutting down the “system”;

• If we have a storage:– We need to scale it out too;– Will it be complex? Can be, but we can;

SAGALong running processes

Long and complex

Check-out

Order ItemsPick up

Ensure ItemsIn Stock

Bill customer credit card

3rd partybilling service

Setup Order cancellation

Timeout

Start item collection

Order ready to be

shipped

Customer credit card

billed

cancellation Timeout Elapsed

OrderCancelled? yes

No

Cancel & CompleteThe order

Ship & CompleteThe order

Use

r R

eque

st

DEMO

Recap

• A long running process with a state;• Can be scaled-out;• Are concurrency safe;• Stored by default on RavenDB:

– Other options supported out-of-the-box;• Timeouts are the way to go to handle the

decision process based on a missing “answer”;

Mind…

• Keep you handling code as small as possible;• If an handler does more than one single action

it is a smell:– Exactly like a too long method;– Move to a Saga if you need a “shared” state;

• The more an handler is simple the more it will be easy to make it idempotent;

THANK YOU, WE ARE ALL SET :-)Q&A