Questo browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
Questo articolo presenta un modello chiave per le architetture cruciali in Azure. Applicare questo modello all'avvio del processo di progettazione e quindi selezionare i componenti più adatti ai requisiti aziendali. L'articolo consiglia un approccio di progettazione stella polare e include altri esempi con componenti tecnologici comuni.
È consigliabile valutare le aree di progettazione principali, definire i flussi di utenti e sistemi critici che usano i componenti sottostanti e sviluppare una matrice di risorse di Azure e la relativa configurazione tenendo presenti le caratteristiche seguenti.
| Caratteristica | Considerazioni |
|---|---|
| Durata | Qual è la durata prevista della risorsa, rispetto ad altre risorse nella soluzione? La risorsa deve durare o avere la stessa durata di tutto il sistema o l'area, oppure deve essere temporanea? |
| Stato | Quale impatto avrà lo stato persistente a questo livello sull'affidabilità o sulla gestibilità? |
| Raggiungere | La risorsa deve essere distribuita a livello globale? La risorsa può comunicare con altre risorse, che si trovano a livello globale o all'interno di tale area? |
| Dipendenze | Quali sono le dipendenze da altre risorse? |
| Limiti di scalabilità | Qual è la velocità effettiva prevista per la risorsa? Quanta capacità è fornita dalla risorsa per soddisfare tale domanda? |
| Disponibilità/ripristino di emergenza | Qual è l'impatto sulla disponibilità da un'emergenza a questo livello? Causerebbe un'interruzione sistemica o solo una capacità localizzata o un problema di disponibilità? |
Importante
Questo articolo fa parte
Alcune risorse sono condivise a livello globale dalle risorse distribuite all'interno di ogni area. Esempi comuni sono le risorse usate per distribuire il traffico tra più aree, archiviare lo stato permanente per l'intera applicazione e monitorare le risorse.
| Caratteristica | Considerazioni |
|---|---|
| Durata della vita | Queste risorse dovrebbero essere di lunga durata (non temporanee). La loro durata dura tutta la vita del sistema o più a lungo. Spesso le risorse vengono gestite attraverso aggiornamenti in loco dei dati e del piano di controllo, presupponendo che supportino operazioni di aggiornamento senza interruzioni. |
| Stato | Poiché queste risorse esistono almeno per la durata del sistema, questo livello è spesso responsabile di archiviare lo stato globale e replicato geograficamente. |
| Raggiungere | Le risorse devono essere distribuite a livello globale e replicate nelle aree che ospitano tali risorse. È consigliabile che queste risorse comunichino con risorse regionali o altre con bassa latenza e la coerenza desiderata. |
| Dipendenze | Le risorse devono evitare dipendenze dalle risorse a livello di area perché la mancata disponibilità può essere causa di un errore globale. Ad esempio, i certificati o i segreti conservati in un singolo vault potrebbero avere un impatto globale se si verifica un guasto regionale dove si trova il vault. |
| Limiti di scalabilità | Spesso queste risorse sono istanze singleton nel sistema e devono essere in grado di scalare in modo che possano gestire il carico di lavoro del sistema nel suo complesso. |
| Disponibilità/ripristino di emergenza | Le risorse regionali e di timbro possono utilizzare risorse globali. È fondamentale che le risorse globali siano configurate con disponibilità elevata e ripristino di emergenza per l'integrità dell'intero sistema. |
Il sigillo contiene l'applicazione e le risorse coinvolte nel completamento delle transazioni aziendali. Un timbro corrisponde in genere a una distribuzione in un'area di Azure. Anche se una regione può avere più di un timbro.
| Caratteristica | Considerazioni |
|---|---|
| Durata della vita | Si prevede che le risorse abbiano una breve durata della vita (temporanea) con l'intento che possano essere aggiunte e rimosse in modo dinamico, mentre le risorse regionali al di fuori dello stampo continuino a persistere. La natura temporanea è necessaria per offrire maggiore resilienza, scalabilità e prossimità agli utenti. |
| Stato | Poiché i timbri sono temporanei e verranno eliminati definitivamente con ogni distribuzione, un timbro dovrebbe essere il più possibile senza stato. |
| Raggiungere | Può comunicare con risorse internazionali e globali. Tuttavia, è consigliabile evitare la comunicazione con altre aree o altri francobolli. |
| Dipendenze | Le risorse di stampa devono essere indipendenti. Si prevede che abbiano dipendenze internazionali e globali, ma non devono basarsi su componenti in altri francobolli nella stessa area o in altre aree. |
| Limiti di scalabilità | La velocità effettiva viene stabilita tramite prove. La velocità effettiva del timbro complessivo è limitata dalla risorsa meno performante. La velocità effettiva stamp deve stimare l'elevato livello di domanda causato da un failover a un altro stamp. |
| Disponibilità/ripristino di emergenza | A causa della natura temporanea dei francobolli, il ripristino di emergenza viene eseguito ridistribuendo il timbro. Se le risorse si trovano in uno stato di malfunzionamento, il timbro, nel suo complesso, può essere eliminato e ridistribuito. |
Un sistema può avere risorse distribuite nella regione che sopravvivono alle risorse di stamp. Ad esempio, le risorse di osservabilità che monitorano le risorse a livello di area, inclusi i francobolli.
| Caratteristica | Considerazione |
|---|---|
| Durata | Le risorse condividono la durata dell'area e sopravvivono alle risorse di stampa. |
| Stato | Lo stato archiviato in un'area non può vivere oltre la durata dell'area. Se lo stato deve essere condiviso tra aree, è consigliabile usare un archivio dati globale. |
| Raggiungere | Le risorse non devono essere distribuite a livello globale. È consigliabile evitare la comunicazione diretta con altre aree a tutti i costi. |
| Dipendenze | Le risorse possono avere dipendenze dalle risorse globali, ma non dalle risorse stampa perché le stampe sono destinate a essere di breve durata. |
| Limiti di scalabilità | Determinare il limite di scalabilità delle risorse regionali combinando tutti i francobolli all'interno dell'area. |
Questi esempi di base fungono da architettura north star consigliata per le applicazioni cruciali. La baseline consiglia vivamente la containerizzazione e l'uso di un agente di orchestrazione dei contenitori per la piattaforma dell'applicazione. La baseline utilizza il servizio Azure Kubernetes Service (AKS).
Fare riferimento a Well-Architected carichi di lavoro critici per le missioni: Containerizzazione.
Se stai iniziando il tuo viaggio critico per la missione, usa questa architettura come riferimento. Il carico di lavoro è accessibile tramite un endpoint pubblico e non richiede la connettività di rete privata ad altre risorse aziendali.
Questa architettura si basa sull'architettura di base. La progettazione viene estesa per fornire controlli di rete rigorosi per impedire l'accesso pubblico non autorizzato da Internet alle risorse del carico di lavoro.
Questa architettura è appropriata se si distribuisce il carico di lavoro in una configurazione aziendale in cui è necessaria l'integrazione all'interno di un'organizzazione più ampia. Il carico di lavoro usa servizi condivisi centralizzati, richiede connettività locale e si integra con altri carichi di lavoro all'interno dell'organizzazione. Viene distribuito in una sottoscrizione della zona di atterraggio di Azure che eredita dal gruppo di gestione Corp.
Questa architettura estende il riferimento di base considerando App Services come tecnologia di hosting delle applicazioni principale, offrendo un ambiente facile da usare per le distribuzioni di contenitori.
È consigliabile usare le linee guida di progettazione fornite per esplorare le principali decisioni di progettazione per raggiungere una soluzione ottimale. Per informazioni, vedere Quali sono le aree di progettazione principali?
Esaminare le procedure consigliate per la progettazione di scenari di applicazioni cruciali.