Date post: | 05-Dec-2014 |
Category: |
Technology |
Upload: | mauro-servienti |
View: | 300 times |
Download: | 1 times |
NServiceBusintroduction to a message based distributed
architecture
Mauro ServientiCTO @ Mastreeno, LTD
[email protected]@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