Best practice per i servizi canonici

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

I servizi canonici ti consentono di esplorare molti configurazioni diverse. Per un'esperienza ottimale con Cloud Service Mesh Service per le dashboard, considera le seguenti pratiche standard durante la configurazione Google Cloud:

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

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

Se un servizio canonico di cui è stato eseguito il deployment in un cluster o in una regione ha lo stesso Kubernetes e il nome del servizio canonico come deployment in un altro cluster regione Cloud Service Mesh, Cloud Service Mesh presuppone che si tratti dello stesso servizio logico.

Questo comportamento è coerente con principio della flotta di "identicità", che indica che uno spazio dei nomi deve avere lo stesso significato e rappresentare nell'intero parco risorse.

Importante: assicurati che servizi logicamente diversi (ad esempio, servizi di pagamento l'API per la contabilità e l'API per le transazioni di pagamento) non utilizzano lo stesso [spazio dei nomi, nome] coppia (ad es. "payments/api") perché si uniscono inavvertitamente in una dashboard del servizio. Tieni presente che questa unione concettuale avviene anche tra regioni confini. Inoltre, la funzionalità dei servizi potrebbe essere interessata.

Un'applicazione software per servizio canonico

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

Puoi definire un servizio canonico per raggruppare diversi concettualmente microservizi diversi insieme, le dashboard dei servizi non forniscono full value.Le dashboard dei servizi mostrerebbero un'aggregazione di dati componenti, che possono avere un rendimento individuale e una configurazione molto diversa. Sarebbe difficile, se non addirittura impossibile, comprendere lo stato di salute, e la configurazione dell'intero insieme.

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

• C'è traffico di rete tra diversi carichi di lavoro all'interno di un singolo Servizio canonico.
• Un servizio di canonicalizzazione comprende più carichi di lavoro di cui viene eseguito il deployment in base a diversi programmi di rilascio.
• I diversi team all'interno dell'organizzazione sono responsabili diverse parti 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 spesso sviluppo, test, di gestione temporanea, produzione o alcuni sottoinsiemi.

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 di un servizio di produzione critico può causare la generazione di pagine 3AM e scontri a fuoco. 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 rilasciare la sicurezza.

Importante: consigliamo di separare i servizi nei vari ambienti in servizi canonici separati. Puoi farlo in tre modi.

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ù spazi dei nomi, ad esempio billing-team e billing-team-test.
3. Separali utilizzando più flotte, una per ogni ambiente.

Preferisco 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 lenti e tendono a durare a lungo. 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 software nuovo o aggiornato, mentre Il ritiro del servizio canonico spesso rappresenta il ritiro di un servizio. Il tuo Possibilità di vedere le prestazioni storiche del servizio, del piano e del progetto dipendono tutti dal mantenimento di un'unica nozione di servizio Cloud Service Mesh per tutta la durata della sua attività.

Da notare che questa è in contrasto con le risorse di livello inferiore come le istanze VM, Kubernetes pod/deployment e persino interi cluster, che spesso vengono l'aggiornamento e la manutenzione dei sistemi di produzione.

Passaggi successivi

• Scopri di più sui servizi canonici.
• Scopri come definire un servizio canonico.