SERIA: Mikroserwisy od podstaw – Część 1

Dlaczego architektura mikroserwisów zmienia zasady gry

Wyobraź sobie, że twoja aplikacja to wielki blok mieszkalny – wszystko jest połączone, każda zmiana wymaga remontu całego budynku, a gdy jeden element się psuje, cały system może stanąć. Teraz pomyśl o miasteczku domków jednorodzinnych – każdy dom jest niezależny, można go remontować osobno, a awaria w jednym nie wpływa na pozostałe. To właśnie różnica między monolitem a mikroserwisami.

Architektura mikroserwisów nie jest nową modą – to odpowiedź na realne problemy, z jakimi borykają się rozwijające się zespoły i rosnące aplikacje. Gdy monolityczna aplikacja osiąga określony rozmiar, każda zmiana staje się kosztowna, ryzykowna i czasochłonna.

Co się nauczysz z tego artykułu

Wymagania wstępne

Czym właściwie są mikroserwisy?

Wyobraź sobie tradycyjną aplikację e-commerce. W architekturze monolitycznej wszystko znajduje się w jednym "pudełku":
– Zarządzanie użytkownikami
– Katalog produktów
– System płatności
– Zarządzanie zamówieniami
– Powiadomienia email

W architekturze mikroserwisów każda z tych funkcjonalności staje się osobnym serwisem:

🏪 E-commerce jako mikroserwisy:

├── User Service (port 3001)
│   ├── Rejestracja/logowanie
│   └── Profile użytkowników
│   
├── Product Service (port 3002)  
│   ├── Katalog produktów
│   └── Wyszukiwarka
│   
├── Payment Service (port 3003)
│   ├── Proces płatności  
│   └── Integracja z bramkami
│   
├── Order Service (port 3004)
│   ├── Składanie zamówień
│   └── Historia zakupów
│   
└── Notification Service (port 3005)
    ├── Email notifications
    └── Push notifications

Kluczowe cechy mikroserwisów

**1. Niezależność deploymentu**
Możesz wdrożyć nową wersję serwisu płatności bez dotykania reszty aplikacji. To oznacza, że zespół odpowiedzialny za płatności może pracować w swoim tempie.

**2. Technologiczna różnorodność**
User Service może być napisany w Javie, Product Service w Node.js, a Payment Service w Pythonie. Każdy zespół wybiera najlepsze narzędzie do swojego problemu.

**3. Odpowiedzialność za dane**
Każdy serwis ma własną bazę danych i nikt inny nie ma do niej bezpośredniego dostępu. Chcesz dane o użytkowniku? Musisz zapytać User Service przez API.

Dlaczego firmy przechodzą na mikroserwisy?

Problem 1: Monolit spowalnia rozwój

Wyobraź sobie sytuację z prawdziwego projektu. Masz aplikację e-commerce napisaną jako monolit w Spring Boot. Zespół ma 15 programistów. Co się dzieje, gdy wszyscy próbują wprowadzać zmiany jednocześnie?

**W mikroserwisach:** Zespół płatności może wprowadzać zmiany niezależnie. Nawet jeśli ich serwis się wysypie, reszta aplikacji dalej działa.

Problem 2: Skalowanie "wszystkiego albo niczego"

W Black Friday ruch na katalog produktów wzrasta 10x, ale rejestracja nowych użytkowników tylko 2x. W monolicie musisz skalować całą aplikację, płacąc za zasoby, których nie potrzebujesz.

**W mikroserwisach:** Sklalujesz tylko Product Service, oszczędzając 70% kosztów infrastruktury.

Problem 3: Technologiczny dług

Twój monolit został napisany w 2015 roku w Java 8. Teraz chcesz użyć najnowszych funkcji Java 11, ale ryzyko migracji całej aplikacji jest zbyt duże.

**W mikroserwisach:** Nowe serwisy piszesz w najnowszych technologiach, stare stopniowo modernizujesz. Można mieć część aplikacji w Java 8, część w Java 11, a nowe funkcje w Kotlin.

Kiedy mikroserwisy to dobry pomysł?

**Mikroserwisy mają sens, gdy:**

**Zostań przy monolicie, gdy:**
– Zespół < 5 osób (overhead mikroserwisów przewyższy korzyści) - Aplikacja jest prosta i szybko się nie zmienia - Nie masz doświadczenia z zarządzaniem rozproszonymi systemami - Budżet na infrastrukturę jest ograniczony

Główne wyzwania mikroserwisów

Mikroserwisy to nie tylko korzyści. Wprowadzają też nowe problemy, o których w monolicie nie musiałeś myśleć.

1. Złożoność sieci

W monolicie wywołanie metody to jeden skok w pamięci. W mikroserwisach to żądanie HTTP przez sieć. Co może pójść nie tak?

// Monolit - proste wywołanie
User user = userService.findById(123);
Order order = orderService.createOrder(user, products);

// Mikroserwisy - potencjalne problemy sieciowe
User user = userServiceClient.findById(123); // Co jeśli timeout?
Order order = orderServiceClient.createOrder(user, products); // Co jeśli serwis jest down?

2. Zarządzanie danymi

W monolicie transakcja bazodanowa gwarantuje spójność. Jak zapewnić, że gdy tworzysz zamówienie, produkty są dostępne, użytkownik istnieje, a płatność przeszła?

**Rozwiązanie:** Saga pattern lub eventual consistency – zaawansowane tematy, które omówimy w kolejnych częściach serii.

3. Monitoring i debugging

W monolicie masz jeden log file. W mikroserwisach request może przejść przez 5 różnych serwisów. Jak wyśledzić błąd?

**Potrzebujesz:**
– Distributed tracing (np. Jaeger, Zipkin)
– Centralizowany logging (np. ELK stack)
– Monitoring zdrowia serwisów (np. Prometheus + Grafana)

Jak przygotować się na mikroserwisy?

**Krok 1: Zidentyfikuj granice domenowe**

Nie dziel według warstw technicznych (Controller, Service, Repository), ale według domen biznesowych:

❌ Złe dzielenie (warstwy techniczne):
├── Web Layer Service
├── Business Logic Service  
└── Data Access Service

✅ Dobre dzielenie (domeny biznesowe):
├── User Management Service
├── Product Catalog Service
├── Order Processing Service
└── Payment Service

**Krok 2: Rozpocznij od extraktów**

Nie przepisuj całej aplikacji. Zacznij od wyciągnięcia jednego, dobrze zdefiniowanego obszaru:

**Krok 3: Zbuduj CI/CD pipeline**

Mikroserwisy bez automatyzacji to koszmar. Potrzebujesz:
– Automated testing dla każdego serwisu
– Independent deployment pipeline
– Container orchestration (Docker + Kubernetes lub Docker Swarm)

Przykład transformacji: od monolitu do mikroserwisów

Zobaczmy jak wygląda proces na przykładzie aplikacji e-commerce:

**Faza 1: Monolit z wydzielonymi modułami**

// Struktura monolitu przed refactoringiem
src/main/java/com/ecommerce/
├── user/
│   ├── UserController.java
│   ├── UserService.java
│   └── UserRepository.java
├── product/
│   ├── ProductController.java  
│   ├── ProductService.java
│   └── ProductRepository.java
└── order/
    ├── OrderController.java
    ├── OrderService.java
    └── OrderRepository.java

**Faza 2: Wyciągnięcie pierwszego serwisu**

// Nowy user-service jako osobna aplikacja
@RestController
@RequestMapping("/api/users")
public class UserController {
    
    @GetMapping("/{id}")
    public ResponseEntity getUser(@PathVariable Long id) {
        User user = userService.findById(id);
        return ResponseEntity.ok(user);
    }
    
    @PostMapping
    public ResponseEntity createUser(@RequestBody CreateUserRequest request) {
        User user = userService.createUser(request);
        return ResponseEntity.ok(user);
    }
}

**Faza 3: Komunikacja między serwisami**

// W order-service - komunikacja przez HTTP
@Service
public class OrderService {
    
    private final UserServiceClient userClient;
    private final ProductServiceClient productClient;
    
    public Order createOrder(CreateOrderRequest request) {
        // Sprawdź czy użytkownik istnieje
        User user = userClient.getUser(request.getUserId());
        
        // Sprawdź dostępność produktów
        List products = productClient.getProducts(request.getProductIds());
        
        // Utwórz zamówienie
        return orderRepository.save(new Order(user.getId(), products));
    }
}

Narzędzia i technologie (stan na 2019)

W 2019 roku ekosystem mikroserwisów już się ustabilizował. Oto główne narzędzia:

**Service Discovery:**
– Eureka (Spring Cloud)
– Consul (HashiCorp)

**API Gateway:**
– Zuul (Netflix, wbudowany w Spring Cloud)
– Kong
– AWS API Gateway

**Containerization:**
– Docker (standard dla pakowania serwisów)
– Kubernetes (orchestracja, zyskuje na popularności)

**Monitoring:**
– Prometheus + Grafana (metryki)
– ELK Stack (logowanie)
– Jaeger (distributed tracing)

Przydatne zasoby:

• Microservices.io – wzorce i best practices
• Martin Fowler – Microservices architecture
• Spring Cloud – narzędzia dla mikroserwisów
• Netflix OSS – open source tools
• Kubernetes documentation

Czy rozważasz wprowadzenie mikroserwisów w swoim projekcie? Jakie są Twoje główne obawy lub pytania? Podziel się w komentarzach!