Connecting multiple SQL Server instances with Switch

Component: Transport Bridge
NuGet Package NServiceBus.Bridge (2.x)
This is a community run project
Target NServiceBus Version: 7.x

The sample demonstrates how to use Switch from NServiceBus.Bridge package to connect endpoints running SQL Server transport that use different instances of SQL Server. This is an alternative to the multi-instance mode of SQL Server transport which has been removed in Version 4.

Switch vs Backplane

Both Switch and Backplane approaches can be used replace the deprecated multi-instance mode in connecting endpoints that use different SQL Server databases. The following table contains a side-by-side comparison of both approaches

SwitchBackplane
Single switch for the entire solutionBridge-per-database, can be co-hosted in a single process
Requires DTC to ensure exactly-once processingExactly-once processing through de-duplication
All SQL Server instances must be in the same networkEach SQL Server instance can be in separate network or even data centre
Centralized forwarding configurationDistributed forwarding configuration

The Backplane approach, while more complex in terms of deployment, provides more flexibility e.g. some databases might be on-premise while others might be in the cloud.

Throughput

Both approaches can be used to increase the throughput of the entire system when performance of a single SQL Server instance becomes a bottle neck. The key to thing when using the Switch or Backplane for performance reasons is partitioning. When done wrong, it can have the opposite effect and decrease the overall throughput.

To correctly partition the system when using Switch or Backplane first cluster the endpoints based on the volume of messages exchanged. The more messages endpoint exchange, the closer they are. If all endpoints form a single cluster Switch or Backplane won't help. In a healthy system, however, there will be several clusters of endpoints of highly coupled endpoints. Assign each cluster its own instance of SQL Server. Use Switch or Backplane to connect the clusters.

Prerequisites

An instance of SQL Server Express is installed and accessible as .\SqlExpress.

At startup each endpoint will create its required SQL assets including databases, tables and schemas.

This sample automatically creates four databases: sqlswitch, sqlswitch_blue, sqlswitch_red and sqlswitch_green

Running the project

  1. Start the solution.
  2. The text Press <enter> to send a message should be displayed in the Client's console window.
  3. Hit enter several times to send some messages.

Verifying that the sample works correctly

  1. The Sales console display information about accepted orders in round-robin fashion.
  2. The Shipping endpoint displays information that orders were shipped.
  3. The Billing endpoint displays information that orders were billed.

Code walk-through

This sample contains four endpoints, Client, Sales, Shipping and Billing. The Client endpoint sends a PlaceOrder command to Sales. When PlaceOrder is processed, Sales publishes the OrderAccepted event which is subscribed by Shipping and Billing.

Client

The Client endpoint is configured to use its own, Blue, database to harden the security of the solution. This database does not contain sensitive data.

In order to route messages to Sales, Client needs to configure bridge connection

var routing = transport.Routing();
var bridge = routing.ConnectToBridge("Blue");
bridge.RouteToEndpoint(typeof(PlaceOrder), "Sales");

Sales and Shipping

The Sales and Shipping endpoints are configured to use the Red database for the transport. As Sales only publishes events, it does not need any routing or bridge configuration.

Shipping subscribes for events published by Sales and it uses the same transport database so regular logical routing is enough

var routing = transport.Routing();
routing.RegisterPublisher(typeof(OrderAccepted), "Sales");

Billing

The Billing endpoint requires even more enhanced security. It uses its own database, Green. In order to subscribe to Sales event it need to register the publisher in the bridge configuration

var routing = transport.Routing();
var bridge = routing.ConnectToBridge("Green");
bridge.RegisterPublisher(typeof(OrderAccepted), "Sales");

Switch

Similar to the Bridge, Switch connects transports. Unlike the Bridge, Switch can connect more than two transports. Each transport is added as a Port. In this sample the Switch is configured with three ports, all using SQL Server transport

var switchConfig = new SwitchConfiguration();

var blueSubscriptionStorage = new SqlSubscriptionStorage(
    () => new SqlConnection(SwitchConnectionString), 
    "Blue", 
    new SqlDialect.MsSqlServer(), 
    null);
await blueSubscriptionStorage.Install().ConfigureAwait(false);

switchConfig.AddPort<SqlServerTransport>("Blue", t =>
{
    t.ConnectionString(ConnectionStrings.Blue);
}).UseSubscriptionPersistence(blueSubscriptionStorage);


switchConfig.AddPort<SqlServerTransport>("Red", t =>
{
    t.ConnectionString(ConnectionStrings.Red);
}).UseSubscriptionPersistence(redSubscriptionStorage);

switchConfig.AddPort<SqlServerTransport>("Green", t =>
{
    t.ConnectionString(ConnectionStrings.Green);
}).UseSubscriptionPersistence(greenSubscriptionStorage);

switchConfig.AutoCreateQueues();

While the Bridge simply forwards messages from one side to the other, the Switch needs explicit forwarding configuration to find out the destination port for each message.

switchConfig.PortTable["Client"] = "Blue";
switchConfig.PortTable["Sales"] = "Red";
switchConfig.PortTable["Shipping"] = "Red";
switchConfig.PortTable["Billing"] = "Green";

The code above maps endpoints to ports.

Samples

Related Articles


Last modified