Stile dell'architetturaQueue-Worker Web
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 front-end Web comunica con il ruolo di lavoro tramite una coda di messaggi.
Altri componenti comunemente incorporati in questa architettura includono:
- Uno o più database.
- Cache in cui archiviare i valori del database per letture rapide.
- Rete CDN per la gestione del contenuto statico
- Servizi remoti, ad esempio posta elettronica o servizio SMS. Spesso queste funzionalità sono fornite da terze parti.
- Provider di identità per l'autenticazione.
Il Web e il ruolo di lavoro sono entrambi senza stato. Lo stato della sessione può essere archiviato in una cache distribuita. Qualsiasi lavoro a esecuzione prolungata viene eseguito in modo asincrono dal ruolo di lavoro. Il ruolo di lavoro può essere attivato dai messaggi nella coda oppure può essere eseguito in base a una pianificazione per l'elaborazione batch. Il ruolo di lavoro è un componente facoltativo. Se non sono presenti operazioni a esecuzione prolungata, il ruolo di lavoro può essere omesso.
Il front-end può essere costituito da un'API Web. Sul lato client, l'API Web può essere utilizzata da un'applicazione a pagina singola che effettua chiamate AJAX o da un'applicazione client nativa.
Quando usare questa architettura
L'architettura Web-Queue-Worker viene in genere implementata usando servizi di calcolo gestiti, servizio app di Azure o Servizi cloud di Azure.
Si consideri questo stile di architettura per:
- Applicazioni con un dominio relativamente semplice.
- Applicazioni con alcuni flussi di lavoro a esecuzione prolungata o operazioni batch.
- Quando si vogliono usare i servizi gestiti, anziché l'infrastruttura distribuita come servizio (IaaS).
Vantaggi
- Architettura relativamente semplice che è facile da comprendere.
- Semplicità di distribuzione e gestione.
- Chiara separazione delle preoccupazioni.
- Il front-end è separato dal ruolo di lavoro usando la messaggistica asincrona.
- Il front-end e il ruolo di lavoro possono essere ridimensionati in modo indipendente.
Sfide
- Senza un'attenta progettazione, il front-end e il ruolo di lavoro possono diventare componenti monolitici di grandi dimensioni difficili da gestire e aggiornare.
- Potrebbero esserci dipendenze nascoste, se il front-end e il ruolo di lavoro condividono schemi di dati o moduli di codice.
- Il front-end Web può non funzionare correttamente dopo la persistenza nel database, ma prima di generare i messaggi nella coda. Ciò può causare possibili problemi di coerenza perché il ruolo di lavoro non eseguirà la sua parte della logica. Le tecniche come il modello outbox transazionale possono essere usate per attenuare questo problema, ma richiedono la modifica del routing dei messaggi in uscita al primo "loopback" attraverso una coda separata. Una libreria che fornisce supporto per questa tecnica è la sessione transazionale NServiceBus.
Procedure consigliate
- Esporre un'API ben progettata al client. Vedere Procedure consigliate per la progettazione delle API.
- Scalabilità automatica per gestire le modifiche nel carico. Vedere Procedure consigliate per la scalabilità automatica.
- Memorizzare nella cache dati semi-statici. Vedere Procedure consigliate per la memorizzazione nella cache.
- Usare una rete CDN per ospitare contenuto statico. Vedere Procedure consigliate per la rete CDN.
- Usare la persistenza poliglotta quando appropriato. Vedere [Usare l'archivio dati migliore per il processo][poliglotta].
- Partizionare i dati per migliorare la scalabilità, ridurre i conflitti e ottimizzare le prestazioni. Vedere Procedure consigliate per il partizionamento dei dati.
Web-Queue-Worker nel servizio app di Azure
Questa sezione descrive un'architettura web-Queue-Worker consigliata che usa il servizio app di Azure.
Scaricare un file di Visio di questa architettura.
Flusso di lavoro
Il front-end viene implementato come app Web del servizio app di Azure e il ruolo di lavoro viene implementato come app di Funzioni di Azure . L'app Web e l'app per le funzioni sono entrambi associati a un piano di servizio app che fornisce le istanze della macchina virtuale.
È possibile usare il bus di servizio di Azure o le code di Archiviazione di Azure per la coda dei messaggi. Il diagramma mostra una coda di Archiviazione di Azure.
Cache Redis di Azure archivia lo stato della sessione e altri dati che hanno bisogno di accesso a bassa latenza.
La rete CDN di Azure viene usata per memorizzare nella cache contenuto statico, ad esempio immagini, CSS o HTML.
Per l'archiviazione, scegliere le tecnologie di archiviazione più adatte alle esigenze dell'applicazione. È possibile usare più tecnologie di archiviazione (persistenza poliglotta). Per illustrare questa idea, il diagramma mostra il database SQL di Azure e Azure Cosmos DB.
Per altre informazioni, vedere l'architettura di riferimento dell'applicazione Web del servizio app e come creare applicazioni aziendali basate su messaggi con NServiceBus e il bus di servizio di Azure.
Altre considerazioni
Non ogni transazione deve passare attraverso la coda e il ruolo di lavoro per l'archiviazione. Il front-end Web può eseguire operazioni di lettura/scrittura semplici direttamente. I ruoli di lavoro sono progettati per attività a elevato utilizzo di risorse o flussi di lavoro a esecuzione prolungata. In alcuni casi, potrebbe non essere necessario un ruolo di lavoro.
Usare la funzionalità di scalabilità automatica predefinita del servizio app per aumentare il numero di istanze di macchine virtuali. Se il carico nell'applicazione segue modelli prevedibili, usare la scalabilità automatica basata su pianificazione. Se il carico è imprevedibile, usare regole di scalabilità automatica basate su metriche.
Valutare la possibilità di inserire l'app Web e l'app per le funzioni in piani di servizio app separati. In questo modo, possono essere ridimensionati in modo indipendente.
Usare piani di servizio app separati per la produzione e i test. In caso contrario, se si usa lo stesso piano per la produzione e il test, significa che i test vengono eseguiti nelle macchine virtuali di produzione.
Usare gli slot di distribuzione per gestire le distribuzioni. 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 è verificato un problema con l'aggiornamento.