Modelli di progettazione cloud
Gli architetti progettano carichi di lavoro combinando servizi della piattaforma, funzionalità e codice per soddisfare i requisiti funzionali e non funzionali nei carichi di lavoro. La progettazione dei carichi di lavoro richiede la comprensione dei requisiti del carico di lavoro e quindi la scelta di topologie e approcci alla soluzione delle sfide presentate dai vincoli del carico di lavoro. Modelli di progettazione cloud che affrontano molte sfide comuni.
La progettazione dei sistemi è fortemente immersa nei pattern di progettazione. L'infrastruttura, il codice e i sistemi distribuiti sono tutti progettati intorno a una combinazione di modelli di progettazione. Questi modelli di progettazione sono utili per creare applicazioni affidabili, sicure, ottimizzate per i costi, operative solide e ad alte prestazioni nel cloud.
Questi modelli di progettazione non sono specifici di alcuna tecnologia e sono rilevanti per qualsiasi sistema distribuito, sia ospitato in Azure, in altre piattaforme cloud e alcuni possono anche estendersi a carichi di lavoro locali o ibridi.
I modelli di progettazione cloud consentono il processo di progettazione
I carichi di lavoro cloud sono soggetti alle fallacies del calcolo distribuito. Ecco alcuni esempi di fallacies di progettazione cloud:
- La rete è affidabile
- La latenza è zero
- La larghezza di banda è infinita
- La rete è sicura
- La topologia non cambia
- C'è un amministratore
- Il controllo delle versioni dei componenti è semplice
- L'implementazione dell'osservabilità può essere ritardata
I modelli di progettazione non eliminano nozioni come queste, ma possono contribuire a rendere consapevoli, compensazioni e mitigazioni di essi. Ogni modello di cloud ha i propri compromessi. È necessario prestare maggiore attenzione al motivo per cui si sceglie un determinato modello rispetto a come implementarlo.
Un carico di lavoro ben progettato considera il modo in cui questi modelli di progettazione a livello di settore devono essere usati come blocchi predefiniti di base per la progettazione del carico di lavoro. Ogni pilastro di Azure Well-Architected è rappresentato in questi modelli di progettazione, che spesso introducono compromessi tra gli obiettivi degli altri pilastri.
Catalogo dei modelli
Ogni modello in questo catalogo descrive il problema che il modello risolve, le considerazioni per l'applicazione del modello e un esempio basato su Microsoft Azure. Alcuni modelli includono esempi di codice o frammenti di codice che illustrano come implementare il modello in Azure.
| Modello | Riepilogo | Concetti fondamentali di Azure Well-Architected Framework |
|---|---|---|
| Ambasciata | Creare servizi helper che inviano richieste di rete per conto di un servizio consumer o di un'applicazione. |
|
| Livello antidanneggiamento | Implementare un'interfaccia o un livello adapter tra un'applicazione moderna e un sistema legacy. |
|
| Richiesta e risposta asincrone | Separare l'elaborazione back-end da un host front-end, in cui l'elaborazione back-end deve essere asincrona, ma il front-end necessita ancora di una risposta chiara. |
|
| Back-end per front-end | Creare servizi back-end separati da usare da specifiche applicazioni front-end o interfacce. |
|
| A scomparti | Isolare gli elementi di un'applicazione in pool in modo che, in caso di errore, gli altri continuino a funzionare. |
|
| Cache-aside | Caricare i dati su richiesta in una cache da un archivio dati. |
|
| Coreografia | Consentire a ogni servizio di decidere quando e come viene elaborata un'operazione aziendale, invece di dipendere da un agente di orchestrazione centrale. |
|
| Interruttore | Gestire gli errori la cui correzione potrebbe richiedere una quantità variabile di tempo in fase di connessione a una risorsa o a un servizio remoto. |
|
| Scontrino | Dividere un messaggio di grandi dimensioni in uno scontrino e un payload per evitare di sovraccaricare il bus dei messaggi. |
|
| Transazione di compensazione | Annullare il lavoro eseguito da una serie di passaggi che insieme definiscono un'operazione coerente. |
|
| Consumer concorrenti | Consentire a più consumer concorrenti di elaborare i messaggi ricevuti sullo stesso canale di messaggistica. |
|
| Consolidamento delle risorse di calcolo | Consolidare più attività o operazioni in una singola unità di calcolo. |
|
| CQRS | Consente di segregare le operazioni di lettura dei dati dalle operazioni di aggiornamento dei dati attraverso l'utilizzo di interfacce separate. |
|
| Stamp di distribuzione | Distribuire più copie indipendenti dei componenti dell'applicazione, inclusi gli archivi dati. |
|
| Configurazione del carico di lavoro Edge | Centralizzare la configurazione per affrontare la sfida di configurare più sistemi e dispositivi nel negozio. | |
| Origine eventi | Usare un archivio di solo accodamento per registrare la serie completa di eventi che descrivono le azioni eseguite sui dati di un dominio. |
|
| Archivio di configurazione esterno | È possibile estrarre le informazioni di configurazione dal pacchetto di distribuzione dell'applicazione e spostarle in una posizione centralizzata. |
|
| Identità federativa | È possibile delegare l'autenticazione a un provider di identità esterno. |
|
| Gatekeeper | Proteggere le applicazioni e i servizi usando un'istanza host dedicata che funga da broker tra i client e l'applicazione o il servizio, convalidi e purifichi le richieste e passi le richieste e i dati tra di essi. |
|
| Aggregazione gateway | Usare un gateway per aggregare più richieste singole in un'unica richiesta. |
|
| Offload del gateway | Eseguire l'offload delle funzionalità dei servizi condivise o specializzate in un proxy gateway. |
|
| Routing del gateway | Eseguire il routing delle richieste a più servizi, usando un singolo endpoint. |
|
| Geode | Distribuire i servizi back-end in un set di nodi geografici, ognuno dei quali può rispondere a qualsiasi richiesta client in qualsiasi area. |
|
| Monitoraggio endpoint di integrità | Implementare controlli funzionali all'interno di un'applicazione a cui gli strumenti esterni possono accedere tramite endpoint esposti a intervalli regolari. |
|
| Tabella degli indici | Creare indici sui campi negli archivi dati spesso referenziati dalle query. |
|
| Designazione leader | Coordinare le azioni eseguite da una raccolta di istanze di attività di collaborazione in un'applicazione distribuita designando un'istanza come leader, con la responsabilità di gestire le altre istanze. |
|
| Vista materializzata | Generare viste prepopolate sui dati in uno o più archivi dati quando i dati non sono formattati in modo ideale per le operazioni di query necessarie. |
|
| Bridge di Messaggistica | Creare un intermediario per abilitare la comunicazione tra sistemi di messaggistica altrimenti incompatibili a causa del protocollo o del formato. |
|
| Pipe e filtri | Scomporre un'attività che esegue un'elaborazione complessa in una serie di elementi distinti riutilizzabili. |
|
| Coda di priorità | Assegnare una priorità alle richieste inviate ai servizi in modo che le richieste con una priorità più alta vengano ricevute ed elaborate più rapidamente rispetto a quelle con priorità più bassa. |
|
| Autore/Sottoscrittore | Abilitare un'applicazione all'annuncio di eventi a più consumer interessati in modalità asincrona, senza accoppiamento di mittenti e destinatari. |
|
| Quarantena | Assicurarsi che gli asset esterni soddisfino un livello di qualità concordato dal team prima di essere autorizzati a utilizzarli nel carico di lavoro. |
|
| Livellamento del carico basato sulle code | Usare una coda che funge da buffer tra un'attività e un servizio richiamato per alleggerire i carichi di lavoro elevati intermittenti. |
|
| Modello di limite di frequenza | Il modello di limitazione consente di evitare o ridurre al minimo gli errori di limitazione correlati a questi limiti di limitazione e di prevedere in modo più accurato la velocità effettiva. |
|
| Riprova | È possibile abilitare un'applicazione per gestire gli errori temporanei previsti durante il tentativo di connessione a un servizio o a una risorsa di rete ritentando in modo trasparente un'operazione non riuscita in precedenza. |
|
| Saga | Gestire la coerenza dei dati tra microservizi in scenari di transazioni distribuite. Una saga è una sequenza di transazioni che aggiorna ogni servizio e pubblica un messaggio o un evento per attivare il passaggio successivo della transazione. |
|
| Supervisione agente di pianificazione | Coordinare un set di azioni in un set distribuito di servizi e di altre risorse remote. |
|
| Serie di istruzioni sequenziali | Elaborare un set di messaggi correlati in un ordine definito, senza bloccare l'elaborazione di altri gruppi di messaggi. |
|
| Partizionamento orizzontale | Dividere un archivio dati in un set di partizioni orizzontali. |
|
| Collaterale | Distribuire i componenti di un'applicazione in un processo o in un contenitore separato per fornire isolamento e incapsulamento. |
|
| Hosting di contenuto statico | Distribuire contenuto statico in un servizio di archiviazione basato sul cloud in grado di inviarlo direttamente al client. |
|
| Strangler Fig | Migrare in maniera incrementale un sistema legacy, sostituendo gradualmente parti specifiche di funzionalità con nuove applicazioni e servizi. |
|
| Limitazione | Controllare il consumo delle risorse usate da un'istanza di un'applicazione, un singolo tenant o un intero servizio. |
|
| Passepartout | Usare un token o una chiave che fornisca ai client l'accesso diretto limitato a una specifica risorsa o a un servizio. |
|
Passaggio successivo
Esaminare i modelli di progettazione dal punto di vista del Pilastro Azure Well-Architected che il modello intende ottimizzare.
- modelli di progettazione per supportare il pilastro Affidabilità
- Modelli di progettazione per supportare il pilastro Sicurezza
- Modelli di progettazione per supportare il pilastro Ottimizzazione costi
- modelli di progettazione per supportare il pilastro dell'eccellenza operativa
- Modelli di progettazione per supportare il pilastro Efficienza delle prestazioni