Versione 1.13

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 esplorare molte configurazioni diverse. Per un'esperienza ottimale con le dashboard dei servizi di Anthos Service Mesh, considera le seguenti prassi standard durante la configurazione dei servizi:

  • Prenota un servizio univoco [namespace, name] in tutta la rete mesh.
  • Definisci un'applicazione software per servizio canonico.
    • Non raggruppare i servizi canonici in ambienti diversi (ad esempio, prod/stage/dev).
    • Utilizza le dashboard di Cloud Monitoring per visualizzazioni di livello superiore di più servizi.
  • Pianificare una lunga durata dei servizi canonici in produzione.

Prenota un servizio univoco [namespace, name] in tutta la rete mesh

Se un servizio canonico di cui è stato eseguito il deployment in un cluster o in un'area geografica ha lo stesso spazio dei nomi Kubernetes e il nome del servizio canonico di un altro cluster o area geografica, Anthos Service Mesh presume che si tratti dello stesso servizio logico.

Questo comportamento è coerente con il principio della flotta di "squadra di identità", in base al quale lo spazio dei nomi deve avere lo stesso significato e rappresentare la stessa entità in tutto il parco risorse.

Un'applicazione software per servizio canonico

I servizi canonici rappresentano un unico servizio logico o microservizio. Sono destinati a includere programmi binari/carichi di lavoro omogenei che rappresentano la stessa applicazione software e la stessa funzione aziendale.

Anche se puoi definire un servizio canonico per raggruppare diversi microservizi concettualmente diversi, le dashboard dei servizi non fornirebbero il loro valore completo.Le dashboard dei servizi potrebbero visualizzare un'aggregazione di componenti diversi che possono essere individualmente eseguiti e configurati in modo molto diverso. Sarebbe difficile o impossibile capire l'integrità, le prestazioni e la configurazione del dispositivo.

Le seguenti pratiche non sono necessariamente cattive, 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 di rilascio.
  • I diversi team all'interno dell'organizzazione sono responsabili dell'utilizzo di parti diverse dello stesso servizio canonico.

Non raggruppare un servizio canonico in più ambienti

Molte organizzazioni tecnologiche si avvalgono di 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 ciascuno dei tuoi vari ambienti, è sconsigliato creare un singolo servizio canonico. Questi servizi non sono uguali e non rappresentano lo stesso livello di preoccupazione o interesse operativo per la tua organizzazione.

Ad esempio, un errore in un servizio di produzione critico potrebbe causare pagine 3AM e scontri. Non vuoi avvisare nessuno se il deployment "&dev" si avvia 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 più impegnativo, ma più potente, sono disponibili tre modi per separare i servizi in diversi ambienti:

  1. Separa utilizzando più nomi di servizi, ad esempio payments-prod e payments-test.
  2. Separa utilizzando più spazi dei nomi, ad esempio billing-team e billing-team-test.
  3. Separa usando più flotte, una per ogni ambiente.

Preferisco le 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 visualizzazioni di livello superiore di più servizi logici contemporaneamente.

I servizi canonici sono progettati per essere di lunga durata

Al di fuori dei casi d'uso di sviluppo, esplorazione e test, i servizi canonici dovrebbero rappresentare servizi logici globali di alto livello. Si tratta di servizi che cambiano lentamente e tendono a durare a lungo. Questa longevità non modifica i nomi dei servizi. Puoi modificare i loro nomi, ma ciò 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 che abbandona spesso rappresenta un ritiro di servizi. La tua capacità di vedere le prestazioni storiche del tuo servizio, del tuo piano e della tua capacità di progetto dipende tutte dal mantenimento di una singola nozione di tale servizio in Anthos Service Mesh per tutta la sua durata.

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

Passaggi successivi