Progettazione per la resilienza
 Il carico di lavoro deve continuare a funzionare con funzionalità complete o ridotte. |
|---|
È consigliabile prevedere malfunzionamenti dei componenti, interruzioni della piattaforma, riduzione delle prestazioni e altri errori. Creare resilienza nel sistema in modo che sia a tolleranza di errore e possa degradarsi normalmente.
Scenario di esempio
Contoso Air è una compagnia aerea commerciale con un reparto di sviluppo interno. L'applicazione LOB principale è una soluzione di prenotazione che consente ai clienti di prenotare i voli direttamente con Contoso Air. L'app è incorporata in Azure e usa app Azure Service, Cosmos DB, Funzioni di Azure, App per la logica di Azure e bus di servizio di Azure.
Determinare i rischi di errore.
Identificare i potenziali punti di errore nel sistema, in particolare per i componenti critici, e determinare l'effetto sui flussi utente e di sistema.
Analizzare il caso di errore, il raggio di esplosione e l'intensità dell'errore per ogni potenziale punto di guasto. I casi di errore e la loro intensità possono variare da scenari a impatto relativamente basso, ad esempio la perdita temporanea di un processo back-end a interruzioni complete a scalabilità completa risultanti da emergenze. L'esecuzione di questa analisi consente di determinare la progettazione delle funzionalità di gestione degli errori a livello di componente.
Sfida di Contoso
- L'applicazione LOB offre molte funzioni chiave che vanno dal marketing al commercio. Il flusso utente di acquisto del ticket è stato identificato come il flusso più critico. Il team del carico di lavoro ha stabilito che devono essere implementate più misure di affidabilità per garantire che il flusso sia ottimizzato per la resilienza.
- Il team ha pianificato il tempo per miglioramenti come la separazione dei componenti e la riprogettazione dei flussi, ma vuole assicurarsi che usino tale tempo per concentrarsi sui miglioramenti più elevati del valore.
Applicazione dell'approccio e dei risultati
- Il team identifica il gateway di pagamento esterno come punto di errore potenziale. Il gateway è a disponibilità elevata, ma è possibile che gli utenti riscontrano errori temporanei occasionali causati da problemi di rete o picchi di richieste estremamente elevate. Il gateway può rifiutare alcune richieste quando viene sottoposto a overload da più richieste simultanee inviate.
- Il team determina che gli utenti devono inviare di nuovo le richieste quando le richieste iniziali vengono rifiutate dal gateway, causando un'esperienza utente negativa.
Implementare meccanismi di auto-conservazione
Creare funzionalità di auto-conservazione usando modelli di progettazione correttamente e modularizzando la progettazione per isolare gli errori.
Creando funzionalità di auto-conservazione nel sistema, sarà possibile evitare che un problema influisca sui componenti downstream. Il sistema sarà in grado di attenuare errori temporanei e permanenti, colli di bottiglia delle prestazioni e altri problemi che potrebbero influire sull'affidabilità. Potrai anche ridurre al minimo il raggio dell'esplosione.
Sfida di Contoso
- Il team vuole ridurre al minimo il rischio di errori temporanei che causano il rifiuto delle richieste degli utenti da parte del gateway di pagamento. A causa della natura temporanea di alcune delle condizioni di errore, è probabile che la stessa richiesta abbia esito positivo se viene inviato di nuovo.
Applicazione dell'approccio e dei risultati
- Il team sviluppa logica personalizzata nel flusso per ritentare la transazione dopo un breve ritardo quando viene rilevato un errore che può essere ripetuto.
- La progettazione della soluzione verrà modificata per incorporare il modello di ripetizione dei tentativi, aumentando leggermente il tempo di attesa tra i tentativi fino a quando la richiesta non viene elaborata correttamente o viene raggiunto il numero massimo di errori.
- Il team decide inoltre di separare le funzionalità di interazione dell'utente e di elaborazione dei pagamenti back-end di questo flusso usando un approccio basato su eventi con bus di servizio di Azure. Quando si verificano errori irreversibili durante l'elaborazione del messaggio (dopo il numero massimo di tentativi), il processore back-end abbandona l'elaborazione della richiesta, lasciando il messaggio nella coda in modo che possa essere rielaborato in un secondo momento.
Creare ridondanza e resilienza complete
Creare ridondanza in livelli e resilienza in vari livelli di applicazione.
Obiettivo della ridondanza nelle utilità fisiche e nella replica immediata dei dati. Mirare anche alla ridondanza nel livello funzionale che copre servizi, operazioni e personale. La ridondanza consente di ridurre al minimo i singoli punti di errore. Ad esempio, se si verifica un'interruzione che interessa uno o più componenti, una zona di disponibilità o un'intera area, una distribuzione ridondante (attiva-attiva o attiva-passiva) consente di soddisfare le destinazioni di tempo di attività.
L'aggiunta di intermediari impedisce la dipendenza diretta tra i componenti e migliora il buffering. Entrambi questi vantaggi rafforzano la resilienza del sistema.
Sfida di Contoso
- L'implementazione di tentativi e disaccoppiamento delle chiamate al gateway di pagamento dall'interfaccia utente tramite bus di servizio ha aumentato notevolmente l'affidabilità di questo flusso, ma gli stakeholder aziendali continuano a preoccuparsi della perdita di dati che può verificarsi a causa di un errore irreversibile nell'area primaria.
Applicazione dell'approccio e dei risultati
- Il team decide di eseguire l'aggiornamento a bus di servizio livello Premium. In questo modo, possono sfruttare le funzionalità di supporto zone di disponibilità di tale livello. Con questa funzionalità, più copie dei dati vengono archiviate in tre strutture separate fisicamente (zone di disponibilità) e il servizio dispone di riserve di capacità sufficienti per gestire immediatamente la perdita irreversibile completa di un data center.
- Il team configura inoltre bus di servizio di Azure ripristino di emergenza geografico per replicare continuamente i dati in un'area secondaria che verrà usata nel caso improbabile di un errore completo dell'area primaria.