Pattern corretto per i processi di lavoro che coinvolgono code e tabelle

Naviga le tue risposte
1

Modifica:

OK, quindi, la gente ha detto che non è chiaro cosa sto chiedendo. Sto chiedendo un feedback su questo design. Ecco un esempio di storia utente:

In qualità di amministratore di gruppo sul sito Web, desidero ricevere una notifica quando un utente del mio gruppo carica un file nel gruppo.

La soluzione più semplice è che nel codice che gestisce il caricamento, creiamo direttamente un messaggio e-mail e lo spediamo. Tuttavia, questo sembra che non sia proprio il livello appropriato di separazione delle preoccupazioni, quindi invece stiamo pensando di avere un processo di lavoro separato che non fa altro che inviare notifiche. Pertanto, il sito Web nel codice di caricamento gestisce la ricezione del file, estraendo alcuni metadati da esso (come il nome file) e scrivendolo nel database. Non appena viene gestito il caricamento del file, vengono eseguiti due passaggi: Scrive i dettagli della notifica da inviare (come oggetto, nome file, ecc.) A una tabella di "notifica" dedicata e crea anche un messaggio in una coda che la notifica invia ai monitor dei processi di lavoro. L'intera sequenza è mostrata nello schema seguente.

Le mie domande sono: vedi qualche inconveniente in questo design? C'è un design migliore? Il team desidera utilizzare ruoli di Azure Worker, code e tabelle. È la chiamata giusta per usare questi componenti o questo disegno è inutilmente complesso? I requisiti degli attributi di qualità sono che è facile da codificare, facile da mantenere, facile da eseguire il debug in fase di esecuzione, controllabile (la cronologia è disponibile quando sono state inviate le notifiche, ecc.), Monitorabile. Qualunque altro attributo di qualità che pensi che dovremmo progettare?

originale:

Stiamo creando un'applicazione cloud (in Azure) in cui sono presenti almeno 2 componenti. Il primo è il componente "source" (ad esempio un'interfaccia utente / sito Web) in cui si verifica un'azione o viene soddisfatta una condizione che attiva un secondo componente o "worker" per eseguire un determinato lavoro. Questi lavori hanno dettagli o metadati ad essi associati che intendiamo archiviare in Archiviazione tabelle di Azure. Ecco lo schema che stiamo considerando:

Passi:

  1. Condizioneperillavororaggiunto.
  2. L'originescriveidettaglidellavoronellatabella.
  3. L'originemetteillavoroincoda.

inmodoasincrono:

  • Il lavoratore accetta il lavoro dalla coda.
  • Record di lavoro DateTimeStarted nella tabella.
  • La coda segna il lavoro contrassegnato come "in corso".
  • Il lavoratore svolge un lavoro.
  • Tabella degli aggiornamenti dei lavoratori con dettagli (incluso DateTimeCompleted).
  • Il lavoratore segnala il completamento alla coda.
  • Lavoro cancellato dalla coda.

    • Si prega di commentare e fammi sapere se ho questo diritto, o se c'è qualche schema migliore. Ad esempio, considera il lavoro come "invio di una notifica", ad esempio un'e-mail i cui campi modello sono riempiti dai "dettagli" menzionati nel modello.

        
    posta Infin8Loop 16.05.2014 - 23:53
    fonte

    1 risposta

    1

    Non posso rispondere se devi farlo o no, ma posso provare ad aiutarti con il tuo processo decisionale.

    In primo luogo, ciò che stai proponendo è un meccanismo molto standard per l'elaborazione asincrona dei dati. Quindi stai facendo qualcosa di molto convenzionale, e questo è buono. Io uso AWS e ho fatto molto con SQS e SNS. Non posso parlare di ciò che offre Azure. AWS fornisce un esempio di questo modello per l'elaborazione in batch.

    Ecco alcuni vantaggi di questo approccio:

    • La richiesta iniziale può essere più veloce perché c'è meno lavoro da fare. C'è un po 'di tempo per mettere il messaggio in coda, ma è probabilmente più veloce del salvataggio su disco e dell'invio di un'email.

    • È possibile rendere le notifiche più tolleranti ai guasti o, almeno, non interferire con la richiesta iniziale che ha richiesto tale notifica. Se il tuo servizio di posta elettronica si interrompe per un giorno, puoi mantenere il messaggio in coda e l'operatore può riprovare il giorno successivo.

    • Si scalerà bene, sia in termini di utenti, sia in base alle nuove funzionalità.

    Ci sono alcuni aspetti negativi:

    • C'è ora una complessità aggiuntiva. Sarebbe più semplice inviare l'e-mail.

    • Gestire correttamente gli errori può essere più complicato. Cosa fai se non puoi inviare una e-mail? Riprovare? Cancellare il messaggio dalla coda e dimenticare? Questa gestione degli errori è importante, ma il tuo caso d'uso decide quanto sofisticato è necessario.

    • Probabilmente vorrai un altro servizio web che gestisca questo, che aggiunge un altro componente. Tuttavia, su progetti su piccola scala, ho inserito il thread di lavoro nello stesso servizio web.

    Separazione delle preoccupazioni

    Hai menzionato Separation of Concerns come una delle ragioni della tua progettazione. Indipendentemente dal modo in cui finisci con l'architettare questo, dovresti comunque separare le preoccupazioni a livello di classe. Qualunque classe stia ricevendo questi dati può chiamare un'interfaccia "notifier". Potresti avere diverse implementazioni nel tempo: inviare l'e-mail nella stessa discussione, inviare l'e-mail in una discussione diversa senza una coda, mettere l'e-mail in una coda. Ogni volta che cambi la tua architettura, tieni il codice di manutenzione lo stesso.

        
    risposta data 23.05.2014 - 22:21
    fonte

    Leggi altre domande sui tag

    Nascondi il menu di amministrazione se non è disponibile l'opzione di amministrazione Uso pratico dell'ereditarietà generica e interazioni con i non generici?