Modelli di progettazione cloud che supportano l'affidabilità
Quando si progettano architetture dei carichi di lavoro, è consigliabile usare modelli di settore che affrontano le problematiche comuni. I modelli consentono di ottenere compromessi intenzionali all'interno dei carichi di lavoro e ottimizzare per il risultato desiderato. Possono anche contribuire a mitigare i rischi che derivano da problemi specifici, che possono influire su sicurezza, prestazioni, costi e operazioni. Se non è stato risolto, questi rischi causeranno alla fine problemi di affidabilità. Questi modelli sono supportati dall'esperienza reale, sono progettati per la scalabilità del cloud e i modelli operativi e sono intrinsecamente indipendenti dai fornitori. L'uso di modelli noti come un modo per standardizzare la progettazione del carico di lavoro è un componente dell'eccellenza operativa.
Molti modelli di progettazione supportano direttamente uno o più pilastri dell'architettura. Modelli di progettazione che supportano il pilastro Affidabilità assegna priorità alla disponibilità del carico di lavoro, alla conservazione automatica, al ripristino, all'integrità dei dati e all'elaborazione e al contenimento dei malfunzionamenti.
Modelli di progettazione per l'affidabilità
La tabella seguente riepiloga i modelli di progettazione cloud che supportano gli obiettivi dell'affidabilità.
| Modello | Summary |
|---|---|
| Ambasciata | Incapsula e gestisce le comunicazioni di rete tramite l'offload di attività trasversali correlate alla comunicazione di rete. I servizi helper risultanti avviano la comunicazione per conto del client. Questo punto di aggregazione offre l'opportunità di aggiungere modelli di affidabilità alla comunicazione di rete, ad esempio tentativi o buffering. |
| Back-end per front-end | Individualizza il livello di servizio di un carico di lavoro creando servizi separati esclusivi di un'interfaccia front-end specifica. A causa di questa separazione, un malfunzionamento nel livello del servizio che supporta un client potrebbe non influire sulla disponibilità dell'accesso di un altro client. Quando si gestiscono diversi client in modo diverso, è possibile assegnare priorità alle attività di affidabilità in base ai modelli di accesso client previsti. |
| A scomparti | Introduce la segmentazione intenzionale e completa tra i componenti per isolare il raggio di esplosione di malfunzionamenti. Questa strategia di isolamento degli errori tenta di contenere errori solo alla testa in blocco che sta riscontrando il problema, impedendo l'impatto su altre teste bulk. |
| Cache-aside | Ottimizza l'accesso ai dati letti di frequente introducendo una cache popolata su richiesta. La cache viene quindi usata nelle richieste successive per gli stessi dati. La memorizzazione nella cache crea la replica dei dati e, in modi limitati, può essere usata per mantenere la disponibilità dei dati a cui si accede di frequente se l'archivio dati di origine non è temporaneamente disponibile. Inoltre, se si verifica un malfunzionamento nella cache, il carico di lavoro può eseguire il fallback all'archivio dati di origine. |
| Interruttore | Impedisce richieste continue a una dipendenza non funzionante o non disponibile. In questo modo, questo modello impedisce l'overload di una dipendenza difettosa. È anche possibile usare questo modello per attivare una riduzione normale del carico di lavoro. Gli interruttori sono spesso associati al ripristino automatico per garantire la conservazione automatica e la riparazione automatica. |
| Scontrino | Separa i dati dal flusso di messaggistica, offrendo un modo per recuperare separatamente i dati correlati a un messaggio. Gli autobus dei messaggi non forniscono la stessa affidabilità e il ripristino di emergenza che sono spesso presenti in archivi dati dedicati, quindi la separazione dei dati dal messaggio può offrire maggiore affidabilità per i dati sottostanti. Questa separazione consente anche un approccio di ripristino della coda di messaggi dopo un'emergenza. |
| Transazione di compensazione | Fornisce un meccanismo per il ripristino da errori ripristinando gli effetti delle azioni applicate in precedenza. Questo modello risolve i malfunzionamenti nei percorsi critici del carico di lavoro usando azioni di compensazione, che possono comportare processi come il rollback diretto delle modifiche dei dati, l'interruzione dei blocchi delle transazioni o anche l'esecuzione del comportamento del sistema nativo per invertire l'effetto. |
| Consumer concorrenti | Applica l'elaborazione distribuita e simultanea per gestire in modo efficiente gli elementi in una coda. Questo modello crea ridondanza nell'elaborazione delle code considerando i consumer come repliche, pertanto un errore dell'istanza non impedisce ad altri consumer di elaborare i messaggi della coda. |
| Origine eventi | Considera la modifica dello stato come serie di eventi, acquisendoli in un log non modificabile e di sola accodamento. È possibile usare questo modello quando una cronologia affidabile delle modifiche è fondamentale in un processo aziendale complesso. Facilita anche la ricostruzione dello stato se è necessario ripristinare gli archivi di stato. |
| Identità federativa | Delega l'attendibilità a un provider di identità esterno al carico di lavoro per la gestione degli utenti e la fornitura dell'autenticazione per l'applicazione. L'offload della gestione degli utenti e dell'autenticazione sposta l'affidabilità per tali componenti al provider di identità, che in genere ha un contratto di servizio elevato. Inoltre, durante il ripristino di emergenza del carico di lavoro, i componenti di autenticazione probabilmente non devono essere risolti come parte del piano di ripristino del carico di lavoro. |
| Aggregazione gateway | Semplifica le interazioni client con il carico di lavoro aggregando le chiamate a più servizi back-end in una singola richiesta. Questa topologia consente di spostare la gestione degli errori temporanei da un'implementazione distribuita tra i client a un'implementazione centralizzata. |
| Offload del gateway | Offload dell'elaborazione delle richieste a un dispositivo gateway prima e dopo l'inoltro della richiesta a un nodo back-end. L'offload di questa responsabilità in un gateway riduce la complessità del codice dell'applicazione nei nodi back-end. In alcuni casi, l'offload sostituisce completamente la funzionalità con una funzionalità fornita dalla piattaforma affidabile. |
| Routing del gateway | Instrada le richieste di rete in ingresso a vari sistemi back-end in base alle finalità delle richieste, alla logica di business e alla disponibilità back-end. Il routing del gateway consente di instradare il traffico solo a nodi integri nel sistema. |
| Geode | Distribuisce i sistemi che operano in modalità di disponibilità attiva-attiva in più aree geografiche. Questo modello usa la replica dei dati per supportare l'ideale per la connessione di qualsiasi client a qualsiasi istanza geografica. Può aiutare il carico di lavoro a resistere a una o più interruzioni a livello di area. |
| Monitoraggio endpoint di integrità | Consente di monitorare l'integrità o lo stato di un sistema esponendo un endpoint appositamente progettato per tale scopo. È possibile usare questo endpoint per gestire l'integrità del carico di lavoro e per avvisi e dashboard. È anche possibile usarlo come segnale per la correzione automatica. |
| Tabella degli indici | Ottimizza il recupero dei dati negli archivi dati distribuiti consentendo ai client di cercare metadati in modo che i dati possano essere recuperati direttamente, evitando la necessità di eseguire analisi complete dell'archivio dati. Poiché i client puntano alla partizione, alla partizione o all'endpoint tramite un processo di ricerca, è possibile usare questo modello per facilitare un approccio di failover per l'accesso ai dati. |
| Designazione leader | Stabilisce un leader di istanze di un'applicazione distribuita. Il leader coordina le responsabilità correlate al raggiungimento di un obiettivo. Questo modello riduce l'effetto dei malfunzionamenti del nodo reindirizzando in modo affidabile il lavoro. Implementa anche il failover tramite algoritmi di consenso quando un leader non funziona correttamente. |
| Pipe e filtri | Suddivide l'elaborazione dati complessa in una serie di fasi indipendenti per ottenere un risultato specifico. La singola responsabilità di ogni fase consente di concentrare l'attenzione ed evita la distrazione dell'elaborazione dei dati con comming. |
| Coda di priorità | Assicura che gli elementi con priorità più alta vengano elaborati e completati prima degli elementi con priorità più bassa. La separazione degli elementi in base alla priorità aziendale consente di concentrare le attività di affidabilità sul lavoro più critico. |
| Autore/Sottoscrittore | Separa i componenti di un'architettura sostituendo la comunicazione diretta da client a servizio o da client a servizi con la comunicazione tramite un broker di messaggi intermedio o un bus di eventi. |
| Livellamento del carico basato sulle code | Controlla il livello di richieste o attività in ingresso memorizzandole nel buffer in una coda e consentendo al processore della coda di gestirle a un ritmo controllato. Questo approccio può offrire resilienza contro picchi improvvisi della domanda separando l'arrivo delle attività dall'elaborazione. Può anche isolare i malfunzionamenti nell'elaborazione della coda in modo che non influiscano sull'assunzione. |
| Limitazione della frequenza | Controlla la frequenza delle richieste client per ridurre gli errori di limitazione ed evitare scenari di ripetizione dei tentativi non associati in caso di errore. Questa tattica protegge il client riconoscendo le limitazioni e i costi di comunicazione con un servizio quando il servizio è progettato per evitare di raggiungere i limiti specificati. Funziona controllando il numero e/o le dimensioni delle operazioni inviate al servizio durante un periodo di tempo specifico. |
| Nuovo tentativo | Risolve gli errori che potrebbero essere temporanei o intermittenti ritentando determinate operazioni, in modo controllato. La mitigazione degli errori temporanei in un sistema distribuito è una tecnica chiave per migliorare la resilienza di un carico di lavoro. |
| Transazioni distribuite Saga | Coordina transazioni a esecuzione prolungata e potenzialmente complesse scomponendo il lavoro in sequenze di transazioni più piccole e indipendenti. Ogni transazione deve inoltre avere azioni di compensazione per invertire gli errori nell'esecuzione e mantenere l'integrità. Poiché le transazioni monolitiche in più sistemi distribuiti sono in genere impossibili, questo modello fornisce coerenza e affidabilità implementando atomicità e compensazione. |
| Supervisione agente di pianificazione | Distribuisce e ridistribuisce in modo efficiente le attività in un sistema in base a fattori osservabili nel sistema. Questo modello usa le metriche di integrità per rilevare gli errori e reindirizzare le attività a un agente integro per attenuare gli effetti di un malfunzionamento. |
| Serie di istruzioni sequenziali | Gestisce l'ingresso della messaggistica simultanea, supportando anche l'elaborazione in un ordine definito. Questo modello può eliminare le race condition difficili da risolvere, la gestione dei messaggi conflitto o altre soluzioni alternative per l'indirizzamento non corretto dei messaggi ordinati che possono causare malfunzionamenti. |
| Partizionamento orizzontale | Indirizza il carico a una destinazione logica specifica per gestire la richiesta specifica, abilitando la corilevazione per l'ottimizzazione. Poiché i dati o l'elaborazione sono isolati nella partizione, un malfunzionamento in una partizione rimane isolato per tale partizione. |
| Strangler Fig | Fornisce un approccio per sostituire sistematicamente i componenti di un sistema in esecuzione con nuovi componenti, spesso durante una migrazione o modernizzazione del sistema. Questo approccio incrementale di questo modello può aiutare a ridurre i rischi durante una transizione. |
| Limitazione | Impone limiti alla velocità effettiva o alla velocità effettiva delle richieste in ingresso a una risorsa o a un componente. È possibile progettare i limiti per evitare l'esaurimento delle risorse che potrebbero causare malfunzionamenti. È anche possibile usare questo modello come meccanismo di controllo in un piano di riduzione delle prestazioni normale. |
Passaggi successivi
Esaminare i modelli di progettazione cloud che supportano gli altri pilastri di Azure Well-Architected Framework: