Fabric di servizio di Azure e code di messaggi

Question

Ora con il servizio di assistenza di Azure, ci sarebbe un caso d'uso anche per l'uso di una soluzione di coda separata come il bus di servizio di Windows? Gli svantaggi sarebbero probabilmente un nuovo singolo punto di errore, ma ci sono aspetti positivi? Le code possono aggiungere un po 'di buffering, ma d'altra parte, Service Fabric dovrebbe essere in grado di scalare davvero bene e offrire funzionalità stateful, quindi non dovrebbero essere necessari buffer di coda?

Answer 1

Certo, il lato positivo è che servizi come Azure Service Bus e Azure Storage Queues offrono funzionalità che non sono incluse immediatamente in Service Fabric. Quindi la domanda da porsi è: si aggiunge una dipendenza del servizio esterno per ottenere quella funzionalità, oppure si rimane autonomi costruendolo da solo su Service Fabric? Un'applicazione autonoma su Service Fabric è buona, ma reinventare la funzionalità esistente non è buona, quindi devi decidere dove si trova il maggior valore e orientarti in quella direzione.

Per esempio, pensare a ..

• portabilità. Un'applicazione che è autonoma in Service Fabric può essere ospitata ovunque sia possibile eseguire Service Fabric, che è praticamente ovunque (Azure, altri cloud pubblici, macchine o data center personali, ecc.).
• Nessuna dipendenza esterna significa meno punti di errore, un singolo set di strumenti e un processo di sviluppo, distribuzione, aggiornamento e manutenzione unificato.

D'altra parte ..

• Servizi come Service Bus offrono una rich set of features. Vale la pena spendere tempo per creare e mantenere le funzionalità necessarie su Service Fabric?

Answer 2

Buona domanda! Mi piace anche questo. Nel mio caso sto usando un cluster RabbitMQ per l'accodamento. Volevo evitarlo e speravo di avere servizi Stateful usando le Code affidabili. Ho esposto un metodo per aggiungere il messaggio al servizio e utilizzare il metodo RunAsync per disconnettere i messaggi non appena arrivano. Non sono impressionato dalle prestazioni che utilizzano questo approccio, rispetto a un servizio stateless che si collega a RabbitMQ. Ma prima di arrendermi, sto pianificando di partizionare il servizio Stateful su 5 nodi e vedere se ci sono miglioramenti delle prestazioni, usando i servizi Stateful come lavoratori che consumano code.