Condividi tramite

Suggerimenti per la progettazione per semplicità ed efficienza

  • Articolo

Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:

RE:01 Progettare il carico di lavoro per allinearsi agli obiettivi aziendali ed evitare complessità o sovraccarichi non necessari. Usare un approccio pratico ed equilibrato per prendere decisioni di progettazione che forniscano i risultati desiderati. Contenere la progettazione in base alle esigenze per ridurre le inefficienze e i potenziali problemi.

Questa guida descrive le raccomandazioni per ridurre al minimo la complessità e il sovraccarico non necessari per mantenere i carichi di lavoro semplici ed efficienti. Scegliere i componenti migliori per eseguire le attività del carico di lavoro necessarie per ottimizzare l'affidabilità del carico di lavoro. Per ridurre gli oneri di sviluppo e gestione, sfruttare l'efficienza offerta dai servizi forniti dalla piattaforma. Questa progettazione consente di creare un'architettura del carico di lavoro resiliente, ripetibile, scalabile e gestibile.

Definizioni

Termine Definizione
Carico di lavoro Una funzionalità discreta o un'attività di calcolo che è possibile separare logicamente da altre attività.

Strategie di progettazione chiave

Un elemento chiave della progettazione per l'affidabilità consiste nel mantenere le cose semplici ed efficienti. Concentrarsi sulla progettazione del carico di lavoro in base ai requisiti aziendali per ridurre il rischio di complessità non necessaria o sovraccarico in eccesso. Prendere in considerazione le raccomandazioni contenute in questo articolo per prendere decisioni sulla progettazione per creare un carico di lavoro snello, efficiente e affidabile. Diversi carichi di lavoro possono avere requisiti diversi per disponibilità, scalabilità, coerenza dei dati e ripristino di emergenza.

È necessario giustificare ogni decisione di progettazione con un requisito aziendale. Questo principio di progettazione potrebbe sembrare ovvio, ma è fondamentale per la progettazione del carico di lavoro. L'applicazione supporta milioni di utenti o poche migliaia? Sono presenti picchi di traffico di grandi dimensioni o un carico di lavoro costante? Quale livello di interruzione dell'applicazione è accettabile? I requisiti aziendali determinano queste considerazioni di progettazione.

Compromesso: una soluzione complessa può offrire più funzionalità e flessibilità, ma potrebbe influire sull'affidabilità del carico di lavoro perché richiede maggiore coordinamento, comunicazione e gestione dei componenti. In alternativa, una soluzione più semplice potrebbe non soddisfare completamente le aspettative degli utenti oppure potrebbe avere un effetto negativo sulla scalabilità e sull'estendibilità man mano che il carico di lavoro evolve.

Esercizi di progettazione collaborativa

Collaborare con gli stakeholder per:

  • Definire e assegnare un livello di criticità ai flussi utente e ai flussi di sistema del carico di lavoro. Concentrarsi sulla progettazione sui flussi critici per determinare i componenti necessari e l'approccio migliore per ottenere il livello di resilienza richiesto.

  • Definire i requisiti funzionali e non funzionali. Prendere in considerazione i requisiti funzionali per determinare se un'applicazione esegue un'attività. Prendere in considerazione i requisiti non funzionali per determinare il livello di prestazioni dell'applicazione in un'attività. Assicurarsi di comprendere i requisiti non funzionali, ad esempio scalabilità, disponibilità e latenza. Questi requisiti influiscono sulle decisioni di progettazione e sulle scelte tecnologico.

  • Scomporre i carichi di lavoro nei componenti. Assegnare priorità alla semplicità, all'efficienza e all'affidabilità nella progettazione. Determinare i componenti necessari per supportare i flussi. Alcuni componenti supportano più flussi. Identificare la sfida che un componente affronta concettualmente e prendere in considerazione la rimozione di un componente dai singoli flussi per semplificare la progettazione complessiva pur fornendo funzionalità complete. Per altre informazioni, vedere Raccomandazioni per l'esecuzione dell'analisi della modalità di errore.

  • Usare l'analisi della modalità di errore per identificare singoli punti di errore e potenziali rischi. Valutare se è necessario tenere conto di situazioni improbabili, ad esempio un'area geografica in cui si verifica una grave calamità naturale che interessa tutte le zone di disponibilità nell'area. È costoso e comporta notevoli compromessi per attenuare questi rischi non comuni. Comprendere chiaramente la tolleranza dell'azienda per i rischi. Per altre informazioni, vedere Raccomandazioni per l'esecuzione dell'analisi della modalità di errore.

  • Definire le destinazioni di disponibilità e ripristino per i flussi per informare l'architettura del carico di lavoro. Le metriche aziendali includono obiettivi a livello di servizio , contratti di servizio (SLA), tempo medio per il ripristino (MTTR), tempo medio tra errori (MTBF), obiettivi del tempo di ripristino (RTO) e obiettivi del punto di ripristino (RPO). Definire i valori di destinazione per queste metriche. Questo esercizio potrebbe richiedere compromessi e comprensione reciproca tra team tecnologici e aziendali per garantire che gli obiettivi di ogni team soddisfino gli obiettivi aziendali e siano realistici. Per altre informazioni, vedere Raccomandazioni per la definizione degli obiettivi di affidabilità.

Consigli aggiuntivi sulla progettazione

È possibile eseguire le raccomandazioni seguenti senza coinvolgimento degli stakeholder:

  • Ricercare semplicità e chiarezza nella progettazione. Usare il livello appropriato di astrazione e granularità per i componenti e i servizi. Evitare l'overengineering o la sottoprogettazione della soluzione. Ad esempio, se si suddivide il codice in più funzioni di piccole dimensioni, è difficile comprendere, testare e gestire.

  • Concedere che tutte le applicazioni di successo cambino nel tempo, se correggere bug, implementare nuove funzionalità o tecnologie o rendere i sistemi esistenti più scalabili e resilienti.

  • Usare le opzioni PaaS (Platform as a Service) invece dell'infrastruttura distribuita come servizio (IaaS) quando possibile. L'infrastruttura distribuita come servizio (IaaS) è come una scatola di mattoncini per le costruzioni: si può costruire tutto quello che si vuole, ma occorre assemblarlo autonomamente. Le opzioni PaaS sono più semplici da configurare e amministrare. Non è necessario configurare macchine virtuali (VM) o reti virtuali. Non è inoltre necessario eseguire attività di manutenzione, ad esempio l'installazione di patch e aggiornamenti.

  • Usare la messaggistica asincrona per separare il producer di messaggi dal consumer.

  • Astrarre l'infrastruttura dalla logica di dominio. Assicurarsi che la logica del dominio non interferisca con le funzionalità correlate all'infrastruttura, ad esempio la messaggistica o la persistenza.

  • Spostare le problematiche trasversali in un servizio distinto. Ridurre al minimo la necessità di duplicare il codice in diverse funzioni, preferire il riutilizzo dei servizi con interfacce ben definite che possono essere facilmente utilizzate da componenti diversi. Ad esempio, se diversi servizi devono autenticare le richieste, è possibile spostare questa funzionalità nel proprio servizio. È quindi possibile evolvere il servizio di autenticazione. Ad esempio, è possibile aggiungere un nuovo flusso di autenticazione senza toccare uno dei servizi che lo usano.

  • Valutare l'idoneità di modelli e procedure comuni per le proprie esigenze. Evitare di seguire le tendenze o le raccomandazioni che potrebbero non essere ottimali per il contesto o i requisiti. Ad esempio, i microservizi non sono l'opzione migliore per ogni applicazione perché possono introdurre problemi di complessità, sovraccarico e dipendenza.

Sviluppare codice sufficiente

I principi di semplicità, efficienza e affidabilità si applicano anche alle procedure di sviluppo. In un carico di lavoro ad accoppiamento debole e componentizzato, determinare la funzionalità fornita da un componente. Sviluppare i flussi per sfruttare questa funzionalità. Prendere in considerazione questi consigli per le procedure di sviluppo:

  • Usare le funzionalità della piattaforma quando soddisfano i requisiti aziendali. Ad esempio, per eseguire l'offload dello sviluppo e della gestione, usare soluzioni senza codice, senza codice o serverless offerte dal provider di servizi cloud.

  • Usare librerie e framework.

  • Introdurre sessioni di programmazione di coppie o di revisione del codice dedicata come procedura di sviluppo.

  • Implementare un approccio per identificare il codice non recapitato. Essere scettici del codice che i test automatizzati non coprono.

Usare l'archivio dati migliore per i dati

In passato, molte organizzazioni archiviarono tutti i dati in database SQL relazionali di grandi dimensioni. I database relazionali offrono garanzie atomiche, coerenti, isolate e durevoli (ACID) per le transazioni di dati relazionali. Tuttavia, questi database presentano svantaggi:

  • Le query possono richiedere join costosi.

  • È necessario normalizzare i dati e ristrutturarlo per lo schema in scrittura.

  • La contesa di blocco può influire sulle prestazioni.

Alternative ai database relazionali

In una soluzione di grandi dimensioni, è probabile che una singola tecnologia di archivio dati non soddisfi tutte le esigenze. Le alternative ai database relazionali includono:

  • Archivi chiave-valore

  • Database di documenti

  • Database di motori di ricerca

  • Database di serie temporali

  • Database della famiglia di colonne

  • Database a grafo

Ogni opzione presenta vantaggi e svantaggi. Tipi di dati diversi sono più adatti per diversi tipi di archivio dati. Scegliere la tecnologia di archiviazione più adatta per i dati e come usarla.

Ad esempio, è possibile archiviare un catalogo prodotti in un database di documenti, ad esempio Azure Cosmos DB, che supporta uno schema flessibile. Ogni descrizione del prodotto è un documento autonomo. Per le query sull'intero catalogo, è possibile indicizzare il catalogo e archiviare l'indice in Ricerca cognitiva di Azure. L'inventario dei prodotti potrebbe essere inserito in un database SQL perché i dati richiedono garanzie ACID.

Consigli

  • Prendere in considerazione altri archivi dati. I database relazionali non sono sempre appropriati. Per altre informazioni, vedere Informazioni sui modelli di archivio dati.

  • Tenere presente che i dati includono più di semplici dati dell'applicazione persistenti. ma anche i log applicazioni, gli eventi, i messaggi e le cache.

  • Adottare la persistenza poliglotta o le soluzioni che usano una combinazione di tecnologie di archivio dati.

  • Prendere in considerazione il tipo di dati disponibili. Ad esempio, archiviare:

    • Dati transazionali in un database SQL.

    • Documenti JSON in un database di documenti.

    • Telemetria in un database time series.

    • Log applicazioni in Ricerca cognitiva di Azure.

    • BLOB in Archiviazione BLOB di Azure.

  • Assegnare priorità alla disponibilità rispetto alla coerenza. Il teorema CAP implica che è necessario fare compromessi tra disponibilità e coerenza in un sistema distribuito. Non è possibile evitare completamente le partizioni di rete, ovvero l'altro componente del teorema CAP. È tuttavia possibile adottare un modello di coerenza finale per ottenere una disponibilità più elevata.

  • Prendere in considerazione il set di competenze del team di sviluppo. L'uso della persistenza poliglotta ha dei vantaggi, ma è possibile che si ecceda. Richiede nuovi set di competenze per adottare una nuova tecnologia di archiviazione dei dati. Per sfruttare al meglio la tecnologia, il team di sviluppo deve:

    • Ottimizzare le query.

    • Ottimizzare le prestazioni.

    • Usare i modelli di utilizzo appropriati.

Prendere in considerazione questi fattori quando si sceglie una tecnologia di archiviazione:

  • Usare la transazione di compensazione. Con la persistenza poliglotta, una singola transazione potrebbe scrivere dati in più archivi. Se si verifica un errore, usare transazioni di compensazione per annullare eventuali passaggi completati.

  • Considerare i contesti delimitati, ovvero un concetto di progettazione basato su dominio. Un contesto delimitato è un limite esplicito intorno a un modello di dominio. Un contesto delimitato definisce le parti del dominio a cui si applica il modello. In teoria, un contesto limitato esegue il mapping a un sottodominio del dominio aziendale. Prendere in considerazione la persistenza poliglotta per i contesti delimitati nel sistema. Ad esempio, i prodotti potrebbero essere visualizzati nel sottodominio del catalogo prodotti e nel sottodominio dell'inventario prodotti. Ma molto probabilmente, questi due sottodomini hanno requisiti diversi per l'archiviazione, l'aggiornamento e l'esecuzione di query sui prodotti.

Facilitazione di Azure

Azure offre i servizi seguenti:

  • Funzioni di Azure è un servizio di calcolo serverless che è possibile usare per creare orchestrazione con codice minimo.

  • App per la logica di Azure è una piattaforma di integrazione del flusso di lavoro serverless che è possibile usare per compilare l'orchestrazione con un'interfaccia utente grafica o modificando un file di configurazione.

  • Griglia di eventi di Azure è un servizio di distribuzione dei messaggi di pubblicazione-sottoscrizione completamente scalabile e completamente gestito che offre modelli di consumo di messaggi flessibili che usano i protocolli MQTT e HTTP. Con Griglia di eventi è possibile creare pipeline di dati con dati del dispositivo, compilare architetture serverless basate su eventi e integrare applicazioni.

Per altre informazioni, vedi:

Esempio

Per un carico di lavoro di esempio che determina i componenti e le relative funzionalità in base ai requisiti, vedere Modello di app Web Reliable.

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità