Quando un'applicazione viene riscritta per utilizzare i microservizi, il numero di componenti ed endpoint coinvolti in una transazione di un singolo utente aumenta. Pertanto, l'osservabilità è fondamentale per far funzionare in modo affidabile i servizi utente. Questa architettura di riferimento mostra come acquisire informazioni di traccia sulle applicazioni di microservizi utilizzando OpenTelemetry e Cloud Trace.
Questo documento è rivolto a sviluppatori, SRE e DevOps Engineer che vogliono comprendere le nozioni di base del tracciamento distribuito e che vogliono applicare questi principi ai propri servizi per migliorarne l'osservabilità.
Architettura
Il seguente diagramma mostra l'architettura di un'applicazione che implementa questa architettura.
Come illustrato nel diagramma precedente, questa architettura include due cluster GKE. Esegui il deployment di un'applicazione in ciascuno dei cluster. Il traffico utente viene inviato all'applicazione frontend sul cluster frontend. Il pod frontend sul cluster frontend comunica con il pod di backend sul cluster di backend. Il pod di backend chiama un endpoint API esterno.
I dati di osservabilità vengono esportati in Cloud Trace, che tiene traccia del modo in cui le richieste si propagano nelle applicazioni.
Note sul layout
Per i servizi eseguiti su Kubernetes, puoi utilizzare un mesh di servizi come Istio per abilitare il tracciamento distribuito del traffico tra servizi senza bisogno di strumentazione dedicata. Tuttavia, potresti avere uno dei seguenti requisiti:
- Vuoi avere più controllo sulle tracce rispetto a quello fornito da Istio.
- Potrebbe essere necessario acquisire gli elementi interni dell'applicazione nelle informazioni di traccia.
- Potrebbe essere necessario tracciare il codice che non è in esecuzione su Kubernetes.
Per questi casi d'uso, puoi utilizzare OpenTelemetry, una libreria open source che può aggiungere strumentazione alle applicazioni di microservizi distribuiti per raccogliere tracce, metriche e log in una vasta gamma di lingue, piattaforme e ambienti.
Informazioni su tracce, intervalli e contesto
Il concetto di tracciamento distribuito è descritto nel documento di ricerca di Daper pubblicato da Google. Come descritto nell'articolo, il seguente diagramma mostra cinque sezioni in una traccia.
Una trace è il totale delle informazioni che descrivono il modo in cui un sistema distribuito risponde alla richiesta di un utente. Le tracce sono composte da intervalli, in cui ogni intervallo rappresenta una coppia specifica di richiesta e risposta coinvolta nella gestione della richiesta dell'utente. L'intervallo padre descrive la latenza osservata dall'utente finale. Ciascuno degli intervalli secondari descrive come è stato chiamato e risposto un particolare servizio nel sistema distribuito, con informazioni sulla latenza acquisite per ciascuno.
Il diagramma mostra una singola richiesta di frontend che effettua due richieste di backend. La seconda chiamata di backend richiede due chiamate helper per essere completate. Ogni chiamata è etichettata con l'ID intervallo e l'ID dell'intervallo padre.
Una sfida del tracciamento nei sistemi distribuiti è che le informazioni sulla richiesta di frontend originale non vengono trasferite automaticamente o intrinsecamente quando vengono effettuate richieste successive a vari servizi di backend.
Con alcuni strumenti (ad esempio, nel linguaggio Go), puoi effettuare richieste con il contesto, ovvero l'indirizzo IP e le credenziali del cluster. OpenTelemetry estende il concetto di contesto per includere il contesto span, il che significa che ulteriori informazioni vengono caricate nell'intestazione HTTP. Le informazioni sull'intervallo padre possono quindi essere incluse in ogni richiesta successiva. Puoi aggiungere intervalli figlio per comporre la traccia complessiva, in modo da poter vedere in che modo la richiesta dell'utente ha attraversato il sistema e alla fine è stata restituita all'utente.
Deployment
Per eseguire il deployment di questa architettura, consulta Eseguire il deployment del tracciamento distribuito per osservare la latenza dei microservizi.
Passaggi successivi
- Scopri di più su OpenTelemetry.
- Scopri di più sulle funzionalità DevOps correlate a questa architettura:
- Esegui il controllo rapido DevOps per comprendere la tua posizione rispetto al resto del settore.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.