Invio di una richiesta all’API Web Core di ASP.Net in esecuzione su un nodo specifico in un cluster Fabric Service

Sto lavorando a un’applicazione Service Fabric, in cui sto eseguendo la mia applicazione che contiene un sacco di API Web ASP.NET Core. Ora quando eseguo la mia applicazione sul mio fabric fabric del servizio locale configurato con 5 nodes, l’applicazione viene eseguita correttamente e sono in grado di inviare richieste post le API Web esposte. In realtà voglio colpire il codice in esecuzione su uno stesso nodo di cluster con richieste di post diverse alle API esposte su quel particolare nodo.

Per ulteriori spiegazioni, ad esempio, esiste un’API esposta sul nodo ‘0’ che accetta una richiesta di posta ed esegue un lavoro, e inoltre vi è un’API che interrompe il lavoro in esecuzione. Ora quando richiedo di eseguire un Job, inizia ad eseguire sul nodo ‘0’, ma quando provo ad abortire il Job, il cluster del fabric di servizi inoltra la richiesta a un nodo diverso, ad esempio dica il nodo ‘1’. Nel risultato non ho potuto abortire il lavoro in esecuzione perché non c’è lavoro in corso disponibile sul nodo ‘1’. Non so come gestire questa situazione.

Per gli stati, sto usando un servizio stateless di tipo ASP.Net Core Web API ed eseguendo l’app su 5 nodes del mio fabric fabric cluster locale.

Si prega di suggerire quale dovrebbe essere l’approccio migliore.

Il tuo problema è dovuto al fatto che stai eseguendo le tue API per svolgere un’attività di lavoro.

Dovresti usare la tua API per pianificare il lavoro in Background (Process \ Worker) e restituire all’utente un token o un id operativo. L’utente utilizzerà questo token per richiedere lo stato o annullare l’attività.

Il primo passo : quando chiami la tua API per la prima volta, potresti generare un GUID (o inserire nel DB) e mettere questo messaggio in una coda (cioè: Bus di servizio), e quindi restituire il GUID al chiamante.

Il secondo passo : un processo di lavoro verrà eseguito nel tuo cluster in ascolto di messaggi da questa coda ed elaborerà questi messaggi ogni volta che arriva un messaggio. È ansible rendere questo servizio un singolo thread che elabora il messaggio per messaggio in un ciclo o un servizio multi-thread che elabora più messaggi utilizzando un thread per ciascun messaggio. Dipenderà da quanto complessa vuoi essere:

  • In un listener a thread singolo, per ridimensionare l’applicazione, è necessario estendersi su più istanze in modo che più attività vengano eseguite in parallelo, è ansible farlo in SF con un semplice comando di scalabilità e SF distribuirà le istanze di servizio sui nodes disponibili.

  • In una versione multi-thread devi gestire la concorrenza per prestazioni migliori, potresti dover considerare la memoria, la cpu, il disco e così via, altrimenti rischi di avere troppo carico in un singolo nodo.

Il terzo passo, la cancellazione: il processo di cancellazione è semplice e ci sono molti approcci:

  • Utilizzando un approccio simile e accodare un messaggio di cancellazione
    • Il servizio ascolterà l’annullamento in un thread separato e annullerà l’attività in esecuzione (se in esecuzione).
    • Usare una coda diversa per inviare i messaggi di cancellazione è migliore
    • Se esegui più istanze di listener, potresti prendere in considerazione un argomento anziché una coda.
  • Utilizzo di una chiave cache per memorizzare lo stato del lavoro e controllare ogni iterazione se è stata richiesta la cancellazione.
  • Tabella con lo stato del lavoro, in cui si controlla ogni iterazione come si farebbe con la chiave di cache.
  • Creazione di un endpoint remoto per effettuare una chiamata diretta al servizio e triggersre un token di cancellazione.

Ci sono molti approcci, questi sono semplici e potresti usare multipli in combinazione per avere un migliore controllo dei tuoi compiti.

Avrai bisogno di un po ‘di spazio per farlo.

Creare una tabella (ad es. JobQueue ). Prima di iniziare a elaborare il lavoro, si memorizza in un database, si memorizza lo stato (ad es. In esecuzione , potrebbe essere un enum), quindi si restituisce l’ID al chiamante. Una volta che hai bisogno di interrompere / annullare il lavoro, chiami il metodo di interruzione dall’API che invia l’ID che desideri interrompere. Nel metodo di interruzione, si aggiorna lo stato del lavoro su Aborting . All’interno del primo metodo (che esegue il lavoro), dovrai controllare questa tabella in un attimo, se si interrompe , quindi si interrompe il lavoro (e si aggiorna lo stato su Aborted ). Oppure puoi cancellare dal database una volta che il lavoro è stato interrotto o terminato.

In alternativa, se si desidera che i dati siano temporanei, è ansible utilizzare un sesto server come server cache e archiviare i dati lì. Questo server cache potrebbe anche essere un server in cluster, ma in tal caso sarà necessario utilizzare qualcosa come Redis .