Modelli di progettazione cloud che supportano l'eccellenza operativa
Quando si progettano architetture del carico di lavoro, è consigliabile usare modelli di settore che affrontano le sfide comuni. I modelli consentono di effettuare compromessi intenzionali all'interno dei carichi di lavoro e ottimizzare per il risultato desiderato. Possono anche contribuire a mitigare i rischi che provengono da problemi specifici, che possono influire sull'affidabilità, sulla sicurezza, sulle prestazioni e sui costi. Poiché le operazioni tagliano in tutte queste aree, i rischi influiscono eventualmente sulle operazioni del carico di lavoro. Questi modelli sono supportati dall'esperienza reale, sono progettati per la scalabilità cloud e i modelli operativi e sono intrinsecamente fornitori agnostici. 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. I modelli di progettazione che supportano il pilastro dell'eccellenza operativa usano topologie che forniscono una base solida per le procedure di distribuzione sicura e facilitano l'evoluzione dell'architettura nel tempo, gli scenari di migrazione e l'osservabilità.
Modelli di progettazione per l'eccellenza operativa
La tabella seguente riepiloga i modelli di progettazione cloud che supportano gli obiettivi di eccellenza operativa.
| Modello | Summary |
|---|---|
| Livello antidanneggiamento | Protegge i nuovi componenti di sistema dal comportamento o dalle scelte di implementazione dei sistemi legacy aggiungendo un livello di mediatori alle interazioni proxy tra i componenti legacy e i nuovi componenti. Questo modello consente di assicurarsi che la progettazione di nuovi componenti rimanga influenziata dalle implementazioni legacy che potrebbero avere modelli di dati diversi o regole aziendali quando si integra con questi sistemi legacy. Il modello è particolarmente utile nelle migrazioni graduali del sistema. Riduce il debito tecnico nei nuovi componenti mentre supporta ancora i componenti esistenti. |
| Coreografia | Coordina il comportamento dei componenti distribuiti autonomi in un carico di lavoro usando comunicazioni decentralizzate basate su eventi. Questo modello può essere utile quando si prevede di aggiornare o sostituire i servizi spesso durante il ciclo di vita di un carico di lavoro. Poiché i componenti distribuiti sono autonomi, è possibile modificare il carico di lavoro con modifiche meno complessive al sistema. |
| Consolidamento delle risorse di calcolo | Ottimizza e consolida le risorse di calcolo aumentando la densità. Questo modello combina più applicazioni o componenti di un carico di lavoro in un'infrastruttura condivisa. Il consolidamento porta a una piattaforma di calcolo più omogenea, che può semplificare la gestione e l'osservabilità, ridurre approcci diversi alle attività operative e ridurre la quantità di strumenti necessari. |
| Stamp di distribuzione | Fornisce un approccio per rilasciare una versione specifica di un'applicazione e la relativa infrastruttura come unità controllata di distribuzione, in base al presupposto che le stesse versioni o diverse verranno distribuite simultaneamente. Questo modello è allineato agli obiettivi dell'infrastruttura non modificabili, supporta modelli di distribuzione avanzati e può facilitare le procedure di distribuzione sicure. |
| Archivio di configurazione esterno | Estrae la configurazione in un servizio esterno all'applicazione per supportare gli aggiornamenti dinamici ai valori di configurazione senza richiedere modifiche al codice o ridistribuzione dell'applicazione. Questa separazione della configurazione dell'applicazione dal codice dell'applicazione supporta la configurazione specifica dell'ambiente e applica il controllo delle versioni ai valori di configurazione. Gli archivi di configurazione esterni sono anche un luogo comune per gestire i flag di funzionalità per abilitare le procedure di distribuzione sicure. |
| Aggregazione gateway | Semplifica le interazioni client con il carico di lavoro aggregando chiamate a più servizi back-end in una singola richiesta. Questa topologia consente alla logica back-end di evolversi indipendentemente dai client, consentendo di modificare le implementazioni del servizio concatenati o anche le origini dati, senza dover modificare i punti di tocco client. |
| Offload del gateway | Offload dell'elaborazione delle richieste in un dispositivo gateway prima e dopo l'inoltro della richiesta a un nodo back-end. L'aggiunta di un gateway di offload al processo di richiesta consente di gestire la configurazione e il supporto della funzionalità caricata da un singolo punto anziché gestirlo da più nodi. |
| Routing del gateway | Instrada le richieste di rete in ingresso a vari sistemi back-end in base a finalità di richiesta, logica di business e disponibilità back-end. Il routing del gateway consente di separare le richieste dai back-end, che a sua volta consente ai back-end di supportare modelli di distribuzione avanzati, transizioni della piattaforma e un singolo punto di gestione per la risoluzione dei nomi di dominio e la crittografia in transito. |
| Monitoraggio endpoint di integrità | Fornisce un modo per monitorare l'integrità o lo stato di un sistema esponendo un endpoint progettato in modo specifico per tale scopo. Standardizzare gli endpoint di integrità da esporre e il livello di analisi nei risultati, in tutto il carico di lavoro può aiutare a valutare i problemi. |
| Bridge di messaggistica | Fornisce un intermediario per abilitare la comunicazione tra i sistemi di messaggistica che altrimenti non sono compatibili a causa del protocollo o del formato. Questo disaccoppiamento offre flessibilità quando si passa la tecnologia di messaggistica ed eventi all'interno del carico di lavoro o quando si hanno requisiti eterogenei dalle dipendenze esterne. |
| Autore/Sottoscrittore | Disaccoppia i componenti di un'architettura sostituendo la comunicazione diretta da client a servizio o client-to-services con comunicazione tramite un broker messaggi intermedio o un bus di eventi. Questo livello di indirettità può consentire di modificare in modo sicuro l'implementazione sul lato server di pubblicazione o sottoscrittore senza dover coordinare le modifiche a entrambi i componenti. |
| Quarantena | Assicura che gli asset esterni soddisfino un livello di qualità concordato dal team prima di essere autorizzati a usarli nel carico di lavoro. L'automazione e la coerenza su questi controlli fanno parte del ciclo di vita dello sviluppo software del carico di lavoro e delle procedure di distribuzione sicure (SDP). |
| Collaterale | Estende la funzionalità di un'applicazione incapsulando attività nonprimari o incrociate in un processo complementare presente insieme all'applicazione principale. Questo modello offre un approccio all'implementazione della flessibilità nell'integrazione degli strumenti che potrebbe migliorare l'osservabilità dell'applicazione senza richiedere all'applicazione di assumere dipendenze di implementazione diretta. Consente alla funzionalità sidecar di evolversi indipendentemente e di essere mantenuta indipendentemente dal ciclo di vita dell'applicazione. |
| Strangler Fig | Fornisce un approccio per sostituire sistematicamente i componenti di un sistema in esecuzione con nuovi componenti, spesso durante una migrazione o una modernizzazione del sistema. Questo modello fornisce un approccio di miglioramento continuo, in cui la sostituzione incrementale con piccole modifiche nel tempo è preferibile anziché grandi modifiche sistemiche più rischiose da implementare. |
Passaggi successivi
Esaminare i modelli di progettazione cloud che supportano gli altri pilastri di Azure Well-Architected Framework: