Best practice per i servizi canonici

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

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

  • Prenota un servizio univoco [spazio dei nomi, nome] nell'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 ottenere viste di livello superiore di più servizi.
  • Fare in modo che i servizi canonici durino a lungo 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 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 presuppone che si tratti dello stesso servizio logico.

Questo comportamento è coerente con il principio del parco risorse di "identicità", secondo il quale uno spazio dei nomi dovrebbe avere lo stesso significato e rappresentare la stessa entità in tutto il parco risorse.

Un'applicazione software per servizio canonico

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

Sebbene si possa definire un servizio canonico per raggruppare diversi microservizi concettualmente diversi, le dashboard dei servizi non fornirebbero il valore completo.Le dashboard dei servizi mostrerebbero un'aggregazione di componenti diversi che potrebbero avere prestazioni e configurazioni diverse singolarmente. Sarebbe difficile, o addirittura impossibile, comprendere l'integrità, le prestazioni e la configurazione del tutto.

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 canonico comprende più carichi di lavoro di cui viene eseguito il deployment in base a pianificazioni delle release diverse.
  • Team diversi all'interno dell'organizzazione sono responsabili della gestione delle 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. ad esempio ambienti di sviluppo, test, temporanei, di produzione o sottoinsiemi.

Anche se esegui il deployment dello stesso servizio concettuale in ciascuno dei vari ambienti, è una prassi negativa trasformarli in un unico servizio canonico. Questi servizi sono diversi e non rappresentano lo stesso livello di preoccupazione operativa o di obiettivo per la tua organizzazione.

Ad esempio, un errore di un servizio di produzione critico potrebbe causare pagine di 3:00 e incendi. Non è consigliabile avvisare nessuno se il deployment "dev" non riesce nel cuore della notte. Lo stesso vale per le prestazioni, la capacità e la sicurezza delle release.

Dal più semplice ma meno rigoroso, al 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ù parchi risorse, uno per ogni ambiente.

Preferisco le dashboard personalizzate di Cloud Monitoring per aggregazioni arbitrarie

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

I servizi canonici sono pensati per essere di lunga durata

Al di fuori dei casi d'uso di sviluppo, esplorazione e test, i servizi canonici devono rappresentare servizi logici globali di alto livello. Questi servizi cambiano lentamente e tendono a essere di lunga durata. Questa longevità include la mancata modifica dei nomi dei servizi. Sebbene sia possibile modificarne i nomi, questa operazione 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 il ritiro di un servizio canonico rappresenta spesso il ritiro di un servizio. La tua capacità di vedere le prestazioni storiche 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 durata della sua attività.

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

Passaggi successivi