I componenti di base 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 integrati in questa architettura sono i seguenti:
- Uno o più database.
- Una cache per archiviare i valori dal database per letture rapide.
- Rete CDN per rendere disponibile il contenuto statico
- Servizi remoti, tra cui i servizi di posta elettronica o SMS. Spesso queste funzionalità sono fornite da terze parti.
- Provider di identità per l'autenticazione.
Il front-end Web e il ruolo di lavoro sono entrambi senza stato. Lo stato della sessione può essere archiviato in una cache distribuita. Qualsiasi operazione a esecuzione prolungata viene eseguita in modo asincrono dal ruolo di lavoro. Il ruolo di lavoro può essere attivato da messaggi nella coda oppure può essere eseguito in base a una pianificazione per l'elaborazione batch. Il ruolo di lavoro è un componente facoltativo. In assenza di 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 singola pagina che effettua chiamate AJAX oppure da un'applicazione client nativa.
Quando usare questa architettura
L'architettura Web/coda/ruolo di lavoro viene in genere implementata usando servizi di calcolo gestiti, Servizio app di Azure o Servizi cloud di Azure.
Prendere in considerazione questo stile di architettura per:
- Applicazioni con un dominio relativamente semplice.
- Applicazioni con alcuni flussi di lavoro o operazioni batch a esecuzione prolungata.
- Quando si vuole usare servizi gestiti invece di un'infrastruttura distribuita come servizio (IaaS).
Vantaggi
- Architettura relativamente semplice e di facile comprensione.
- Semplicità di distribuzione e gestione.
- Netta separazione delle attività.
- Il front-end viene separato dal ruolo di lavoro tramite 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.
- Possono essere presenti 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 API design best practices (Procedure consigliate per la progettazione di API).
- Usare la scalabilità automatica per gestire le modifiche nel carico. Vedere Autoscaling best practices (Procedure consigliate per la scalabilità automatica).
- Memorizzare nella cache dati semi-statici. Vedere Caching best practices (Procedure consigliate per la memorizzazione nella cache).
- Usare una rete CDN per ospitare il contenuto statico. Vedere CDN best practices (Procedure consigliate per la rete CDN).
- Usare la programmazione poliglotta persistente nei casi appropriati. Vedere Usare il migliore archivio dati per il processo.
- Partizionare i dati per migliorare la scalabilità, ridurre i conflitti e ottimizzare le prestazioni. Vedere Procedure consigliate per il partizionamento dei dati.
Architettura Web/coda/ruolo di lavoro per Servizio app di Azure
Questa sezione descrive un'architettura Web/coda/ruolo di lavoro consigliata che usa Servizio app di Azure.
Scaricare un file di Visio di questa architettura.
Workflow
Il front-end viene implementato come app Web del servizio app Azure e il ruolo di lavoro viene implementato come app 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 bus di servizio di Azure o Archiviazione di Azure code per la coda di messaggi. Il diagramma mostra una coda di archiviazione di Azure.
cache di Azure per Redis archivia lo stato della sessione e altri dati che hanno bisogno di accesso a bassa latenza.
Rete CDN di Azure viene usato per memorizzare nella cache contenuto statico, ad esempio immagini, CSS o HTML.
Per l'archiviazione, scegliere le tecnologie più adatte in base alle esigenze dell'applicazione. È possibile usare più tecnologie di archiviazione (programmazione poliglotta persistente). Per illustrare questa idea, il diagramma mostra database SQL di Azure e Azure Cosmos DB.
Per altre informazioni, vedere l'architettura di riferimento dell'applicazione Web servizio app e come creare applicazioni aziendali basate su messaggi con NServiceBus e bus di servizio di Azure.
Altre considerazioni
Non tutte le transazioni devono passare dalla coda e dal ruolo di lavoro per l'archiviazione. Il front-end Web può eseguire semplici operazioni di lettura/scrittura direttamente. I ruoli di lavoro sono progettati per attività a elevato utilizzo di risorse o flussi di lavoro a esecuzione prolungata. In alcuni casi, un ruolo di lavoro può essere totalmente superfluo.
Usare la funzionalità di scalabilità automatica predefinita di Servizio app per aumentare il numero di istanze di macchina virtuale. Se il carico sull'applicazione segue modelli prevedibili, usare la scalabilità automatica basata sulla pianificazione. Se il carico è imprevedibile, usare regole di scalabilità automatica basate sulle 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 gli ambienti di produzione e test. In caso contrario, se si usa lo stesso piano per gli ambienti di produzione e test, i test verranno eseguiti nelle macchine virtuali di produzione.
Usare 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. È anche possibile tornare alla versione precedente, in caso di problemi con l'aggiornamento.