Service Fabric, What Microservices is best intended for continuous polling from Service Bus

2
votes

I am new to Service Fabric.

We have a queue on Azure Service Bus. I want to continuously pull from the queue in my Service Fabric, process the message (execute some business logic) and save some data in the DB, then remove the message from the queue.

The Microservice should check the queue every couple of seconds to monitor for a new message.

My question is, What is the intended Microservice(s) that would pull data, process some business logic, then save to the DB. Is it A Stateless Service or a Reliable Actor

3
c#azuremicroservicesazureservicebusazure-service-fabric
do you really need a microservice ? you can use a webjob, it will be easier. If you microservice is only triggered by a queue, it is really a microservice ? – Thomas
@Thomas Yes, a web job can solve the issue, but it would complicate the architecture as the rest of the system is already on Microservices, not just this component, so it makes more sense to use something from Fabric given that it is a close match with what we are looking for. – Adam

3 Answers

3
votes

(Edit: interpreted question wrong earlier)

I'd say it's a matter of personal preference which model you choose.

You can have a stateless service running on all nodes, receiving messages and processing them on worker threads.

Actors are less able to singlehandedly process lots of messages because of the Single Entry model (limiting multi-threading options). But Actors can come in numbers. You can have many Actors listening for messages. You'd need to ensure those Actors become & stay alive though.

original answer:

This nuget package does this: https://www.nuget.org/packages/ServiceFabric.ServiceBus.Services It supports queues, topics, batching and sessions.

1
votes

Your problem space seems to fit the stateful or stateless model. Either one is fine depending on whether you need to maintain state or not.

As general guidance, consider the actor pattern to model your problem or scenario if:

  • Your problem space involves a large number (thousands or more) of small, independent, and isolated units of state and logic.
  • You want to work with single-threaded objects that do not require significant interaction from external components, including querying state across a set of actors.
  • Your actor instances won't block callers with unpredictable delays by issuing I/O operations.

Reference: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction

0
votes

You may use any. Stateless or Statefull. Is should not really matter. In my view, you can do below:

  1. Create a custom listener say "ServiceBusCommunicationListener" derived from ICommunicationListener. In the "public Task OpenAsync(CancellationToken cancellationToken)" method of ICommunicationListener, you can write code to access service bus queue.
  2. For Service Bus Queue read, you can use "Microsoft.ServiceBus.Messaging.SubscriptionClient" and use its "OnMessageAsync" method to continuously receive message.

  3. Once you have this, inside your service code, you may use StatefulService's "CreateServiceReplicaListeners" override or StatelessService's "CreateServiceInstanceListeners". 

        protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
        {
            return new[] { new ServiceReplicaListener(context => new ServiceBusCommunicationListener(context)) };
        }