Search code examples
nservicebusazure-service-fabric

Using NServiceBus with Azure Service Fabric

I've read other questions on StackOverflow regarding using NSB on SF and also the sample on github (outdated) and I'm still not sure how to configure NServiceBus properly for this platform.

I'm looking to set up a send only publish/subscribe workflow. What I can't determine through my research is how to set this up so that only one instance of a particular service responds to the message.

For example: 3 services running on the standard 5 nodes (so pretend 5 instances of each of the 3 services).

  1. Existing load balancer routes an http request to a specific instance of Service A.
  2. Service A publishes the "OrderComplete" event
  3. Services B and C both subscribe to the event.
  4. How can I make sure that only one instance of Services B and C respond instead of all 5 instances of Service B and all 5 instances of Service C?

All the services are currently Stateless services.

I was thinking of using the AzureServiceBus or AzureStorageQueue transport.

Solution

  • Stateless approach is fine. You do not need to go into stateful services with a single partition unless you want to leverage reliable collections for your services. But let's look at both options

    Going with Stateless services

    It's ok to have multiple instances of your services. Yes, they all will create subscriptions. I'd argue that is exactly what you want - competing consumers. More service instances you have, more throughput you'll get, i.e. handling more messages.

    What I can't determine through my research is how to set this up so that only one instance of a particular service responds to the message.

    This will happen automatically due to the nature of the competing consumer transport (both ASB and ASQ).

    Going with Stateful services

    With stateful services you need to be very careful. Yes, you could go with a single partition per service, hence having a single primary replica handling your messages. But then, arguably, you're wasting your cluster resources by not utilizing them for concurrent processing of many messages. If you decide to partition your service, then you won't be able to use reliable collections as replicas of services do not share reliable collections among themselves. Should you choose to use partitioned stateful services w/o reliable collections, well, then you better to utilize stateless counterpart.

    Note: NSB will provide support for running with stateful services to take advantage of the reliable collections for persistence needs, but even then partitioning is something that would need to be through through to align with business needs. If you do not have a need like that, I'd suggest to stick to stateless services and Azure Storage persistence.