Grid microservice a più istanze: prevenzione della duplicazione dello sforzo durante la risoluzione delle risorse memorizzate nella cache

Question

Grid microservice a più istanze: prevenzione della duplicazione dello sforzo durante la risoluzione delle risorse memorizzate nella cache

#1 da (2 voti)

2

Sfondo:

Stiamo effettuando la conversione di un'applicazione Windows Service (WS) tradizionale multiservizio in una griglia di microservizi di Service Fabric di Azure in esecuzione su un livello di messaggistica del bus di servizio.

Nell'applicazione WS, il servizio "caricatore di dati" era un singleton per evitare la duplicazione degli sforzi relativi al caricamento dei dati in un DB da fonti esterne come parte di un lavoro.

Nella nuova griglia (e poiché stiamo utilizzando SQL Server 2016 con la sua funzionalità di importazione di dati bulk in parallelo), vorremmo avere più istanze del servizio "caricatore di dati" ma è ancora uno scenario standard che due o più posti di lavoro con dipendenze sullo stesso set di dati possono essere spinti sulla griglia di elaborazione contemporaneamente.

Domanda:

Esiste uno schema standard per garantire che la duplicazione degli sforzi relativi al caricamento di insiemi di dati specifici in questo tipo di architettura sia evitata?

microservices architectural-patterns messaging grid-computing

posta toadflakz 10.03.2017 - 10:43

fonte

1 risposta

Leggi altre domande sui tag microservices architectural-patterns messaging grid-computing

Convenzione di denominazione per la classe C # che accede a un servizio web Come architettura ed esporre un'API per la creazione di filtri dati personalizzati?

score 2 · Accepted Answer

Creare un oggetto di assegnazione lavoro di importazione dati centralizzato che assegni i lavori di importazione dati ad altri oggetti. I lavori possono essere eseguiti da thread all'interno dello stesso processo o da processi esterni, se in esecuzione su più computer. L'oggetto assegnatore centralizzato evita la duplicazione degli sforzi.

Riguardo al Principio di Responsabilità Unica citato nel tuo commento: questo "principio" è difficile da seguire perché la parola "responsabilità" è vaga. La definizione di "responsabilità" dovrebbe variare a seconda del livello di astrazione e del software specifico da progettare. Al più alto livello di astrazione, una "responsabilità" può comprendere una vasta gamma di compiti, mentre al livello più basso di astrazione, una "responsabilità" può essere limitata e specifica.

Al livello più basso, alcune persone considerano due righe di codice come due responsabilità separate. Avendo lavorato con il codice che riduce tutti i metodi a quasi una riga, credo che questo tipo di design sia altrettanto orribile o peggio di una gigantesca classe o metodo monolitico.