Best practice per i servizi canonici

Nota: i servizi canonici sono supportati automaticamente in Anthos Service Mesh versione 1.6.8 e successive.

I servizi canonici consentono di esplorare molte configurazioni diverse. Per un'esperienza ottimale con le dashboard di servizio Anthos Service Mesh, considera le seguenti pratiche standard durante la configurazione dei servizi:

  • Prenota un servizio univoco [spazio dei nomi, nome] sull'intero mesh.
  • Definisci un'applicazione software per servizio canonico.
    • Non raggruppare i servizi canonici tra ambienti (ad esempio, prod/stage/dev).
    • Utilizza le dashboard di Cloud Monitoring per viste di livello superiore di più servizi.
  • Pianifica una lunga durata dei servizi canonici in produzione.

Prenota un servizio univoco [spazio dei nomi, nome] sull'intero mesh

Se un servizio canonico di cui è stato eseguito il deployment in un cluster o in una regione ha lo stesso spazio dei nomi Kubernetes e lo stesso nome di servizio canonico di uno di cui è stato eseguito il deployment in un altro cluster o in un'altra regione, Anthos Service Mesh presuppone che si tratti dello stesso servizio logico.

Questo comportamento è coerente con il principio del parco risorse "identicità", secondo cui uno spazio dei nomi deve avere lo stesso significato e rappresentare la stessa entità nell'intero parco risorse.

Una sola applicazione software per servizio canonico

I servizi canonici sono pensati per rappresentare un singolo servizio logico o microservizio. Sono concepiti per includere file binari/carichi di lavoro omogenei che rappresentano la stessa applicazione software e la stessa funzione aziendale.

Sebbene sia possibile definire un servizio canonico per raggruppare diversi microservizi concettualmente diversi, le dashboard dei servizi non forniscono il loro valore completo.Le dashboard dei servizi mostrano un'aggregazione di componenti diversi che possono essere eseguiti e configurati in modo molto diverso singolarmente. Sarebbe difficile, se non impossibile, comprendere lo stato, le prestazioni e la configurazione dell'insieme.

Le seguenti non sono necessariamente cattive pratiche, ma il tuo servizio canonico potrebbe essere troppo grande se:

  • Esiste traffico di rete tra diversi carichi di lavoro all'interno di un singolo servizio canonico.
  • Un servizio canonico comprende più carichi di lavoro il cui deployment viene eseguito in diverse pianificazioni di rilascio.
  • Team diversi all'interno dell'organizzazione sono responsabili della gestione di diverse parti di un singolo servizio canonico.

Non raggruppare un servizio canonico tra ambienti

Molte organizzazioni tecnologiche impiegano diversi ambienti di deployment per garantire la qualità del software e limitare i rischi. Questi ambienti in genere includono sviluppo, test, gestione temporanea, produzione o alcuni sottoinsiemi.

Anche se esegui il deployment dello stesso servizio concettuale in ciascuno dei vari ambienti, non è consigliabile impostarli come un unico servizio canonico. Questi servizi non sono gli stessi e non rappresentano lo stesso livello di preoccupazione o attenzione operativa per la tua organizzazione.

Ad esempio, un errore in un servizio di produzione critico potrebbe causare pagine 3AM e incendi. Non vuoi avvisare nessuno se il deployment "dev" non riesce nel bel mezzo della notte. Lo stesso vale per la comprensione di prestazioni, capacità e sicurezza delle release.

Dal più semplice ma meno rigoroso al più impegnativo, ma al più potente, esistono tre modi per separare i servizi in ambienti diversi:

  1. Separa utilizzando più nomi di servizio, ad esempio payments-prod e payments-test.
  2. Separa utilizzando più spazi dei nomi, ad esempio billing-team e billing-team-test.
  3. Separa utilizzando più parchi risorse, uno per ogni ambiente.

Utilizza le dashboard personalizzate di Cloud Monitoring per aggregazioni arbitrarie

Anziché espandere artificialmente i servizi canonici in ambiti più ampi per i dati aggregati, utilizza le dashboard di Cloud Monitoring per creare contemporaneamente viste di livello superiore di più servizi logici.

I servizi canonici sono pensati per durare a lungo

Al di fuori dei casi d'uso di sviluppo, esplorazione e test, i servizi canonici devono rappresentare servizi logici globali e di alto livello. Questi servizi cambiano lentamente e tendono a durare a lungo. Questa longevità include la modifica dei nomi dei servizi. Anche se puoi modificare i loro nomi, questo influisce su metriche, SLO e log. Tuttavia, puoi modificare liberamente il campo Display name senza interruzioni.

Un nuovo servizio canonico spesso rappresenta software nuovo o aggiornato, mentre l'eliminazione di un servizio canonico rappresenta spesso il ritiro di un servizio. La tua capacità di vedere le prestazioni storiche del tuo servizio, del tuo piano e della capacità del tuo progetto dipende dal mantenimento di un'unica nozione di quel servizio in Anthos Service Mesh per la durata della sua durata.

Tieni presente che ciò è in contrasto con le risorse di livello inferiore come istanze VM, pod/deployment di Kubernetes e persino interi cluster, che spesso vengono utilizzati nell'ambito dell'aggiornamento e della manutenzione dei sistemi di produzione.

Passaggi successivi