Resumen breve de las lecciones anteriores

Imagina que has pedido una pizza a través de una aplicación. Pulsa el botón "Pedir", y tu petición se envía a un microservicio que se encarga de gestionar el pedido. Ese microservicio solicita datos a otro servicio —el que maneja la lista de pizzas—. Luego entra en acción otro servicio que calcula la entrega, y después otro más para el pago. Así, una petición que parece simple pasa por muchos servicios, cada uno de los cuales puede dejar su "rastro".

Trazado distribuido (Distributed Tracing) es el proceso de seguir el "viaje" de tu petición a través de todos esos servicios. Te ayuda a entender por qué componentes pasa la petición, cuánto tiempo se tarda en cada etapa y dónde puede haber cuellos de botella.

Objetivos principales del trazado distribuido:

• Mostrar todo el recorrido de ejecución de la petición.
• Detectar puntos de congestión y operaciones lentas.
• Diagnosticar errores y fallos.
• Mejorar el rendimiento y optimizar la arquitectura.

En el contexto de microservicios, el trazado distribuido se convierte en la herramienta principal para no perderse en la compleja red de interacciones entre servicios.

Conceptos fundamentales

En el trazado distribuido hay dos conceptos clave:

• Trace (traza) – es el recorrido completo de la petición de principio a fin. Por ejemplo, una petición para formalizar un pedido puede empezar en la aplicación web y terminar en el servicio de entrega; el Trace agrupa todas esas etapas.
• Span (span) – es un paso individual dentro del Trace. Cada llamada a un microservicio, acceso a una base de datos o petición vía HTTP se considera un Span.

En la práctica esto se ve como un árbol: cada Trace contiene muchos Spans, que se dividen en acciones padre e hija.

¿Por qué hace falta el trazado distribuido?

1. Entender interacciones complejas: cuando una petición "se queda atascada", el trazado ayuda a saber exactamente dónde falló. Por ejemplo, el servicio de entrega puede retrasar la respuesta por una conexión lenta a la base de datos.
2. Reducir el tiempo de inactividad: el trazado permite identificar rápidamente qué componentes fallan y dónde están los cuellos de botella.
3. Optimizar el rendimiento: medir los tiempos de ejecución permite encontrar fragmentos de código o interacciones que necesitan mejora.
4. Aportar transparencia: si trabajas en equipo, el trazado hace el sistema más comprensible para todos. Todo lo que pasa entre servicios queda documentado.

Componentes principales del trazado distribuido

Span y Trace: el tándem que lo explica todo.

Un poco sobre Span:

• Span es una acción individual, por ejemplo, una llamada a un REST API o una operación de escritura en una base de datos.
• Cada Span tiene un identificador único que lo vincula al trace y a otros spans.

Y un poco sobre Trace:

• Trace agrupa múltiples Spans en una sola unidad.
• Trace también tiene su propio identificador único para mostrar que todos los Spans pertenecen a la misma petición.

Ejemplo:

 Trace ID: 987654321
 ├── Span ID: 1 (Customer Service - procesamiento del pedido)
 ├── Span ID: 2 (Pizza Service - verificación de disponibilidad de pizza)
 ├── Span ID: 3 (Delivery Service - cálculo de la entrega)
 └── Span ID: 4 (Payment Service - procesamiento del pago)

Observación: cada paso tiene la duración de un Span.

Herramientas para implementar trazado distribuido

Hay varias herramientas que facilitan implementar trazado en microservicios. Veamos dos de las más populares:

1. Zipkin

Zipkin es una herramienta para recopilar y visualizar datos de trazado. Permite almacenar y analizar información sobre el tiempo de ejecución de cada petición.

• Pros: Sencillez de configuración, soporte para muchos lenguajes de programación.
• Contras: Capacidades limitadas para métricas y monitoring (solo tracing).

Documentación oficial de Zipkin

2. OpenTelemetry

OpenTelemetry es un enfoque más moderno que unifica tracing, métricas y logs en una sola solución. Se puede considerar una solución universal para Observability.

• Pros: Soporte para varios estándares, mucha flexibilidad.
• Contras: Configuración más compleja en comparación con Zipkin.

Documentación oficial de OpenTelemetry

¿Cómo funciona el trazado distribuido?

El proceso se puede describir así:

1. Generación de Trace ID: cuando la petición entra al sistema, se crea un identificador único para el Trace.
2. Generación de Span ID: cada acción dentro de ese Trace recibe su propio Span ID único.
3. Propagación del contexto: Trace ID y Span ID se transmiten entre servicios mediante cabeceras HTTP.
4. Recopilación de datos: cada servicio registra datos sobre tiempos de ejecución, errores y otros eventos.
5. Análisis: todos los datos se envían a la herramienta (por ejemplo, Zipkin), donde puedes visualizar todo el proceso.

Ejemplo de interacción entre microservicios con trazado

Imagina este diagrama de interacción:

Client -> Order Service -> Inventory Service -> Payment Service

Primero Cliente envía una petición a Order Service (microservicio de gestión de pedidos). A su vez, éste llama a:

1. Inventory Service para comprobar el stock en el almacén.
2. Payment Service para confirmar el pago.

El trazado distribuido creará un árbol de peticiones que mostrará:

• Cuánto tiempo tardó Order Service.
• En qué punto la petición se retrasó (por ejemplo, en la comprobación del almacén).
• Si ocurrió un error, en qué servicio pasó.

¿Cómo ayuda esto en la vida real?

El trazado distribuido resulta especialmente útil cuando el sistema crece hasta tener decenas o cientos de microservicios. En ese escenario:

• Los errores pueden ocurrir en cualquier parte.
• Buscar manualmente el problema se vuelve imposible.
• Testear todas las interacciones es muy complicado.

El trazado se encarga de "etiquetar" cada petición y da al desarrollador toda la información necesaria para un análisis rápido.

En la siguiente lección hablaremos sobre cómo integrar Spring Boot con Zipkin y Sleuth. Para ello tomaremos varios microservicios, conectaremos las librerías de tracing y aprenderemos a "ver" las peticiones en la interfaz de Zipkin. ¡Preparaos para la práctica — será interesante!