Condividi tramite

Stile dell'architettura Web-Queue-Worker

I componenti principali di questa architettura sono un front-end Web che gestisce le richieste client e un ruolo di lavoro che esegue attività a elevato utilizzo di risorse, flussi di lavoro a esecuzione prolungata o processi batch. Il web front-end comunica con il worker tramite una coda di messaggi.

Diagramma logico che mostra l'architettura web-Queue-Worker.

I componenti seguenti sono comunemente incorporati in questa architettura:

  • Uno o più database

  • Cache in cui archiviare i valori del database per letture rapide

  • Una rete per la distribuzione di contenuti per la gestione di contenuti statici

  • Servizi remoti, ad esempio posta elettronica o SMS (Short Message Service), che in genere forniscono provider di servizi non Microsoft

  • Fornitore di servizi di identità per l'autenticazione

Web e worker sono entrambi senza stato e lo stato della sessione può essere archiviato in una cache distribuita. Il lavoratore gestisce il lavoro a esecuzione prolungata in modo asincrono. I messaggi nella coda possono avviare il worker oppure una pianificazione può eseguirlo per l'elaborazione batch. Il compito del lavoratore è facoltativo se l'applicazione non dispone di operazioni a esecuzione prolungata.

Il front-end potrebbe includere un'API Web. Un'applicazione a pagina singola può utilizzare l'API Web effettuando chiamate AJAX o un'applicazione client nativa può utilizzarla direttamente.

Quando usare questa architettura

L'architettura Web-Queue-Worker viene in genere implementata usando servizi di calcolo gestiti come il servizio app di Azure o il servizio Azure Kubernetes.

Si consideri questa architettura per i casi d'uso seguenti:

  • Applicazioni con un dominio relativamente semplice

  • Applicazioni con flussi di lavoro a esecuzione prolungata o operazioni batch

  • Scenari in cui si preferisce i servizi gestiti rispetto all'infrastruttura distribuita come servizio (IaaS)

Vantaggi

  • Un'architettura semplice e semplice da seguire

  • Distribuzione e gestione con un minimo sforzo

  • Separazione chiara delle responsabilità

  • Disaccoppiamento del front-end e del lavoratore tramite la messaggistica asincrona

  • Scalabilità indipendente del front-end e del ruolo di lavoro

Sfide

  • Senza un'attenta progettazione, il front-end e il worker possono diventare componenti monolitici di grandi dimensioni, difficili da gestire e aggiornare.

  • Se il front-end e il ruolo di lavoro condividono schemi di dati o moduli di codice, potrebbero esserci dipendenze nascoste.

  • Il front-end web può fallire dopo essere stato persistito nel database ma prima di inviare messaggi alla coda, causando problemi di coerenza perché il worker non svolge la propria parte della logica. Per attenuare questo problema, è possibile utilizzare tecniche come il modello Outbox transazionale, che richiedono il reinoltro dei messaggi in uscita affinché ritornino tramite una coda separata. La libreria di sessioni transazionali NServiceBus supporta questa tecnica.

Procedure consigliate

Web-Queue-Worker nel servizio app

Questa sezione descrive un'architettura Web-Queue-Worker consigliata che utilizza App Service.

Diagramma che mostra l'architettura Web-Queue-Worker.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

  • Il front-end viene implementato come app Web di App Service e il worker viene implementato come app di Azure Functions. L'app Web e l'app delle Funzioni sono entrambe associate a un piano di servizio app che fornisce le istanze di macchine virtuali (VM).

  • È possibile usare il bus di servizio di Azure o le code di Archiviazione di Azure per la coda dei messaggi. Il diagramma precedente usa una coda di archiviazione.

  • Azure Managed Redis archivia lo stato della sessione e altri dati che richiedono l'accesso a bassa latenza.

  • La rete per la distribuzione di contenuti di Azure viene usata per memorizzare nella cache contenuto statico come immagini, CSS o HTML.

  • Per l'archiviazione, scegliere le tecnologie più adatte alle esigenze dell'applicazione. Questo approccio, noto come persistenza poliglotta, usa più tecnologie di archiviazione nello stesso sistema per soddisfare requisiti diversi. Per illustrare questa idea, il diagramma mostra sia il database SQL di Azure che Azure Cosmos DB.

Per ulteriori informazioni, vedere Baseline applicazione web ad alta disponibilità con ridondanza delle zone e Costruzione di applicazioni aziendali basate su messaggi con NServiceBus e Service Bus.

Altre considerazioni

  • Non tutte le transazioni devono passare attraverso la coda e il processo di lavoro per la memorizzazione. Il front-end Web può eseguire operazioni di lettura e scrittura semplici direttamente. I lavoratori sono progettati per attività che richiedono molte risorse o flussi di lavoro di lunga durata. In alcuni casi, potresti non aver bisogno di un lavoratore.

  • Usare la funzionalità di scalabilità automatica predefinita della piattaforma di calcolo per aumentare il numero di istanze. Se il carico nell'applicazione segue modelli prevedibili, usare la scalabilità automatica basata su pianificazione. Se il carico è imprevedibile, usare la scalabilità automatica basata su metriche.

  • Prendere in considerazione l'inserimento dell'app Web e dell'app Funzioni in piani di servizio App Service separati per consentire loro di scalare in modo indipendente.

  • Usare piani di servizio app separati per la produzione e i test.

  • Usare gli slot di implementazione per gestire le implementazioni. Questo metodo consente di distribuire una versione aggiornata in uno slot di staging e quindi di passare alla nuova versione. Consente anche di tornare alla versione precedente se si verifica un problema durante l'aggiornamento.

  • Last updated on