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 navigare in molte configurazioni diverse. Per un'esperienza ottimale con le dashboard del servizio Anthos Service Mesh, durante la configurazione dei servizi devi tenere in considerazione le seguenti pratiche standard:

Prenota un servizio unico [nomespazio, nome] in tutta la rete mesh.
Definire 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 visualizzazioni di livello superiore di più servizi.
Pianifica una durata estesa della produzione di servizi canonici.

Prenota un servizio unico [namespace, name] sull'intera rete 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 il nome del servizio canonico di un deployment in un altro cluster o regione, Anthos Service Mesh presume che si tratti dello stesso servizio logico.

Questo comportamento è coerente con il principio di parco risorse "della stessa identità", che afferma che uno spazio dei nomi deve avere lo stesso significato e rappresentare la stessa entità nell'intero parco risorse.

Un'applicazione software per servizio canonico

I servizi canonici hanno lo scopo di rappresentare un singolo servizio logico o microservizio. Hanno lo scopo di estendere programmi binari/carichi di lavoro omogenei che rappresentano la stessa applicazione software e funzione aziendale.

Sebbene tu possa definire un servizio canonico per raggruppare diversi microservizi concettualmente diversi, le dashboard dei servizi non fornirebbero il loro valore completo.Le dashboard dei servizi mostrerebbero un'aggregazione di componenti diversi che potrebbero avere prestazioni e configurazioni individuali in modo molto diverso. Sarà difficile o addirittura impossibile comprendere lo stato di integrità, prestazioni e configurazione del gruppo.

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

C'è traffico di rete tra carichi di lavoro diversi all'interno di un singolo servizio canonico.
Un servizio canonico comprende più carichi di lavoro di cui è stato eseguito il deployment in base a diverse pianificazioni delle release.
Team diversi all'interno dell'organizzazione sono responsabili dell'esecuzione di diverse parti di un singolo servizio canonico.

Non raggruppare un servizio canonico tra gli ambienti

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

Anche se esegui il deployment dello stesso servizio concettuale in ogni tuo ambiente, è prassi scorretta renderle un singolo servizio canonico. Questi servizi non sono uguali e non rappresentano lo stesso livello di preoccupazione o obiettivo operativo per la tua organizzazione.

Ad esempio, un errore in un servizio di produzione critico può causare il blocco delle pagine e del traffico di terze parti in 3AM. Non vuoi avvisare nessuno se il deployment "dev" non va a buon fine nel cuore della notte. Lo stesso vale per la comprensione di prestazioni, capacità e sicurezza della release.

Dal più semplice ma meno rigoroso a quello con il massimo impegno, ma anche il più potente, sono disponibili tre modi per separare i servizi in ambienti diversi:

Separali utilizzando più nomi di servizi, ad esempio payments-prod e payments-test.
Separa usando più spazi dei nomi, ad esempio billing-team e billing-team-test.
Separa i dati utilizzando più mezzi, uno per ciascun ambiente.

Preferenza alle dashboard personalizzate di Cloud Monitoring per le aggregazioni arbitrarie

Invece di gonfiare artificialmente i servizi canonici in ambiti più ampi per i dati aggregati, usa le dashboard di Cloud Monitoring per creare viste di livello superiore a più servizi logici contemporaneamente.

I servizi canonici sono progettati per essere longevi

Al di fuori dei casi d'uso di sviluppo, esplorazione e test, i servizi canonici devono rappresentare servizi logici di alto livello globali. Questi servizi cambiano lentamente e tendono a essere longevi. Questa longevità include lo spostamento dei nomi dei servizi. Puoi modificarne i nomi, ma la variazione influisce su metriche, SLO e log. Tuttavia, puoi regolare liberamente il campo Display name senza interruzioni.

Un nuovo servizio canonico rappresenta spesso un software nuovo o aggiornato, mentre un servizio canonico abbandona spesso rappresenta un ritiro dei servizi. La possibilità di visualizzare le prestazioni storiche del servizio, del piano e della capacità di progetto dipende dal mantenimento di una singola nozione di quel servizio in Anthos Service Mesh per l'intera durata.

Si tratta di un contrasto con le risorse di livello inferiore come istanze VM, pod/deployment di Kubernetes e perfino interi cluster, che spesso vengono e vengono inseriti nell'ambito dell'aggiornamento e della manutenzione dei sistemi di produzione.