Valutazione e idoneità dei microservizi

Un'architettura di microservizi può offrire molti vantaggi per le applicazioni, tra cui agilità, scalabilità e disponibilità elevata. Questa architettura può anche presentare problemi. Quando si creano applicazioni basate su microservizi o si trasformano applicazioni esistenti in un'architettura di microservizi, è necessario analizzare e valutare la situazione corrente per identificare le aree che richiedono miglioramenti.

Questo articolo descrive le considerazioni per l'adozione di un'architettura di microservizi. Usare questa guida per valutare la maturità dell'applicazione, dell'infrastruttura, delle procedure DevOps e del modello di sviluppo.

Come usare questa valutazione

Questa valutazione è applicabile in più fasi del ciclo di vita dei microservizi, non solo durante la progettazione iniziale. Usarlo nelle situazioni seguenti:

  • Prima di adottare i microservizi. Valutare se l'organizzazione, i team e l'infrastruttura sono pronti per la transizione da un'architettura monolitica o modulare. I risultati consentono di identificare i prerequisiti da affrontare prima di iniziare la scomposizione.

  • Durante la scomposizione attiva. Quando si estraggono i servizi da un monolith, rivedere le sezioni pertinenti per verificare che ogni servizio soddisfi i criteri per la distribuzione indipendente, la proprietà dei dati, i modelli di comunicazione e l'osservabilità.

  • Per i sistemi di microservizi esistenti. Eseguire periodicamente la valutazione, ad esempio ogni anno o dopo un evento imprevisto significativo, per identificare la deriva dell'architettura, le lacune operative o le aree in cui le procedure sono cadute dietro le linee guida correnti.

Ogni sezione di questo articolo presenta un set di fattori da valutare. Per ogni fattore, registrare lo stato corrente, identificare il divario tra lo stato corrente e lo stato di destinazione e assegnare un proprietario e una sequenza temporale per la correzione. Considerare l'approccio seguente per agire sui risultati:

  1. Classificare i risultati in base alla gravità. Distinguere tra i bloccanti che impediscono operazioni di produzione sicure e miglioramenti che aumentano l'efficienza o riducono il rischio nel tempo.

  2. Assegnare priorità in base all'impatto aziendale. Allineare la correzione alle priorità aziendali identificate nella prima sezione di questa valutazione. Un divario nella resilienza è più importante per un carico di lavoro incentrato sull'affidabilità che per uno strumento interno in fase di sviluppo iniziale.

  3. Creare elementi di lavoro attuabili. Converti ogni rilievo in un elemento del backlog con criteri di accettazione chiari. Evitare di considerare la valutazione come elenco di controllo monouso. Integrare invece i risultati nei cicli di pianificazione regolari del team.

  4. Rivaluta dopo la correzione. Dopo aver affrontato una ricerca, rivedere la sezione pertinente per verificare che il divario sia chiuso e che la modifica non abbia introdotto nuove lacune nelle aree adiacenti.

Comprendere le priorità aziendali

Per valutare un'architettura di microservizi, comprendere prima di tutto le priorità principali dell'azienda. Ad esempio, le priorità possono includere agilità, adozione del cambiamento o sviluppo rapido. Analizzare se l'architettura è allineata a tali priorità. Le priorità aziendali possono cambiare nel tempo.

Considerare le priorità seguenti:

  • Innovazione, inclusa la promozione dell'agilità e della sperimentazione
  • Affidabilità, inclusa la garanzia della disponibilità elevata e della tolleranza di errore
  • Efficienza, inclusa l'ottimizzazione delle risorse e della produttività

Documentare gli obiettivi del livello di servizio (SLO) allineati a varie parti dell'applicazione per garantire un impegno aziendale che possa guidare la valutazione.

Registrare le decisioni relative all'architettura

Un'architettura di microservizi aiuta i team a diventare autonomi. I team possono prendere decisioni personalizzate su tecnologie, metodologie e componenti dell'infrastruttura. Tuttavia, queste scelte devono rispettare i principi formalmente concordati noti come governance condivisa. Questi principi esprimono l'accordo tra i team su come affrontare la strategia più ampia per i microservizi.

Prendere in considerazione i fattori seguenti:

  • Indica se la governance condivisa è in vigore per guidare le decisioni relative all'architettura tra i team

  • Se si mantengono record di decisioni di architettura (ADR) che includono logica chiara, compromessi e stato

  • Se si mantiene un diario dell'architettura per catturare esplorazioni di design e contesto in evoluzione

  • Se il team può accedere e cercare facilmente le ADR e il registro dell'architettura

  • Se si ha un framework di valutazione della tecnologia per valutare nuovi strumenti e framework

  • Se sono stati stabiliti principi per la selezione e la standardizzazione della tecnologia

  • Se le decisioni relative all'architettura vengono esaminate e aggiornate regolarmente man mano che i requisiti aziendali e tecnici si evolvono

Valutare la composizione del team

È necessario strutturare correttamente il team per evitare comunicazioni non necessarie tra i team. I team di piccole dimensioni, incentrati e interfunzionali sono la soluzione migliore per un'architettura di microservizi. Queste modifiche richiedono spesso un cambiamento di mentalità, che deve precedere la ristrutturazione del team.

Prendere in considerazione i fattori seguenti:

  • Se i team sono divisi in base ai sottodomini e seguono i principi di progettazione basata su dominio (DDD)

  • Se i team sono interfunzionali e hanno capacità sufficiente per creare e gestire i microservizi correlati in modo indipendente

  • Quantità di tempo impiegato in attività e attività non pianificate che non sono correlate ai progetti

  • Quantità di tempo impiegato per la collaborazione tra team

  • Se si dispone di un processo per identificare e ridurre al minimo il debito tecnico

  • Come i team imparano le lezioni e come comunicano questa esperienza

Usa la metodologia Twelve-Factor

L'obiettivo fondamentale della scelta di un'architettura di microservizi è offrire valore più veloce e adattarsi al cambiamento seguendo le procedure agile. La metodologia diTwelve-Factor app fornisce linee guida per la creazione di applicazioni gestibili e scalabili. Queste linee guida promuovono attributi come immutabilità, effimerità, configurazione dichiarativa e automazione. Incorporando queste linee guida ed evitando problemi comuni, è possibile creare microservizi indipendenti e ad accoppiamento libero.

Comprendere l'approccio di scomposizione

La trasformazione di un'applicazione monolitica in un'architettura di microservizi richiede tempo. Iniziare con i servizi perimetrali. I servizi perimetrali hanno meno dipendenze da altri servizi e possono essere facilmente separati dal sistema come servizi indipendenti. Si raccomanda vivamente di utilizzare modelli come Strangler Fig e Livello Anti-Corruzione per mantenere le applicazioni monolitiche funzionanti, fino a che tutti i servizi siano suddivisi in microservizi separati. Durante la separazione, i principi di DDD possono aiutare i team a scegliere componenti o servizi dall'applicazione monolitica in base ai sottodomini.

Ad esempio, un sistema di e-commerce potrebbe avere moduli come carrello, gestione dei prodotti, gestione degli ordini, prezzi, generazione di fatture e notifica. Si decide di avviare la trasformazione dell'applicazione con il modulo di notifica perché non ha dipendenze da altri moduli. Tuttavia, altri moduli potrebbero dipendere da questo modulo per inviare notifiche. È possibile rendere il modulo di notifica un microservizio separato, ma è anche necessario aggiornare l'applicazione monolitica per chiamare il nuovo servizio di notifica. Si decide di trasformare il modulo di generazione della fattura successivamente. Questo modulo viene chiamato dopo la generazione di un ordine. È possibile usare modelli come Strangler Fig e Anti-Corruption Layer per supportare questa trasformazione.

La sincronizzazione dei dati, scritture multiple su interfacce sia monolitiche che di microservizi, gestione della proprietà dei dati, scomposizione dello schema, join, volume di dati e integrità dei dati potrebbero rendere difficile la suddivisione e la migrazione dei dati. Esistono diverse tecniche che è possibile usare, ad esempio mantenere un database condiviso tra microservizi, disaccoppiare i database da un gruppo di servizi basati su funzionalità o dominio aziendali e isolare i database dai servizi. Una soluzione ideale consiste nel scomporre ogni database con ogni servizio. Alcune circostanze potrebbero rendere questo approccio poco pratico. In questi casi, è possibile applicare modelli come il modello di visualizzazione materializzata e gli approcci, ad esempio la modernizzazione delle applicazioni usando un wrapper API per astrarre e modernizzare l'accesso ai dati legacy o condivisi.

Valutare l'idoneità di DevOps

Quando si passa a un'architettura di microservizi, è importante valutare le competenze di DevOps. Un'architettura di microservizi deve facilitare lo sviluppo agile nelle applicazioni per aumentare l'agilità organizzativa. DevOps è una delle procedure chiave da implementare per ottenere questa competenza.

Quando si valuta la funzionalità DevOps per un'architettura di microservizi, considerare i punti seguenti:

  • Se gli utenti dell'organizzazione conoscono le procedure e i principi fondamentali di DevOps

  • Se i team comprendono gli strumenti di controllo del codice sorgente e il modo in cui si integrano con pipeline di integrazione continua e recapito continuo (CI/CD)

  • Se si implementano correttamente le procedure DevOps, tra cui:

    • Seguire le pratiche agili.

    • Implementazione dell'integrazione continua.

    • Implementazione del recapito continuo, in cui le modifiche al codice vengono compilate, testate e preparate automaticamente per il rilascio nell'ambiente di produzione. Questo approccio consente di garantire che il software possa essere rilasciato in modo sicuro in qualsiasi momento e con approvazione manuale.

    • Implementazione della distribuzione continua, che estende il recapito continuo distribuendo automaticamente le modifiche al codice nell'ambiente di produzione dopo aver superato tutti i test automatizzati, senza intervento manuale.

    • Incorporamento del monitoraggio continuo in tutte le fasi di DevOps e operazioni IT per garantire l'integrità, le prestazioni e l'affidabilità continue delle applicazioni e dell'infrastruttura durante il passaggio dallo sviluppo agli ambienti di produzione e cliente.

  • Se la strategia di automazione dei processi di build e deployment è allineata agli obiettivi di consegna e ai requisiti operativi del team

  • Che si utilizzino i feature flag e le strategie di rilascio progressivo

  • Come viene gestita la configurazione degli ambienti di gestione temporanea e di produzione per l'applicazione

  • Indica se la catena di strumenti dispone del supporto della community e di un modello di supporto e fornisce canali e documentazione appropriati

Identificare le aree aziendali che cambiano frequentemente

Un'architettura di microservizi è flessibile e adattabile. Durante la valutazione, facilitare una discussione nell'organizzazione per determinare le aree che i colleghi si aspettano di cambiare frequentemente. La creazione di microservizi consente ai team di rispondere rapidamente alle modifiche richieste dai clienti e ridurre al minimo le attività di test di regressione. In un'applicazione monolitica, una modifica in un modulo richiede numerosi livelli di test di regressione e riduce l'agilità nelle nuove versioni.

Prendere in considerazione i fattori seguenti:

  • Indica se il servizio è distribuibile in modo indipendente

  • Indica se il servizio segue i principi DDD

  • Indipendentemente dal fatto che il servizio segua i principi di responsabilità singola, aperto-chiuso, sostituzione di Liskov, segregazione dell'interfaccia e inversione delle dipendenze (SOLID)

  • Indica se il database è privato del servizio

  • Che tu costruisca il servizio utilizzando il framework supportato per microservizi

Valutare l'idoneità dell'infrastruttura

Quando si passa a un'architettura di microservizi, l'idoneità dell'infrastruttura è un punto fondamentale da considerare. La configurazione non corretta dell'infrastruttura o l'uso dei servizi o dei componenti appropriati influisce sulle prestazioni, la disponibilità e la scalabilità dell'applicazione. È possibile usare tutte le metodologie e le procedure suggerite per creare un'applicazione. Tuttavia, se l'infrastruttura non è adeguata, l'applicazione potrebbe avere prestazioni scarse e richiedere manutenzione aggiuntiva.

Quando si valuta l'idoneità dell'infrastruttura, tenere presenti i fattori seguenti:

  • Indica se l'infrastruttura garantisce la scalabilità dei servizi distribuiti

  • Se l'infrastruttura dei contenitori è pronta per la distribuzione di microservizi

  • Indica se l'infrastruttura supporta il provisioning tramite script che possono essere automatizzati tramite CI/CD

  • Indica se l'infrastruttura di distribuzione offre un contratto di servizio per la disponibilità

  • Se si dispone di un piano di ripristino di emergenza (DR) e programmi di esercitazioni di routine

  • Indica se i dati vengono replicati in aree diverse per il ripristino di emergenza

  • Se si dispone di un piano di backup dei dati

  • Indica se le opzioni di distribuzione sono documentate

  • Indica se l'infrastruttura di distribuzione viene monitorata

  • Indica se l'infrastruttura di distribuzione supporta la riparazione automatica dei servizi

Per informazioni sulla selezione di una piattaforma di calcolo, vedere Scegliere un'opzione di calcolo di Azure per i microservizi.

Valutare i cicli di rilascio

I microservizi possono adattarsi al cambiamento e sfruttare lo sviluppo agile per abbreviare i cicli di rilascio e portare valore ai clienti più velocemente. Quando si valutano i cicli di rilascio, tenere presenti i fattori seguenti:

  • Frequenza di compilazione e rilascio delle applicazioni.

  • Frequenza con cui i rilasci hanno esito negativo dopo la distribuzione.

  • Tempo necessario per ripristinare o correggere i problemi dopo un'interruzione.

  • Indica se si usa il controllo delle versioni semantiche per le applicazioni.

  • Se si mantengono ambienti diversi e si propaga la stessa versione in una sequenza. Ad esempio, si effettua il rilascio prima nell'ambiente di staging e poi in produzione.

  • Se si usa il controllo delle versioni per le API.

  • Se si seguono le linee guida appropriate per il controllo delle versioni per le API.

  • Quando si modifica una versione dell'API.

  • Qual è l'approccio alla gestione delle versioni delle API, tra cui:

    • Controllo delle versioni del percorso URI.
    • Controllo delle versioni dei parametri di query.
    • Controllo delle versioni dei tipi di contenuto.
    • Controllo delle versioni delle intestazioni personalizzate.

  • Se hai una pratica in atto per il versionamento degli eventi.

Valutare la comunicazione tra i servizi

I microservizi sono servizi autonomi che comunicano tra loro attraverso i limiti dei processi per affrontare gli scenari aziendali. Per ottenere comunicazioni affidabili e affidabili, è necessario selezionare un protocollo di comunicazione appropriato.

Prendere in considerazione i fattori seguenti:

  • Se si segue un approccio API-first, in cui si progettano e mantengono le API come componenti principali dell'architettura di sistema.

  • Se si valutano protocolli ad alte prestazioni, ad esempio gRPC, HTTP/2 o messaggistica asincrona come Kafka o NATS, per una comunicazione efficiente da servizio a servizio.

  • Indipendentemente dal fatto che siano presenti operazioni a catena prolungata, in cui più servizi comunicano in sequenza tramite un protocollo di comunicazione sincrono.

  • Indica se si usano piattaforme di streaming di eventi per l'elaborazione dei dati in tempo reale.

  • Indica se si prevede di implementare la comunicazione asincrona ovunque nel sistema.

  • Indica se si prevede di valutare la tecnologia di Message Broker e le relative funzionalità.

  • Indica se si comprende la velocità effettiva dei messaggi che i servizi ricevono ed elaborano.

  • Indica se si usa la comunicazione diretta da client a servizio.

  • Se è necessario rendere persistenti i messaggi a livello di broker di messaggi.

  • Indica se si usa il modello Visualizzazione materializzata per risolvere il comportamento di chat dei microservizi.

  • Sia che si preveda di implementare modelli di ritentare, circuit breaker, ritardo esponenziale, o jitter per una comunicazione affidabile. Un modo comune per gestire queste funzionalità consiste nell'usare il modello Ambassador.

  • Indica se sono stati definiti eventi di dominio per facilitare la comunicazione tra microservizi.

Valutare la mesh del servizio e l'individuazione dei servizi

Man mano che aumenta il numero di microservizi, gestire nel codice dell'applicazione aspetti trasversali della rete come mTLS, nuovi tentativi, regolazione del traffico e autorizzazione per singolo servizio diventa difficile da mantenere e rendere coerente. Un service mesh sposta questi aspetti in un livello di infrastruttura dedicato, generalmente implementato tramite proxy sidecar, in modo che i singoli servizi non debbano occuparsene.

L'individuazione dei servizi è un prerequisito per una comunicazione affidabile tra servizi. Negli ambienti dinamici in cui le istanze del servizio vengono aumentate o ridotte, i client non possono fare affidamento su indirizzi statici. Un meccanismo di scoperta dei servizi mantiene un registro aggiornato delle istanze disponibili e instrada il traffico di conseguenza.

Prendere in considerazione i fattori seguenti:

  • Che ci si affidi al service discovery nativo della piattaforma, come gli oggetti Service di Kubernetes, oppure che sia necessario un registro dei servizi dedicato per ambienti che si estendono su più cluster o workload non containerizzati

  • Se gli aspetti di rete trasversali, come mTLS, i nuovi tentativi, i timeout e i circuit breaker, siano implementati in modo coerente in tutti i servizi oppure duplicati nel codice applicativo di ciascun servizio

  • Indica se è stata valutata una mesh di servizi per eseguire l'offload di mTLS, la gestione del traffico, i tentativi con backoff e l'osservabilità dal codice dell'applicazione al livello dell'infrastruttura

  • Se i vostri requisiti di gestione del traffico, come i rilasci canary, la suddivisione del traffico o l'iniezione di guasti per i test, giustificano il sovraccarico operativo di un service mesh

  • Indica se i criteri di autorizzazione per servizio vengono applicati in modo coerente ,ad esempio tramite i criteri della mesh dei servizi, mentre ogni servizio convalida ancora i token e applica le proprie regole di autorizzazione

  • Come gestire la comunicazione tra servizi oltre i confini del cluster o in ambienti ibridi in cui il meccanismo di discovery nativo della piattaforma non arriva

Valutare il modo in cui i servizi vengono esposti ai client

Un gateway API è uno dei componenti principali di un'architettura di microservizi. L'esposizione diretta dei servizi ai client crea problemi di gestibilità, controllo e comunicazione affidabile. Un gateway API funge da server proxy che intercetta il traffico e lo instrada ai servizi back-end. Se è necessario filtrare il traffico in base all'indirizzo IP, all'autorizzazione o alle risposte fittizie, è possibile filtrarlo a livello di gateway API senza apportare modifiche ai servizi.

Prendere in considerazione i fattori seguenti:

  • Indica se i client utilizzano direttamente i servizi

  • Indica se un gateway API funge da facciata unificata per tutti i servizi

  • Se si implementa il Backends for Frontends (BFF) pattern per diversi tipi di client

  • Indica se il gateway API può configurare criteri come limiti di quota, risposte fittizie e filtro degli indirizzi IP

  • Se si usano più gateway API per soddisfare le esigenze di vari tipi di client, ad esempio app per dispositivi mobili, app Web e partner

  • Se il gateway API fornisce un portale in cui i client possono individuare e sottoscrivere servizi, ad esempio un portale per sviluppatori in Gestione API di Azure

  • Se la soluzione offre funzionalità di bilanciamento del carico L7 o web application firewall (WAF) insieme al gateway API

Valutare la gestione delle transazioni

Le transazioni distribuite consentono di eseguire più operazioni come singola unità di lavoro. In un'architettura di microservizi, il sistema viene scomposto in numerosi servizi. Più microservizi indirizzano un singolo caso d'uso aziendale come parte di una singola transazione distribuita. In una transazione distribuita, un comando è un'operazione che viene avviata quando si verifica un evento. L'evento attiva un'operazione nel sistema. Se l'operazione ha esito positivo, potrebbe attivare un altro comando, che può quindi attivare un altro evento. Questo processo continua fino al completamento o al rollback di tutte le transazioni, a seconda che la transazione abbia esito positivo.

Prendere in considerazione i fattori seguenti:

  • Numero di transazioni distribuite nel sistema

  • Come gestire le transazioni distribuite, incluso l'uso del modello Saga con orchestrazione o coreografia

  • Che si usi event sourcing per mantenere la cronologia delle transazioni e lo stato

  • Se si implementano modelli CQRS (Command Query Responsibility Segregation)

  • Quante transazioni si estendono su più servizi

  • Sia che si segua un modello di transazione atomicità, coerenza, isolamento e durabilità (ACID) o un modello di transazione sostanzialmente disponibile, flessibile e infine coerente (BASE) per ottenere la coerenza e l'integrità dei dati

  • Indica se si usano operazioni di concatenamento lungo per le transazioni che si estendono su più servizi

  • Se si implementano modelli di compensazione oltre a Saga per il rollback delle transazioni

Valutare il modello di sviluppo del servizio

Uno dei maggiori vantaggi delle architetture di microservizi è la diversità tecnologica. I sistemi basati su microservizi consentono ai team di sviluppare servizi usando le tecnologie scelte. Nello sviluppo di applicazioni tradizionali, è possibile riutilizzare il codice esistente quando si compilano nuovi componenti o creare un framework di sviluppo interno per ridurre le attività di sviluppo. L'uso di più tecnologie può impedire il riutilizzo del codice.

Prendere in considerazione i fattori seguenti:

  • Se si usa un modello di servizio standardizzato per accelerare lo sviluppo di nuovi servizi e garantire la coerenza nelle procedure di architettura, distribuzione e DevOps

  • Se si segue la metodologia dell'app Twelve-Factor e si usa una singola codebase per i microservizi per isolare le dipendenze ed esternalizzare la configurazione

  • Se si mantiene la configurazione sensibile negli archivi delle chiavi

  • Se [tu] containerizzi i servizi

  • Se si conoscono i requisiti di coerenza dei dati

Valutare l'approccio alla distribuzione

L'approccio alla distribuzione è il metodo per rilasciare versioni dell'applicazione in diversi ambienti di distribuzione. I sistemi basati su microservizi offrono l'agilità necessaria per rilasciare le versioni più velocemente rispetto alle applicazioni tradizionali.

Quando si valuta il piano di distribuzione, considerare i fattori seguenti:

  • Se si ha una strategia per la distribuzione dei servizi.

  • Se si usano strumenti e tecnologie moderni per distribuire i servizi.

  • Che tipo di team di collaborazione richiedono quando si distribuiscono i servizi.

  • Se si effettua il provisioning dell'infrastruttura tramite Infrastructure as Code (IaC).

  • Se si seguono principi di infrastruttura non modificabili.

  • Se si usano funzionalità DevOps per automatizzare le distribuzioni.

  • Indica se si propagano le stesse compilazioni in ambienti, come consigliato dalla metodologia di app Twelve-Factor.

  • Indica se si usa un approccio GitOps. In questo modello lo stato desiderato dell'infrastruttura e della configurazione dell'applicazione viene archiviato in modo dichiarativo in Git e riconciliato automaticamente da un operatore.

Valutare la piattaforma di hosting

La scalabilità è uno dei principali vantaggi delle architetture di microservizi. I microservizi corrispondono ai domini aziendali, così puoi scalare ogni servizio in modo indipendente. Un'applicazione monolitica viene distribuita come singola unità in una piattaforma di hosting, quindi è necessario ridimensionarla in modo olistico. Questo approccio comporta tempi di inattività, rischi di distribuzione e manutenzione. L'applicazione monolitica potrebbe essere ben progettata e avere componenti che indirizzano singoli domini aziendali. Ma a causa di una mancanza di limiti di processo, il potenziale di violare i principi di responsabilità singola aumenta. Gli sforzi per applicare i principi della singola responsabilità possono comportare codice che non dispone di struttura ed è difficile da gestire. Poiché l'applicazione è composta e distribuita come singolo processo di hosting, la scalabilità è difficile da ottenere.

I microservizi consentono ai team di scegliere la piattaforma di hosting appropriata per supportare le esigenze di scalabilità. Diverse piattaforme di hosting possono risolvere questi problemi fornendo funzionalità come la scalabilità automatica, il provisioning elastico, la disponibilità più elevata, la distribuzione più veloce e il monitoraggio semplice.

Prendere in considerazione i fattori seguenti:

  • Quale piattaforma di hosting, ad esempio macchine virtuali, contenitori o piattaforme serverless, viene usata per distribuire i servizi

  • Indica se la piattaforma di hosting è scalabile e supporta la scalabilità automatica

  • Quanto tempo è necessario per ridimensionare la piattaforma di hosting

  • Se si conoscono i contratti di servizio forniti da varie piattaforme di hosting

  • Indica se la piattaforma di hosting supporta il ripristino di emergenza

Valutare la resilienza e la gestione degli errori

I microservizi sono sistemi distribuiti in cui l'errore parziale è la norma anziché l'eccezione. La valutazione della resilienza valuta sia il modo in cui i singoli servizi reagiscono agli errori che la piattaforma contiene l'impatto degli errori tra zone di disponibilità, aree e dipendenze. Per indicazioni più generali, vedere il pilastro Affidabilità di Well-Architected Framework.

Considerare i fattori seguenti a livello di servizio:

  • Se i servizi considerano gli errori transitori, ad esempio timeout, limitazione della velocità ed errori di I/O temporanei, come una condizione prevista e applicano criteri di nuovo tentativo con un numero limitato di tentativi, backoff e jitter

  • Se i timeout sono definiti in corrispondenza di ogni confine di rete e i circuit breaker hanno soglie esplicite per l'apertura, il sondaggio nello stato semiaperto e la chiusura

  • Se le operazioni di scrittura siano idempotenti in modo che i nuovi tentativi non producano effetti collaterali duplicati

  • Se le funzionalità non critiche continuano a funzionare in modo degradato, ad esempio fornendo dati dalla cache o non aggiornati oppure venendo temporaneamente disattivate, quando le relative dipendenze non sono disponibili

Considerare i fattori seguenti a livello di piattaforma:

  • Indica se i servizi vengono distribuiti in più zone di disponibilità e tra aree in cui l'obiettivo del tempo di ripristino (RTO) lo richiede

  • Se le dipendenze dai servizi di piattaforma, ad esempio rete, identità, messaggistica e archiviazione, sono configurate per la ridondanza della zona o dell'area geografica

  • Se gli aggiornamenti della piattaforma, l'applicazione di patch e il ridimensionamento vengono completati senza tempi di inattività del servizio

  • Se gli obiettivi di tempo di ripristino (RTO) e di punto di ripristino (RPO) sono definiti per ciascun servizio

  • Indica se le procedure di failover e ripristino sono documentate ed eseguite su una cadenza definita

Valutare il monitoraggio dei servizi

Il monitoraggio è un elemento importante di un'applicazione basata su microservizi. La risoluzione degli errori può risultare scoraggiante perché l'applicazione è suddivisa in molti servizi eseguiti in modo indipendente. Se si usa una semantica appropriata per monitorare i servizi, i team possono monitorare, analizzare e rispondere facilmente agli errori.

Prendere in considerazione i fattori seguenti:

  • Se si monitorano i servizi distribuiti

  • Se si sono definiti gli obiettivi di livello di servizio

  • Se si ha un meccanismo di registrazione e quali strumenti si usano

  • Indica se le richieste includono un identificatore di traccia che si propaga attraverso ogni servizio, inclusi i limiti asincroni dei messaggi, usando uno standard, ad esempio il contesto di traccia W3C

  • Sia che si usi OpenTelemetry o un framework compatibile per raccogliere ed esportare tracce, metriche e log in un formato indipendente dal fornitore

  • Se tracce, log e metriche sono correlati tramite ID di traccia, in modo che una richiesta possa essere ricostruita da un capo all'altro

  • Se si registrano eccezioni

  • Se si mantengono i codici di errore aziendali per identificare rapidamente i problemi

  • Se utilizzi sonde di salute per i servizi

  • Se si usa la registrazione semantica e si implementano metriche chiave, soglie e indicatori

  • Se si mascherano i dati sensibili durante la registrazione

  • Se si monitorano le dipendenze del servizio e le integrazioni esterne

Valutare gli ID di correlazione e le chiavi di idempotenza

In un'architettura di microservizi, una singola richiesta utente passa spesso attraverso molti servizi ospitati in modo indipendente. Due identificatori correlati consentono di tracciare la richiesta e riprovarla in modo sicuro: un ID di correlazione e chiavi di idempotenza.

Un ID di correlazione è un singolo identificatore assegnato dal gateway API o dal primo servizio quando la richiesta entra nel sistema. Ogni servizio nella catena di chiamate riceve questo identificatore in un'intestazione di richiesta e lo include nei log e nei dati di telemetria. Poiché lo stesso ID di correlazione viene visualizzato nei log di ogni servizio, è possibile ricostruire il percorso di richiesta end-to-end, determinare la causa radice di un errore e valutare l'impatto.

Le chiavi di idempotenza si basano sull'ID di correlazione per garantire che i nuovi tentativi siano sicuri. Quando un servizio riceve una richiesta, deriva una chiave di idempotency dall'ID di correlazione e da un qualificatore specifico del servizio, ad esempio corr-7A3F:payment. Il servizio archivia questa chiave nel proprio database prima di iniziare l'elaborazione. Se un nuovo tentativo arriva con lo stesso ID di correlazione, il servizio ricostruisce la stessa chiave di idempotenza, lo trova nel database e ignora la rielaborazione. Ogni servizio nella catena ricava la propria chiave di idempotenza dall'ID di correlazione condiviso, quindi i nuovi tentativi possono essere eseguiti in sicurezza nell'intera transazione senza richiedere un meccanismo separato di generazione della chiave. Per la tecnica equivalente applicata ai consumer di messaggi, vedere il modello Consumer Idempotente.

Si consideri, ad esempio, una transazione di ordine che passa attraverso tre servizi: Ordine, Pagamento e Inventario. Il gateway API assegna l'ID di correlazione corr-7A3F. Ogni servizio deriva la propria chiave di idempotenza: corr-7A3F:order, corr-7A3F:paymente corr-7A3F:inventory. Se il servizio inventario ha esito negativo e la transazione viene ritentata, i servizi di ordine e pagamento individuano le chiavi di idempotenza e ignorano la rielaborazione. Il servizio Inventario non trova la chiave perché il tentativo precedente non è riuscito prima dell'archiviazione, quindi elabora normalmente la richiesta. Nel frattempo, la ricerca nei log mostra corr-7A3F il percorso di richiesta completo in tutti e tre i servizi, tra cui l'errore originale e il nuovo tentativo riuscito.

Prendere in considerazione i fattori seguenti:

  • In quale fase si assegna l'ID di correlazione

  • Quale componente assegna l'ID di correlazione

  • Se ciascun servizio archivia le chiavi di idempotenza nel proprio database per supportare nuovi tentativi sicuri

  • Formato degli ID di correlazione e delle chiavi di idempotenza

  • Se si registrano gli ID di correlazione e altre informazioni sulla richiesta

Valutare la necessità di un framework di chassis per microservizi

Un framework di chassis di microservizi è un framework di base che offre funzionalità per problemi trasversali, ad esempio la registrazione, la gestione delle eccezioni, la traccia distribuita, la sicurezza e la comunicazione. Quando si usa un framework dello chassis, è necessario concentrarsi maggiormente sull'implementazione del limite del servizio rispetto all'interazione con le funzionalità dell'infrastruttura.

Si supponga, ad esempio, di creare un servizio di gestione del carrello. Si vuole convalidare il token in ingresso, scrivere i log nel database di registrazione e comunicare con un altro servizio richiamando l'endpoint del servizio. Se si usa un framework di chassis di microservizi, è possibile ridurre gli sforzi di sviluppo. Dapr è un sistema che fornisce vari blocchi predefiniti per l'implementazione di problematiche trasversali.

Prendere in considerazione i fattori seguenti:

  • Se si utilizza un framework chassis per microservizi.

  • Se si utilizza Dapr per interagire con preoccupazioni trasversali.

  • Indica se il framework dello chassis è agnostico rispetto al linguaggio.

  • Se il framework dello chassis è generico in modo che possa supportare tutti i tipi di applicazioni. Un framework dello chassis non deve contenere logica specifica dell'applicazione.

  • Indica se il framework dello chassis fornisce un meccanismo per usare i componenti o i servizi selezionati in base alle esigenze.

Valutare l'approccio ai test delle applicazioni

In genere si testa l'applicazione dopo il completamento dello sviluppo ed è pronta per l'implementazione negli ambienti di test di accettazione utente e produzione. Prendere in considerazione il test in precedenza nel ciclo di vita di sviluppo dell'applicazione. Questo approccio è noto come test di spostamento a sinistra. Aumenta la qualità delle applicazioni perché si eseguono test durante ogni fase del ciclo di vita di sviluppo delle applicazioni, incluse le fasi di progettazione, sviluppo e post-sviluppo.

Ad esempio, quando si compila un'applicazione, si inizia progettando un'architettura. Quando si usa l'approccio di spostamento a sinistra, si testa la progettazione per individuare le vulnerabilità usando strumenti come Microsoft Threat Modeling Tool. Quando si avvia lo sviluppo, è possibile analizzare il codice sorgente eseguendo strumenti come test di sicurezza delle applicazioni statici (SAST) e usando altri analizzatori per individuare i problemi. Dopo aver distribuito l'applicazione, è possibile usare strumenti come il test di sicurezza delle applicazioni dinamiche (DAST) per testarlo mentre è ospitato. I test funzionali, i test chaos, i test di penetrazione e altri tipi di test vengono eseguiti in un secondo momento.

Prendere in considerazione i fattori seguenti:

  • Se si scrivono piani di test che coprono l'intero ciclo di vita di sviluppo

  • Se si includono tester nelle riunioni dei requisiti e nell'intero ciclo di vita dello sviluppo di applicazioni

  • Se si usa lo sviluppo basato su test o lo sviluppo basato sul comportamento

  • Se si testano le storie utente e si includono criteri di accettazione nelle storie utente

  • Se si testa la progettazione usando strumenti come Threat Modeling Tool

  • Se scrivi test unità

  • Se si usano analizzatori di codice statici o altri strumenti per misurare la qualità del codice

  • Se si usano strumenti automatizzati per testare le applicazioni

  • Se implementate pratiche DevOps sicure

  • Se si eseguono test di integrazione, test di applicazioni end-to-end, test di carico e prestazioni, test di penetrazione e test del caos

Valutare la sicurezza dei microservizi

La protezione dei servizi, l'accesso sicuro e la comunicazione sicura sono tra le considerazioni più importanti per un'architettura di microservizi. Un approccio Zero Trust richiede che ogni servizio verifichi in modo indipendente l'identità e l'autorizzazione di ogni richiesta, indipendentemente dal fatto che la richiesta abbia origine dall'esterno o dall'interno del limite di rete. Per applicare questo principio in modo coerente senza duplicare la logica, centralizzare il rilascio dei token e l'imposizione dei criteri nel gateway API o tramite un proxy sidecar. Ad esempio, i componenti middleware di Dapr e i criteri di autorizzazione del service mesh. Ogni servizio convalida ancora il token e applica le proprie regole di autorizzazione. Un gateway API può anche applicare filtri e criteri aggiuntivi, ad esempio quelli basati sulla top 10 OWASP, per intercettare il traffico rischioso prima di raggiungere i servizi back-end.

Prendere in considerazione i fattori seguenti:

  • Indica se il servizio richiede l'autenticazione e l'autorizzazione e se si implementano i principi dell'architettura Zero Trust

  • Che si disponga di una strategia completa di gestione dei segreti che includa la rotazione delle chiavi, la gestione del ciclo di vita e la verifica, andando oltre la semplice archiviazione dei segreti in un archivio sicuro di chiavi e segreti

  • Indica se si usa un gateway API per convalidare i token e le richieste in ingresso

  • Che si utilizzi Transport Layer Security (TLS) o TLS reciproco (mTLS) per garantire la sicurezza della comunicazione tra servizi

  • Indipendentemente dal fatto che si implementi l'analisi di sicurezza dei contenitori e delle immagini, generare una fattura software di materiali (SBOM) per ogni immagine e firmare le immagini per verificarne la provenienza prima della distribuzione

  • Se si implementano criteri di sicurezza di rete per consentire la comunicazione necessaria tra i servizi

  • Sia che si usino firewall, ad esempio L4 o L7, se applicabile per garantire maggiore sicurezza per le comunicazioni interne ed esterne

  • Se si usano criteri di sicurezza nei gateway API per controllare il traffico

  • Indica se è disponibile il monitoraggio della sicurezza di runtime per rilevare un comportamento anomalo

Contributors

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

  • Last updated on