DEV Community: Andrzej Korcz

Kafka kontra RabbitMQ

Andrzej Korcz — Sat, 05 Oct 2024 17:13:21 +0000

Apache Kafka i RabbitMQ to dwa popularne systemy kolejek wiadomości, ale mają różne podejścia do przetwarzania danych i nadają się do różnych przypadków użycia. Oto ich kluczowe różnice i wskazówki, kiedy wybrać każdy z nich:

Apache Kafka

Model przetwarzania: Kafka to system strumieniowy oparty na przesyłaniu zdarzeń (event streaming). Każda wiadomość jest zapisywana w partycji, a konsumenci mogą odczytywać te wiadomości w sposób uporządkowany. Kafka bardziej przypomina rozproszoną bazę danych wiadomości, która umożliwia "replay" – czyli ponowne odczytywanie tych samych danych.
Szybkość i wydajność: Kafka jest zoptymalizowana pod kątem wydajności i wysokiej przepustowości, dobrze nadaje się do przetwarzania dużych ilości danych w czasie rzeczywistym (np. logi, dane o zdarzeniach, strumienie danych z IoT). Może obsługiwać miliony wiadomości na sekundę.
Trwałość: Kafka przechowuje dane na dysku, dzięki czemu mogą być one dostępne przez długi czas, nawet po ich przetworzeniu. Konsumenci mogą odczytywać wiadomości w dowolnym momencie, od konkretnego punktu w historii.
Skalowalność: Kafka została zaprojektowana do pracy w rozproszonym środowisku i łatwo skalować ją na wiele węzłów (serwerów), co sprawia, że dobrze radzi sobie w dużych systemach rozproszonych.
Zastosowania: Najlepsza do strumieniowania danych w czasie rzeczywistym, analizy danych, systemów logów i dużych systemów rozproszonych, gdzie priorytetem jest przepustowość i trwałość.

RabbitMQ

Model przetwarzania: RabbitMQ to tradycyjny broker wiadomości (message broker) oparty na modelu kolejek (publish-subscribe lub point-to-point). Przesyła wiadomości od producentów do konsumentów, a wiadomości są usuwane po ich przetworzeniu. RabbitMQ oferuje różne zaawansowane wzorce routingu wiadomości (direct, topic, fanout).
Szybkość i wydajność: RabbitMQ dobrze radzi sobie z przetwarzaniem mniejszych ilości danych, szczególnie w scenariuszach wymagających niskiej latencji (opóźnienia). Jest bardziej zoptymalizowany pod kątem pracy w środowiskach o wysokiej dostępności (HA).
Trwałość: RabbitMQ oferuje przechowywanie wiadomości w pamięci lub na dysku, ale zazwyczaj wiadomości są konsumowane i usuwane natychmiast po dostarczeniu do konsumenta.
Skalowalność: RabbitMQ może być skalowany w poziomie, ale nie na taką skalę jak Kafka. Może obsługiwać wiele węzłów, ale nie radzi sobie tak dobrze z ekstremalnymi przypadkami dużego ruchu.
Zastosowania: Idealny do obsługi klasycznych zadań w systemach mikroserwisowych, w których kluczowa jest niezawodna komunikacja między usługami (request-response, task queues), a także w systemach wymagających zaawansowanego routingu wiadomości.

Kiedy wybrać Kafka:

Gdy potrzebujesz przetwarzania dużej ilości danych w czasie rzeczywistym.
Gdy zależy Ci na wysokiej przepustowości i niskich opóźnieniach.
Gdy chcesz przechowywać historię zdarzeń i móc je ponownie przetwarzać.
Gdy system wymaga skalowania na dużą skalę.

Kiedy wybrać RabbitMQ:

Gdy potrzebujesz zaawansowanego routingu wiadomości (np. publish-subscribe, fanout, topic routing).
Gdy projekt wymaga prostszej i bardziej klasycznej architektury systemu kolejek wiadomości.
Gdy zależy Ci na niskiej latencji oraz niezawodnej komunikacji między mikroserwisami lub aplikacjami.
Gdy ilość danych nie jest tak wielka jak w przypadku rozbudowanych systemów strumieniowych, ale kluczowa jest spójność i pewność dostarczenia wiadomości.

Podsumowując, Kafka jest idealna do strumieniowania dużych ilości danych i zastosowań wymagających wysokiej przepustowości, natomiast RabbitMQ lepiej nadaje się do klasycznych zastosowań związanych z wymianą wiadomości i tasków, gdzie ważna jest elastyczność routingu i prostota integracji.

Dwa popularne standardy propagacji śledzenia komunikatów.

Andrzej Korcz — Fri, 04 Oct 2024 13:17:32 +0000

1. W3C Trace Context (standard propagacji śledzenia przyjęty przez W3C):

Ten standard został wprowadzony, aby zapewnić jednolity format propagacji kontekstu śledzenia między różnymi systemami, serwisami i narzędziami. Działa niezależnie od implementacji i ma na celu ujednolicenie formatu w różnych środowiskach. W3C Trace Context składa się z dwóch kluczowych nagłówków:

traceparent: To główny nagłówek w W3C Trace Context. Zawiera najważniejsze informacje o kontekście śledzenia:
- Wersja: Numer wersji standardu (obecnie 00).
- Trace ID: Globalny unikalny identyfikator całego śledzenia (np. cała ścieżka od producenta do konsumenta).
- Parent ID (Span ID): Identyfikator spana reprezentującego bezpośredniego rodzica w śledzeniu.
- Flagi: Informacje na temat próbkowania (czy dany span ma być śledzony i przesyłany do systemu zbierającego).

Przykład nagłówka traceparent:

  traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

Gdzie:

00 to wersja.
4bf92f3577b34da6a3ce929d0e0e4736 to Trace ID.
00f067aa0ba902b7 to Parent ID (Span ID).
01 to flagi (bit flagi próbkowania, gdzie 01 oznacza, że span ma być śledzony).
- tracestate: To dodatkowy nagłówek używany w W3C Trace Context. Zawiera bardziej zaawansowane informacje, które mogą być specyficzne dla dostawcy systemu śledzenia (np. dodatkowe dane potrzebne narzędziu śledzącemu). Pozwala na propagowanie dodatkowych metadanych związanych z śledzeniem, np. priorytety lub informacje specyficzne dla narzędzia (np. Jaeger, Zipkin).

Przykład:

  tracestate: congo=t61rcWkgMzE

2. B3 Propagation (standard używany przez Zipkin):

B3 to inny, popularny standard propagacji kontekstu śledzenia, stosowany głównie w systemie Zipkin, ale obsługiwany także przez inne tracery, takie jak Jaeger. B3 działa w sposób nieco prostszy niż W3C Trace Context i składa się z kilku nagłówków:

x-B3-TraceId: To globalny identyfikator śledzenia (trace). Odpowiada za identyfikację całego cyklu śledzenia, podobnie jak Trace ID w W3C. Ten identyfikator jest unikalny dla całego śledzenia i pozwala połączyć wszystkie spany w jeden trace.

Przykład:

  x-B3-TraceId: 4bf92f3577b34da6a3ce929d0e0e4736

x-B3-ParentSpanId: Identyfikator rodzica aktualnego spana. Ten nagłówek zawiera ID spana, który bezpośrednio poprzedza obecny span. Jest on podobny do Parent ID w W3C Trace Context.

Przykład:

  x-B3-ParentSpanId: 00f067aa0ba902b7

x-B3-SpanId: To identyfikator spana w ramach śledzenia. Każdy span w trace ma swój unikalny identyfikator, który odróżnia go od innych spanów w danym trace. Jest podobny do Parent ID w W3C Trace Context, ale dotyczy konkretnego spana, a nie rodzica.

Przykład:

  x-B3-SpanId: 00f067aa0ba902b7

x-B3-Sampled: To flaga określająca, czy dany span (i cały trace) powinien być próbkowany i wysyłany do systemu zbierającego. Możliwe wartości to:
- 1 oznacza, że span ma być śledzony.
- 0 oznacza, że span nie będzie śledzony.

Przykład:

  x-B3-Sampled: 1

Podział nagłówków:

W3C Trace Context:
- traceparent
- tracestate
B3 Propagation (Zipkin):
- x-B3-TraceId
- x-B3-ParentSpanId
- x-B3-SpanId
- x-B3-Sampled

Jakie są różnice między tymi standardami?

W3C Trace Context jest bardziej nowoczesnym, ujednoliconym standardem wspieranym przez organizację W3C, co oznacza, że jest neutralny w stosunku do narzędzi do śledzenia (np. Jaeger, Zipkin). Umożliwia bardziej elastyczną propagację informacji o śledzeniu, w tym dostarczanie zaawansowanych metadanych poprzez tracestate.
B3 jest starszym standardem propagacji, który został wprowadzony przez Zipkin. Jest prostszy i używa osobnych nagłówków dla każdego elementu kontekstu śledzenia (trace ID, span ID itd.), zamiast jednej złożonej struktury, jak w W3C Trace Context.

Co to oznacza dla Twojej aplikacji?

Twoja aplikacja aktualnie obsługuje zarówno W3C Trace Context (traceparent, tracestate), jak i B3 (x-B3-*).
W wielu przypadkach, systemy takie jak Jaeger, Zipkin, lub OpenTelemetry potrafią obsługiwać oba standardy, ale powinno się wybrać jeden spójny standard propagacji. Korzystanie z obu może wprowadzać zamieszanie i niespójności, zwłaszcza gdy różne systemy interpretują nagłówki inaczej.
Jeśli chcesz mieć pełną kontrolę nad śledzeniem, najlepiej jest zdecydować się na jeden standard (najczęściej rekomendowany jest W3C Trace Context, ponieważ jest to standard uznawany przez W3C i ma szersze wsparcie).

Jeśli twój system korzysta z różnych narzędzi do śledzenia (np. Jaeger, Zipkin) i musisz wspierać oba standardy, konieczne może być skonfigurowanie odpowiednich integracji lub middleware, które będą konwertować nagłówki między tymi standardami.

Łańcuch zależności wyjątków.

Andrzej Korcz — Thu, 03 Oct 2024 18:03:08 +0000

Łańcuch zależności wyjątków (ang. exception chaining) to koncepcja programistyczna stosowana głównie w językach takich jak Java, która pomaga zachować pełny kontekst błędu poprzez połączenie kilku wyjątków w jeden ciąg. Oznacza to, że jeden wyjątek może być „powiązany” z innym, co pozwala śledzić całą sekwencję zdarzeń, które doprowadziły do danego błędu.

Aby to lepiej zrozumieć, warto rozważyć kilka elementów:

1. Cel łańcucha wyjątków

Wyjątki mogą występować na różnych poziomach aplikacji — od niskopoziomowych operacji (np. błąd odczytu pliku) do bardziej abstrakcyjnych problemów (np. błędy biznesowe). Dzięki łańcuchowi zależności wyjątków możemy:

Zachować oryginalny wyjątek (czyli przyczynę pierwotną),
Owinąć go nowym, bardziej specyficznym wyjątkiem (bardziej związanym z kontekstem aplikacji),
Uzyskać pełną historię tego, co się wydarzyło od początkowego błędu do końca.

2. Jak to działa?

W praktyce, podczas obsługi wyjątku można przekazać oryginalny wyjątek (tzw. cause) jako argument do nowego wyjątku. Umożliwia to przekazanie informacji o pierwotnym błędzie i dodanie dodatkowego kontekstu. Zasadniczo wygląda to tak:

   try {
       // Kod, który może wygenerować wyjątek
   } catch (IOException e) {
       throw new CustomException("Błąd podczas przetwarzania pliku", e);
   }

W tym przykładzie IOException jest pierwotnym wyjątkiem, który zostaje złapany. Następnie rzucamy nowym wyjątkiem CustomException, który zawiera wiadomość „Błąd podczas przetwarzania pliku” oraz odniesienie do oryginalnego wyjątku IOException. Dzięki temu możemy śledzić cały łańcuch błędów.

3. Dlaczego to jest ważne?

Utrzymanie kontekstu: Zamiast "zgubić" pierwotny wyjątek, możemy go przekazać dalej, co jest przydatne, gdy chcemy dowiedzieć się, co dokładnie spowodowało problem.
Lepsze debugowanie: Dzięki łańcuchowi wyjątków, gdy aplikacja wyrzuci nowy wyjątek, jesteśmy w stanie śledzić całą sekwencję wyjątków (np. z poziomu logów czy stack trace), co ułatwia diagnozowanie problemu.

4. Hierarchia wyjątków

W Javie wszystkie wyjątki dziedziczą od klasy Throwable. Każdy wyjątek ma pole cause, które przechowuje oryginalny wyjątek (jeśli został podany). W przypadku wystąpienia wyjątku możemy sprawdzić całą hierarchię zależności wyjątków, analizując stos wywołań (ang. stack trace).

Klasa Throwable zawiera metodę getCause(), która zwraca wyjątek, który spowodował bieżący problem. Jeśli nie ma przyczyny, zwracany jest null.
Konstruktor Throwable (oraz klas pochodnych takich jak Exception czy RuntimeException) pozwala na przekazanie „przyczyny” poprzez drugi argument:
```
 public Throwable(String message, Throwable cause)
```

5. Spring Boot i łańcuch wyjątków

W Spring Boot, łańcuch zależności wyjątków jest szczególnie przydatny w kontekście aplikacji webowych. Jeśli na przykład aplikacja rzuci wyjątek na poziomie bazy danych (np. DataAccessException), można przekazać ten wyjątek dalej, a Spring Boot może go automatycznie przetworzyć i zwrócić odpowiedni komunikat HTTP do klienta.

Przykład w Spring Boot:

   @Service
   public class FileService {
       public void processFile(String fileName) {
           try {
               // Operacje na pliku
           } catch (IOException e) {
               throw new FileProcessingException("Błąd przetwarzania pliku: " + fileName, e);
           }
       }
   }

Jeśli IOException zostanie wyrzucony, FileProcessingException go „owinie” i doda dodatkowe informacje. Łańcuch ten można przekazać dalej do kontrolera, który obsługuje wyjątki w aplikacji webowej.

6. Stack trace i debugowanie

Kiedy aplikacja wyrzuci wyjątek, z którym łańcuch wyjątków jest powiązany, możemy zauważyć w stack trace wszystkie przyczyny błędów. Na przykład:

   Exception in thread "main" CustomException: Błąd podczas przetwarzania pliku
    at com.example.FileProcessor.processFile(FileProcessor.java:25)
    at com.example.Main.main(Main.java:10)
   Caused by: java.io.IOException: Plik nie istnieje
    at com.example.FileProcessor.readFile(FileProcessor.java:15)
    ... 1 more

W powyższym przykładzie widzimy, że CustomException został wyrzucony z powodu IOException. Takie informacje są kluczowe w diagnozowaniu problemów w aplikacji.

Podsumowanie

Łańcuch zależności wyjątków w Javie (i w Spring Boot) pozwala na lepsze śledzenie źródeł błędów, dodając do nich dodatkowy kontekst i umożliwiając bardziej precyzyjne debugowanie. Jest to niezwykle przydatne w aplikacjach o większej złożoności, gdzie wyjątki mogą pojawiać się na różnych poziomach abstrakcji.

Korzyści z użycia wirtualnych wątków w aplikacji Spring Boot

Andrzej Korcz — Tue, 01 Oct 2024 07:10:28 +0000

Korzyści z użycia wirtualnych wątków w aplikacji Spring Boot są bardziej wyraźne w sytuacjach wymagających intensywnej współbieżności i asynchroniczności. Oto omówienie zalet i przykładów, gdzie wirtualne wątki mają sens:

Zalety Wirtualnych Wątków:

Obsługa Wysokiej Liczby Współbieżnych Połączeń:
- Tradycyjne wątki w Javie są zasobożerne — każde stworzenie wątku systemowego wymaga pamięci i zasobów CPU. Przy dużej liczbie jednoczesnych połączeń (np. setki tysięcy żądań HTTP do serwera) system zaczyna się przeciążać. Wirtualne wątki są znacznie lżejsze, ponieważ JVM może tworzyć miliony wirtualnych wątków, które zarządzane są w bardziej efektywny sposób.
- W kontekście aplikacji webowych lub mikroserwisowych, które często obsługują tysiące jednoczesnych zapytań (HTTP, zapytania do bazy danych, zewnętrzne API), wirtualne wątki pozwalają na łatwiejsze skalowanie.
Efektywniejsze Przetwarzanie I/O:
- W aplikacjach Spring Boot wiele operacji opiera się na I/O (wejście-wyjście), np. odpytywanie baz danych, komunikacja z zewnętrznymi serwisami przez API, odczyt/zapis plików, przesyłanie danych po sieci. Operacje I/O są naturalnie blokujące i czekanie na odpowiedź może zablokować tradycyjny wątek systemowy.
- Wirtualne wątki pozwalają na bardziej efektywne zarządzanie operacjami I/O, ponieważ mogą być łatwo zawieszane i wznawiane, gdy dane są dostępne, bez blokowania zasobów systemowych (np. CPU, pamięci).
Prostszy Model Programowania:
- Tradycyjnie w Javie do obsługi asynchronicznych operacji używało się wątków, puli wątków lub bardziej skomplikowanych mechanizmów, takich jak CompletableFuture, czy programowanie reaktywne (Reactor, RxJava). Chociaż te podejścia działają, mogą wprowadzać pewną złożoność i trudności z zarządzaniem współbieżnością.
- Dzięki wirtualnym wątkom, programiści mogą używać bardziej intuicyjnych konstrukcji blokujących (takich jak Thread.sleep() czy klasyczne I/O), a JVM sam optymalizuje zarządzanie wątkami. Zyskujemy więc prostszy model programowania, zachowując efektywność współbieżności.
Lepsza Skalowalność Aplikacji:
- W przypadku serwisów mikroserwisowych czy serwerów HTTP, wirtualne wątki pozwalają na większą skalowalność bez konieczności przepisania aplikacji na programowanie reaktywne. Umożliwia to łatwe zwiększenie liczby jednoczesnych połączeń (przepustowości) przy mniejszym zużyciu zasobów.

Przykłady Użycia Wirtualnych Wątków:

Aby lepiej zrozumieć, gdzie wirtualne wątki mogą mieć sens, przyjrzyjmy się bardziej realistycznym scenariuszom:

1. Serwisy Mikroserwisowe (HTTP i Bazy Danych)

Załóżmy, że mamy serwis mikroserwisowy, który obsługuje wiele zapytań HTTP, a każde z tych zapytań odpytywało bazę danych oraz zewnętrzny serwis przez API. W takim przypadku tradycyjne wątki byłyby blokowane podczas oczekiwania na odpowiedzi z bazy danych oraz z zewnętrznego serwisu, co zmniejsza wydajność.

W przypadku wirtualnych wątków można napisać kod w sposób blokujący (czyli używać klasycznych operacji I/O), ale JVM nie będzie blokował systemowych zasobów, gdy wątek czeka na dane z bazy lub z sieci.

Przykład:

@GetMapping("/data")
public String fetchData() {
    try {
        // Wirtualny wątek pobiera dane z bazy
        String dbResult = databaseService.queryData(); // Operacja blokująca (I/O)

        // Wirtualny wątek pobiera dane z zewnętrznego serwisu
        String apiResult = externalApiService.fetchData(); // Operacja blokująca (I/O)

        return "Wynik: " + dbResult + ", " + apiResult;
    } catch (Exception e) {
        return "Błąd podczas przetwarzania danych!";
    }
}

W tym przykładzie:

Tradycyjnie użycie blokujących zapytań do bazy danych i zewnętrznych API mogłoby wymagać reaktywnego programowania lub specjalnego zarządzania wątkami.
Wirtualne wątki pozwalają na blokujący kod bez wydajnościowych kompromisów — można efektywnie skalować aplikację bez dodawania złożoności.

2. Asynchroniczne Pobieranie Danych z Kilku Źródeł

Często w aplikacjach webowych konieczne jest pobranie danych z kilku różnych źródeł (np. API, bazy danych, innych serwisów) w odpowiedzi na jedno zapytanie użytkownika.

Z wirtualnymi wątkami możemy łatwo uruchomić te zapytania asynchronicznie, korzystając z prostego modelu wątków, bez potrzeby używania bardziej skomplikowanych mechanizmów jak CompletableFuture.

@GetMapping("/fetch-multiple")
public String fetchMultipleSources() {
    Executor executor = Executors.newVirtualThreadPerTaskExecutor();

    var future1 = CompletableFuture.supplyAsync(() -> service1.getData(), executor);
    var future2 = CompletableFuture.supplyAsync(() -> service2.getData(), executor);

    // Czekamy na wyniki obu operacji
    String result1 = future1.join();
    String result2 = future2.join();

    return "Wyniki: " + result1 + " oraz " + result2;
}

Tutaj:

Każde zapytanie do serwisów (service1 i service2) uruchamiane jest w osobnym wirtualnym wątku.
W przypadku aplikacji mikroserwisowych, gdzie aplikacja często komunikuje się z wieloma zewnętrznymi serwisami, takie rozwiązanie pozwala na prostą obsługę dużej liczby równoczesnych połączeń, bez obciążenia zasobów systemu.

Podsumowanie

Wirtualne wątki w Javie 21 przynoszą ogromne korzyści w aplikacjach, które są mocno współbieżne i zależne od operacji I/O. Dzięki nim można:

Skalować aplikację do obsługi większej liczby jednoczesnych żądań przy niższym zużyciu zasobów.
Upraszczać kod współbieżny (mniej kodu reaktywnego lub zaawansowanego zarządzania wątkami).
Używać prostszego modelu programowania (blokującego), ale z efektywnością asynchronicznego wykonania.

Wirtualne wątki umożliwiają łatwe tworzenie aplikacji webowych czy mikroserwisów, które mogą obsługiwać więcej użytkowników i połączeń bez konieczności pisania złożonego kodu.

Różnice między bibliotekami a starterami w Spring Boot

Andrzej Korcz — Sat, 28 Sep 2024 11:00:11 +0000

Biblioteki Spring Boot Starter to specjalne, predefiniowane pakiety w ekosystemie Spring, które mają na celu uproszczenie zarządzania zależnościami i konfiguracją dla różnych funkcjonalności. Ich zadaniem jest zapewnienie gotowej paczki zależności i podstawowej konfiguracji dla konkretnych scenariuszy, takich jak dostęp do bazy danych, obsługa aplikacji webowych czy logowanie.

Różnica między starterami a zwykłymi bibliotekami, polega głównie na celu i strukturze. Wyjaśnię to bardziej szczegółowo:

1. Co to są biblioteki typu "starter"?

Startery Spring Boot to specjalne pakiety, które zawierają predefiniowane zestawy zależności niezbędne do implementacji określonej funkcji. Są to głównie paczki ułatwiające życie programistom, pozwalając na szybkie dodanie odpowiednich bibliotek do projektu i eliminując potrzebę ręcznego zarządzania wieloma zależnościami.

Na przykład:

spring-boot-starter-web to starter odpowiedzialny za aplikacje webowe. Zawiera wszystkie niezbędne zależności, takie jak Spring MVC, Tomcat jako domyślny kontener aplikacji, oraz inne kluczowe biblioteki do tworzenia aplikacji webowych.
spring-boot-starter-data-jpa to starter do obsługi JPA (Java Persistence API), który automatycznie dodaje zależności do Hibernate, Spring Data JPA oraz baz danych.

W porównaniu do zwykłej biblioteki, starter:

Nie oferuje bezpośrednio logiki biznesowej lub narzędzi, ale dostarcza zestaw zależności, które są typowo potrzebne dla konkretnego rodzaju aplikacji.
Startery mają na celu ułatwienie konfiguracji oraz szybszy start w pracy z różnymi komponentami Spring Boot.

2. Różnica między starterami a zwykłą biblioteką

Przykładowo biblioteka (np. StringUtils) jest zazwyczaj prostą biblioteką narzędziową, która dostarczała konkretne funkcje (metody) do pracy z ciągami znaków. W przeciwieństwie do tego, startery Spring Boot są bardziej zestawami zależności i konfiguracji, a nie konkretnymi implementacjami logiki.

Kluczowe różnice:

Cel:
- Zwykła biblioteka (jak nasz przykład StringUtils) dostarcza pewne narzędzia lub logikę biznesową do użycia w aplikacjach.
- Starter dostarcza zestaw zależności i konfiguracji, potrzebnych do korzystania z określonej technologii lub komponentu Spring Boot.
Zarządzanie zależnościami:
- W przypadku zwykłej biblioteki sam definiujesz jej zależności i konfigurację.
- Starter automatycznie dodaje wszystkie niezbędne zależności oraz domyślne konfiguracje, eliminując konieczność ręcznego zarządzania nimi.
Użyteczność:
- Biblioteka dostarcza konkretne funkcje lub klasy do użycia w kodzie (np. StringUtils).
- Starter dostarcza komponenty, konfiguracje i zależności, które są używane przez Spring Boot do automatycznego zarządzania komponentami aplikacji (np. konfiguracja bazy danych, systemu logowania).

3. Jak stworzyć własny starter?

Możesz stworzyć własny starter Spring Boot, który będzie działał podobnie jak oficjalne startery. Taki starter będzie zawierał gotową paczkę zależności i może dodać domyślną konfigurację dla innych projektów.

Przykład tworzenia własnego startera:

Załóżmy, że chcemy stworzyć starter, który automatycznie dodaje naszą klasę StringUtils oraz pewne domyślne zależności. Poniżej pokazuję, jak to zrobić.

Krok 1: Struktura projektu

Struktura projektu wygląda podobnie jak w przypadku zwykłej biblioteki, ale z tą różnicą, że starter będzie zawierał domyślną konfigurację.

Krok 2: Konfiguracja `build.gradle`

plugins {
    id 'java'
    id 'maven-publish'
}

group = 'com.example'
version = '1.0.0'
sourceCompatibility = '22'

repositories {
    mavenCentral()
}

dependencies {
    // Domyślne zależności, które będą dodane automatycznie
    implementation 'org.springframework.boot:spring-boot-starter:3.3.4'
    implementation 'org.springframework.boot:spring-boot-starter-logging'

    // Możesz dodać więcej zależności, np. do baz danych, logowania itp.
}

publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }
}

Krok 3: Automatyczna konfiguracja

W Spring Boot startery mogą również automatycznie konfigurować różne komponenty przy uruchomieniu aplikacji. Stwórz klasę konfiguracyjną w swoim starterze.

package com.example.common;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class CommonLibraryAutoConfiguration {

    @Bean
    public StringUtils stringUtils() {
        return new StringUtils();
    }
}

Klasa CommonLibraryAutoConfiguration jest oznaczona adnotacją @Configuration, co oznacza, że Spring Boot automatycznie wykryje i skonfiguruje komponenty (w tym wypadku klasę StringUtils) w aplikacji, która będzie używać tego startera.

Krok 4: Plik `spring.factories`

Aby Spring Boot wiedział, że Twoja konfiguracja powinna być automatycznie załadowana, musisz dodać plik spring.factories do katalogu resources/META-INF/.

resources/
└── META-INF/
    └── spring.factories

W pliku spring.factories wpisz:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.common.CommonLibraryAutoConfiguration

Dzięki temu Spring Boot będzie wiedział, że klasa CommonLibraryAutoConfiguration powinna być automatycznie załadowana przy starcie aplikacji.

Krok 5: Publikacja startera

Podobnie jak w przypadku zwykłej biblioteki, opublikuj swój starter, korzystając z polecenia:

./gradlew publishToMavenLocal

Krok 6: Użycie startera

Aby użyć tego startera w innym projekcie, wystarczy dodać jego zależność w pliku build.gradle:

dependencies {
    implementation 'com.example:my-starter:1.0.0'
}

Spring Boot automatycznie załaduje konfigurację i zarejestruje komponent StringUtils bez potrzeby ręcznej konfiguracji.

4. Podsumowanie różnic

Starter:
- Zawiera zestaw zależności.
- Może dodawać domyślną konfigurację i automatycznie rejestrować komponenty Spring Boot.
- Upraszcza pracę poprzez automatyczne zarządzanie konfiguracją i komponentami.
Zwykła biblioteka:
- Zawiera konkretne funkcje lub narzędzia, ale nie zarządza zależnościami czy konfiguracją automatycznie.
- Użytkownik musi sam dodać zależności i odpowiednio skonfigurować komponenty.

Startery są więc bardziej "plug-and-play", a zwykłe biblioteki wymagają więcej ręcznego zarządzania zależnościami i konfiguracją.

DEV Community: Andrzej Korcz

Kafka kontra RabbitMQ

Apache Kafka

RabbitMQ

Kiedy wybrać Kafka:

Kiedy wybrać RabbitMQ:

Dwa popularne standardy propagacji śledzenia komunikatów.

1. W3C Trace Context (standard propagacji śledzenia przyjęty przez W3C):

2. B3 Propagation (standard używany przez Zipkin):

Podział nagłówków:

Jakie są różnice między tymi standardami?

Co to oznacza dla Twojej aplikacji?

Łańcuch zależności wyjątków.

1. Cel łańcucha wyjątków

2. Jak to działa?

3. Dlaczego to jest ważne?

4. Hierarchia wyjątków

5. Spring Boot i łańcuch wyjątków

6. Stack trace i debugowanie

Podsumowanie

Korzyści z użycia wirtualnych wątków w aplikacji Spring Boot

Zalety Wirtualnych Wątków:

Przykłady Użycia Wirtualnych Wątków:

1. Serwisy Mikroserwisowe (HTTP i Bazy Danych)

2. Asynchroniczne Pobieranie Danych z Kilku Źródeł

Podsumowanie

Różnice między bibliotekami a starterami w Spring Boot

1. Co to są biblioteki typu "starter"?

2. Różnica między starterami a zwykłą biblioteką

Kluczowe różnice:

3. Jak stworzyć własny starter?

Przykład tworzenia własnego startera:

Krok 1: Struktura projektu

Krok 2: Konfiguracja build.gradle

Krok 3: Automatyczna konfiguracja

Krok 4: Plik spring.factories

Krok 5: Publikacja startera

Krok 6: Użycie startera

4. Podsumowanie różnic

Krok 2: Konfiguracja `build.gradle`

Krok 4: Plik `spring.factories`