EA - Coupling i Kohezja

w dniu
0

Wzorce MSA - Distributed Tracing B3 propagation

w dniu

 W architekturze mikroserwisów każdy system to zbiór wielu mniejszych komponentów, które komunikują się między sobą najczęściej za pomocą żądań HTTP, wiadomości z kolejek lub gRPC. To świetnie wspiera skalowalność i elastyczność… dopóki coś nie przestanie działać.


Wtedy pojawia się pytanie:
  • Gdzie utknęło żądanie?
  • Który mikroserwis zawiódł?
  • Jak długo trwało przetwarzanie w każdym kroku?

Distributed Tracing to wzorzec, który pozwala śledzić żądania przez cały łańcuch mikroserwisów, a standard B3 umożliwia łatwą i jednolitą identyfikację każdego kroku tej podróży.

Na czym polega Distributed Tracing?

Distributed Tracing (śledzenie rozproszone) to mechanizm, który rejestruje ścieżkę żądania przez wiele usług. Każde żądanie otrzymuje unikalny identyfikator, który jest przekazywany między usługami — dzięki temu możemy odtworzyć całą trasę żądania i zmierzyć czas trwania każdego kroku.

Wprowadzenie do standardu B3

B3  to lekki, prosty do wdrożenia standard propagowania trace-id w systemach rozproszonych. Wystarczy dodać kilka nagłówków HTTP, by rozpocząć śledzenie żądań.

Kluczowe nagłówki B3:

NagłówekOpis
X-B3-TraceIdUnikalny identyfikator całego śledzenia (trace)
X-B3-SpanIdIdentyfikator konkretnego kroku (span) w ramach trace
X-B3-ParentSpanId(opcjonalnie) identyfikator nadrzędnego span
X-B3-SampledCzy trace ma być zarejestrowany (1 = tak)
X-B3-FlagsDodatkowa flaga debugowania

Przykład nagłówków B3 w żądaniu HTTP:


X-B3-TraceId: 4bf92f3577b34da6a3ce929d0e0e4736
X-B3-SpanId: 00f067aa0ba902b7
X-B3-ParentSpanId: b73a56a1d2ee0eb2
X-B3-Sampled: 1

Jak to działa w praktyce?

Schemat przepływu

Wyobraźmy sobie system z trzema mikroserwisami:


Klient → Gateway → Serwis A → Serwis B → Serwis C

Dzięki nagłówkom B3:

  1. Klient wysyła żądanie do Gateway z X-B3-TraceId.

  2. Gateway tworzy X-B3-SpanId i wysyła je do Serwisu A.

  3. Serwis A generuje swój SpanId, zachowuje ParentSpanId z Gatewaya i przekazuje trace dalej.

  4. Na końcu, Serwis C kończy trace — a wszystkie kroki są zarejestrowane.

Wizualizacja śladu (trace)

Po zebraniu wszystkich danych (np. za pomocą Jaeger, Zipkin lub Grafana Tempo), możemy zobaczyć wizualnie:


TraceId: 4bf92f3577b34da6a3ce929d0e0e4736
├── Gateway [15 ms]
│   └── Serwis A [30 ms]
│       └── Serwis B [40 ms]
│           └── Serwis C [25 ms]

Implementacja Distributed Tracing z użyciem Spring Boot i Sleuth


<!-- pom.xml -->
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>


# application.yml
spring:
  zipkin:
    base-url: http://zipkin:9411
  sleuth:
    sampler:
      probability: 1.0

Dzięki Sleuth i Zipkin aplikacja automatycznie:

  • generuje trace-id i span-id,

  • przekazuje nagłówki HTTP,

  • wysyła dane do Zipkina.

Korzyści z wdrożenia Distributed Tracing

✅ Szybsze diagnozowanie problemów
✅ Pomiar czasu odpowiedzi poszczególnych usług
✅ Widoczność zależności między mikroserwisami
✅ Identyfikacja wąskich gardeł
✅ Lepsze wsparcie operacyjne i DevOps

Wnioski i dobre praktyki

  • Zawsze przekazuj trace-id i span-id w żądaniach HTTP, gRPC i eventach.
  • Testuj czy wszystkie mikroserwisy poprawnie obsługują nagłówki B3.
  • Używaj narzędzi jak Zipkin, Jaeger lub Grafana Tempo do analizy trace’ów.
  • W systemach rozproszonych bez observability jesteś ślepy.

Podsumowanie

Wzorzec Distributed Tracing to fundament nowoczesnych, obserwowalnych systemów mikroserwisowych. W połączeniu ze standardem B3 umożliwia łatwą propagację identyfikatorów śledzenia między usługami. Dobrze wdrożony trace pozwala nie tylko znaleźć błędy, ale też optymalizować wydajność i rozumieć złożoność architektury.


Komentarze

Prześlij komentarz