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 consentono di navigare in molte configurazioni diverse. Per un'esperienza ottimale con le dashboard dei servizi di Cloud Service Mesh, tieni presente le seguenti pratiche standard durante la configurazione dei servizi:

  • Riserva un servizio univoco [spazio dei nomi, nome] nell'intero mesh.
  • Definisci una sola applicazione software per servizio canonico.
    • Non raggruppare i servizi canonici in più ambienti (ad esempio produzione/staging/sviluppo).
    • Utilizza le dashboard di Cloud Monitoring per visualizzazioni più generali di vari servizi.
  • Pianifica i servizi canonici in modo che durino a lungo in produzione.

Riserva 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 del servizio canonico di uno 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 di "uguaglianza" del parco risorse, che afferma che uno spazio dei nomi deve avere lo stesso significato e rappresentare la stessa entità in tutto il parco risorse.

Una sola applicazione software per servizio canonico

I servizi canonici sono pensati per rappresentare un singolo servizio logico o microservizio. Devono coprire file binari/workload omogenei che rappresentano la stessa applicazione software e la stessa funzione aziendale.

Anche se potresti definire un servizio canonico per raggruppare diversi microservizi concettualmente diversi, le dashboard dei servizi non renderebbero al meglio. Le dashboard dei servizi mostrerebbero un'aggregazione di componenti dissimili che potrebbero essere eseguiti e configurati in modo molto diverso. Sarebbe difficile o addirittura impossibile comprendere l'integrità, le prestazioni e la configurazione dell'insieme.

Quelle riportate di seguito non sono necessariamente delle pratiche errate, ma il servizio canonico potrebbe essere troppo grande se:

  • Esiste traffico di rete tra workload diversi all'interno di un singolo servizio canonico.
  • Un servizio canonico comprende più workload distribuiti in programmazioni di release diverse.
  • Diversi team all'interno dell'organizzazione sono responsabili del funzionamento di parti diverse 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 sviluppo, test, staging, produzione o un sottoinsieme di questi.

Anche se implementi lo stesso servizio concettuale in ognuno dei tuoi vari ambienti, è una pratica sconsigliata renderli un unico servizio canonico. Questi servizi non sono uguali e non rappresentano lo stesso livello di interesse o attenzione operativa per la tua organizzazione.

Ad esempio, un errore in un servizio di produzione critico potrebbe causare pagine e interruzioni alle 3 del mattino. Non vuoi avvisare nessuno se il deployment di sviluppo ("dev") non va a buon fine 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 più efficace), esistono tre modi per separare i servizi in ambienti diversi:

  1. Separali utilizzando più nomi di servizi, 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, una per ogni ambiente.

Preferisci le dashboard personalizzate di Cloud Monitoring per aggregazioni arbitrarie

Anziché gonfiare artificialmente i servizi canonici in ambiti più ampi per i dati aggregati, utilizza le dashboard di Cloud Monitoring per creare visualizzazioni più generali di vari servizi logici contemporaneamente.

I servizi canonici sono pensati per durare a lungo

Escludendo i 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 durare a lungo. Questa longevità include la mancata modifica dei nomi dei servizi. Anche se puoi modificare 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 un software nuovo o aggiornato, mentre un servizio canonico che non è più disponibile spesso rappresenta un servizio ritirato. La possibilità di visualizzare il rendimento storico del servizio, del piano e del progetto dipende dal mantenimento di una singola nozione di quel servizio in Cloud Service Mesh per tutta la sua durata.

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

Passaggi successivi