Mikroserwisy – czy to przyszłość architektury

Dlaczego mikroserwisy są teraz wszędzie?

W 2016 roku słowo „mikroserwisy” pojawia się na każdej konferencji programistycznej. Firmy jak Netflix, Amazon czy Uber przeszły już na tę architekturę i chwalą się efektami. Ale czy to oznacza, że każda aplikacja powinna porzucić tradycyjny monolit?

Czym są mikroserwisy?

Mikroserwisy to podejście architektoniczne, gdzie aplikacja składa się z wielu małych, niezależnych serwisów, które komunikują się poprzez sieć. Każdy serwis odpowiada za konkretną funkcjonalność biznesową i może być rozwijany, wdrażany i skalowany niezależnie.

Przeciwieństwem mikroserwisów jest **aplikacja monolityczna** – gdzie cała logika biznesowa znajduje się w jednej, dużej aplikacji. Monolit to nie jest coś złego per se, ale ma swoje ograniczenia przy skalowaniu zespołów i funkcjonalności.

Kluczowe cechy mikroserwisów

**1. Autonomiczność:** Każdy serwis ma własną bazę danych i może być wdrażany niezależnie.

**2. Skupienie na biznesie:** Jeden serwis = jedna domena biznesowa (np. płatności, użytkownicy, zamówienia).

**3. Komunikacja przez sieć:** Serwisy rozmawiają przez HTTP/REST API, nie przez bezpośrednie wywołania metod.

**4. Różnorodność technologiczna:** Każdy zespół może wybrać najlepszą technologię dla swojego problemu.

Korzyści mikroserwisów

Skalowanie zespołów

Największą zaletą mikroserwisów jest możliwość niezależnej pracy zespołów. Gdy masz 50+ programistów, koordynacja zmian w monolicie staje się koszmarem. Z mikroserwisami każdy zespół może:

– Wybierać własny stos technologiczny
– Wdrażać zmiany bez czekania na inne zespoły
– Odpowiadać za pełny cykl życia swojego serwisu

Skalowanie technicznie

W monolicie musisz skalować całą aplikację, nawet jeśli problem dotyczy tylko jednego modułu. Z mikroserwisami skalujesz tylko to, co potrzeba:

# Docker Compose - skalowanie tylko serwisu płatności
version: '2'
services:
  payments-service:
    image: payments:latest
    scale: 5  # 5 instancji tylko dla płatności
  
  user-service:
    image: users:latest
    scale: 1  # jeden wystarczy

Odporność na awarie

Gdy jeden mikroserwis padnie, reszta aplikacji może działać. W monolicie jeden błąd może położyć cały system.

Wyzwania i problemy

Mikroserwisy to nie srebrna kula. Rozwiązują jedne problemy, ale wprowadzają nowe:

Złożoność operacyjna

Zamiast jednej aplikacji masz nagle 10, 20 lub 100 serwisów do monitorowania, logowania i debugowania. To wymaga:

– Centralizowanego logowania (ELK Stack)
– Monitoringu infrastruktury (Prometheus, Grafana)
– Service discovery (Consul, Eureka)
– API Gateway (Zuul, Kong)

Latencja sieciowa

Wywołania między serwisami przez sieć są 1000x wolniejsze niż wywołania metod w monolicie. Musisz projektować z myślą o:

– Timeouts i retry logic
– Circuit breakers (Hystrix od Netflix)
– Asynchronicznej komunikacji

Problemy z transakcjami

Nie ma ACID transactions między serwisami. Musisz używać wzorców jak:

– **Saga Pattern** – długie transakcje jako seria kroków
– **Event Sourcing** – przechowywanie zdarzeń zamiast stanu
– **Eventual Consistency** – akceptacja tymczasowej niespójności

// Przykład Saga Pattern - zamówienie z płatnością
public class OrderSaga {
    
    public void processOrder(Order order) {
        try {
            // Krok 1: Zarezerwuj produkty
            inventoryService.reserve(order.getItems());
            
            // Krok 2: Pobierz płatność
            paymentService.charge(order.getPayment());
            
            // Krok 3: Potwierdź zamówienie
            orderService.confirm(order);
            
        } catch (Exception e) {
            // Rollback - anuluj poprzednie kroki
            compensate(order);
        }
    }
    
    private void compensate(Order order) {
        inventoryService.release(order.getItems());
        paymentService.refund(order.getPayment());
    }
}

Kiedy wybrać mikroserwisy?

Mikroserwisy nie są dla każdego. Oto sytuacje, gdy warto je rozważyć:

Test Conwaya

Prawo Conwaya mówi: „Organizacje projektują systemy odzwierciedlające ich strukturę komunikacyjną”.

Jeśli masz jeden zespół – prawdopodobnie lepiej sprawdzi się monolit. Jeśli masz zespoły odpowiedzialne za różne domeny biznesowe – mikroserwisy mogą być naturalne.

Technologie i narzędzia w 2016

Ekosystem mikroserwisów w 2016 roku szybko się rozwija:

Platformy i orchestracja

– **Docker** – konteneryzacja serwisów
– **Docker Swarm** – orkiestracja kontenerów (Kubernetes dopiero zyskuje popularność)
– **Amazon ECS** – managed containers w AWS

Service Discovery

– **Netflix Eureka** – rejestr serwisów
– **Consul** – service discovery + configuration
– **Zookeeper** – koordynacja serwisów

API Gateway

– **Netflix Zuul** – routing i proxy
– **Kong** – API gateway z pluginami
– **AWS API Gateway** – managed w chmurze

Circuit Breakers

– **Netflix Hystrix** – ochrona przed kaskadowymi awariami
– **Akka Circuit Breaker** – dla aplikacji JVM

// Spring Boot z Eureka - rejestracja serwisu
@SpringBootApplication
@EnableEurekaClient
public class PaymentServiceApplication {
    
    public static void main(String[] args) {
        SpringApplication.run(PaymentServiceApplication.class, args);
    }
}

// application.yml
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
  instance:
    preferIpAddress: true

Strategia migracji z monolitu

Nie przechodzisz na mikroserwisy z dnia na dzień. Oto sprawdzona strategia:

1. Strangler Fig Pattern

Stopniowo „dusisz” monolit, wydzielając serwisy:

1. **Zidentyfikuj granice** – znajdź bounded contexts w monolicie
2. **Wydziel API** – stwórz interfejs dla wybranej funkcjonalności
3. **Przepierw ruch** – skieruj część requestów do nowego serwisu
4. **Usuń stary kod** – gdy nowy serwis jest stabilny

2. Database per Service

Każdy serwis powinien mieć własną bazę danych:

-- Przed: jedna baza dla wszystkiego
-- orders, users, products, payments w jednej DB

-- Po: oddzielne bazy
-- orders-service -> orders_db  
-- users-service -> users_db
-- payments-service -> payments_db

3. Start small

Zacznij od serwisu który:
– Ma najmniej zależności
– Jest dobrze zdefiniowany biznesowo
– Może być łatwo odwrócony

Monitorowanie mikroserwisów

W świecie mikroserwisów monitoring to nie opcja – to konieczność:

Distributed Tracing

Śledź request przez wiele serwisów:

– **Zipkin** – distributed tracing system
– **Jaeger** – OpenTracing compatible
– **Spring Cloud Sleuth** – automatic tracing dla Spring

Centralizowane logi

# Logstash configuration dla mikroserwisów
input {
  beats {
    port => 5044
  }
}

filter {
  if [fields][service] == "payment-service" {
    mutate {
      add_tag => [ "payment" ]
    }
  }
}

output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "microservices-%{+YYYY.MM.dd}"
  }
}

Podsumowanie

Mikroserwisy w 2016 roku to obiecująca architektura, ale nie panaceum. Wprowadzają złożoność operacyjną w zamian za elastyczność i skalowalność zespołów.

Kluczowe pytania przed decyzją:
1. Czy masz zespół DevOps gotowy na zarządzanie wieloma serwisami?
2. Czy Twoja aplikacja ma wyraźne granice biznesowe?
3. Czy zespół > 15 osób i ma problemy z koordynacją?

Jeśli odpowiedź to „tak” – mikroserwisy mogą być dobrym wyborem. Jeśli „nie” – zostań przy monolicie i zrób go dobrze.

Przydatne zasoby:

• Martin Fowler – Microservices
• Netflix Eureka – Service Discovery
• Spring Cloud Documentation
• Docker – Getting Started
• Netflix Hystrix – Circuit Breaker