Best practice per i servizi canonici

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

Canonical Services ti consente di gestire molte configurazioni diverse. Per un'esperienza ottimale con le dashboard dei servizi Cloud Service Mesh, considera le seguenti best practice standard durante la configurazione dei servizi:

  • Riserva un servizio univoco [namespace, name] per l'intero mesh.
  • Definisci un'applicazione software per servizio canonico.
    • Non raggruppare i servizi canonici in più ambienti (ad esempio prod/stage/dev).
    • Utilizza le dashboard di Cloud Monitoring per visualizzare una panoramica più ampia di più servizi.
  • Pianifica che i servizi canonici siano di lunga durata in produzione.

Riserva un servizio univoco [namespace, name] per l'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 un servizio di cui è stato eseguito il deployment in un altro cluster o in un'altra regione, Cloud Service Mesh presume che si tratti dello stesso servizio logico.

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

Un'applicazione software per servizio canonico

I servizi canonici sono pensati per rappresentare un singolo servizio logico o un singolo microservice. Sono destinati a includere 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 ne fornirebbero il valore completo.Le dashboard dei servizi mostrerebbero un'aggregazione di componenti diversi che potrebbero funzionare e essere configurati in modo molto diverso singolarmente. Sarebbe difficile o addirittura impossibile comprendere l'integrità, le prestazioni e la configurazione dell'intero sistema.

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

  • Esiste traffico di rete tra carichi di lavoro diversi all'interno di un singolo servizio Canonical.
  • Un servizio Canonical è costituito da più carichi di lavoro di cui viene eseguito il deployment su diversi programmi di rilascio.
  • Diversi team all'interno della tua organizzazione sono responsabili del funzionamento di diversi componenti di un singolo servizio canonico.

Non raggruppare un servizio canonico in più ambienti

Molte organizzazioni tecnologiche utilizzano più ambienti di deployment per garantire la qualità del software e limitare i rischi. Questi ambienti includono più spesso dev, test, staging, prod o qualche sottoinsieme.

Anche se implementi lo stesso servizio concettuale in ciascuno dei tuoi vari ambienti, è una cattiva prassi creare un unico servizio canonico. Questi servizi non sono uguali e non rappresentano lo stesso livello di attenzione o preoccupazione operativa per la tua organizzazione.

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

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

  1. Separali utilizzando più nomi di servizio, ad esempio payments-prod e payments-test.
  2. Separali utilizzando più namespaces, ad esempio billing-team e billing-team-test.
  3. Separali utilizzando più flotte, una per ogni ambiente.

Preferisci le dashboard personalizzate di Cloud Monitoring per aggregazioni arbitrarie

Anziché aumentare artificialmente i servizi canonici in ambiti più ampi per i dati aggregati, utilizza le dashboard di monitoraggio cloud per creare contemporaneamente visualizzazioni di livello superiore di più servizi logici.

I servizi canonici sono progettati per durare a lungo

A parte i casi d'uso di sviluppo, esplorazione e test, i servizi canonici devono rappresentare servizi logici globali di alto livello. Questi servizi sono soggetti a variazioni lente e tendono ad avere una lunga durata. Questa longevità include la mancata modifica dei nomi dei servizi. Sebbene tu possa modificarne i nomi, questa operazione influisce su metriche, SLO e log. Tuttavia, puoi modificare liberamente il campo Display name senza interruzione.

Un nuovo servizio canonico spesso rappresenta un software nuovo o aggiornato, mentre un servizio canonico che non sarà più disponibile spesso rappresenta il ritiro di un servizio. La tua capacità di visualizzare il rendimento storico del servizio, del piano e della capacità del progetto dipende dal mantenimento di un'unica nozione di quel servizio in Cloud Service Mesh per tutta la sua durata.

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

Passaggi successivi