Mikroserwisy — co to jest i kiedy wybrać zamiast monolitu?

Q: Czym jest API Gateway w mikroserwisach?

API Gateway to punkt wejścia dla wszystkich klientów do ekosystemu mikroserwisów — działa jak reverse proxy/facade. Zapewnia: single entry point (zamiast klientów znających adresy wszystkich serwisów), routing requestów do właściwych serwisów, authentication/authorization, rate limiting, load balancing, SSL termination, request aggregation (Backend for Frontend pattern). Popularne rozwiązania: Kong, AWS API Gateway, Nginx, Traefik, Ambassador.

Q: Jak mikroserwisy komunikują się ze sobą?

Dwa główne wzorce: Synchroniczna (REST/gRPC) — jeden serwis bezpośrednio wywołuje drugi przez HTTP/REST lub gRPC. Prosta do debugowania, ale tworzy coupling i kaskadowe awarie. Asynchroniczna (Message Queue) — serwisy komunikują się przez kolejki wiadomości (Kafka, RabbitMQ, AWS SQS). Decoupled, resilient, ale trudniejsze w debugowaniu. Best practice: preferuj asynchroniczną komunikację dla event-driven workflows, synchroniczną tylko gdy potrzebujesz natychmiastowej odpowiedzi.

Q: Co to jest Service Mesh?

Service Mesh to dedykowana warstwa infrastruktury zarządzająca komunikacją między mikroserwisami — bez modyfikowania kodu aplikacji. Rozwiązuje typowe problemy distributed systems: service discovery, load balancing, circuit breaking, retry logic, mutual TLS, observability (tracing). Sidecar proxy (np. Envoy) jest wstrzykiwany obok każdego serwisu i transparentnie obsługuje komunikację. Popularne service mesh: Istio (pełnofunkcyjny, złożony), Linkerd (lżejszy, szybszy), Consul Connect.

Architektura mikroserwisów umożliwia niezależny rozwój i skalowanie — ale za cenę złożoności. Poznaj porównanie z monolitem, wzorce i kiedy naprawdę warto.

Czym są mikroserwisy?

Architektura mikroserwisów to wzorzec projektowania aplikacji jako zbioru małych, niezależnych serwisów — każdy odpowiada za konkretną funkcję biznesową (zamówienia, płatności, użytkownicy, powiadomienia) i komunikuje się z pozostałymi przez sieć. Każdy serwis można rozwijać, testować, wdrażać i skalować niezależnie.

Złota zasada Martina Fowlera: "Don't start with microservices." Zacznij od monolitu, zrozum domain boundaries, a mikroserwisy wyodrębnij gdy naprawdę bolą problemy skalowania i autonomii teamów — nie wcześniej.

Monolit vs. Mikroserwisy — porównanie

Aspekt	Monolit	Mikroserwisy
Wdrożenie	Jeden deployment całej aplikacji — wszystko albo nic	Każdy serwis deployowany niezależnie — partial rollouts
Skalowanie	Skalowanie całej aplikacji nawet gdy tylko jedna część jest przeciążona	Skalowanie indywidualnych serwisów według potrzeb
Technologia	Jeden stack technologiczny dla całej aplikacji	Każdy serwis może używać innego języka, bazy danych, frameworka
Złożoność operacyjna	Prosta — jeden proces, jeden deployment, jedno logowanie	Wysoka — sieć, service discovery, distributed tracing, consistency
Team	Jeden shared codebase — merge conflicts, coordination overhead przy skali	Autonomiczne teamy — każdy owns swój serwis end-to-end
Debug / Testing	Łatwy lokalny development — jeden proces do uruchomienia	Trudny — potrzebujesz wielu serwisów, service virtualization, distributed tracing
Kiedy wybrać	Startup, mały team, niepewne wymagania, early product	Duży team, skalowanie, niezależne domain teams, proven architecture

5 kluczowych wzorców architektury mikroserwisów

Database per Service

Każdy serwis ma własną bazę danych — loose coupling, ale eventual consistency i brak transakcji cross-service

Kiedy stosować: Gdy serwisy muszą być naprawdę niezależne i mogą tolerować eventual consistency

Saga Pattern

Zarządzanie transakcjami rozłożonymi na wiele serwisów przez sekwencję lokalnych transakcji i compensating events

Kiedy stosować: Gdy potrzebujesz ACID-like properties w distributed system

CQRS (Command Query Responsibility Segregation)

Oddzielenie modeli zapisu (Command) i odczytu (Query) — optymalizacja każdego osobno

Kiedy stosować: Gdy wymagania na read i write mocno się różnią, high read/write ratio

Circuit Breaker

Automatyczne zatrzymanie requestów do niedostępnego serwisu — zapobiega kaskadowym awariom

Kiedy stosować: Zawsze w synchronicznej komunikacji między serwisami

Backend for Frontend (BFF)

Osobne API Gateway dla każdego frontend (mobile, web, third-party) — optymalizuje payload i UX

Kiedy stosować: Gdy masz wiele typów klientów z różnymi potrzebami

FAQ — mikroserwisy

Co to jest architektura mikroserwisów?

Architektura mikroserwisów (microservices) to wzorzec projektowania aplikacji jako zbioru małych, niezależnych serwisów — każdy odpowiada za konkretną funkcję biznesową, działa w osobnym procesie i komunikuje się przez sieć (API, message queue). Każdy mikroserwis może być rozwijany, wdrażany i skalowany niezależnie, przez osobny team, w osobnej technologii. Alternatywa dla monolitu — gdzie cały kod jest jedną dużą aplikacją.

Kiedy używać mikroserwisów zamiast monolitu?

Martin Fowler radzi: zacznij od monolitu (Monolith First). Mikroserwisy mają sens gdy: organizacja ma wiele niezależnych teamów (Conway's Law), różne części systemu wymagają różnego skalowania, chcesz deployować różne części niezależnie, różne domeny mają różne wymagania technologiczne. Problemy mikroserwisów: distributed systems complexity, networking, eventual consistency, observability overhead. Dla startupów i małych zespołów (<50 developerów) monolit jest zazwyczaj lepszym wyborem.

Czym jest API Gateway w mikroserwisach?

API Gateway to punkt wejścia dla wszystkich klientów do ekosystemu mikroserwisów — działa jak reverse proxy/facade. Zapewnia: single entry point (zamiast klientów znających adresy wszystkich serwisów), routing requestów do właściwych serwisów, authentication/authorization, rate limiting, load balancing, SSL termination, request aggregation (Backend for Frontend pattern). Popularne rozwiązania: Kong, AWS API Gateway, Nginx, Traefik, Ambassador.

Jak mikroserwisy komunikują się ze sobą?

Dwa główne wzorce: Synchroniczna (REST/gRPC) — jeden serwis bezpośrednio wywołuje drugi przez HTTP/REST lub gRPC. Prosta do debugowania, ale tworzy coupling i kaskadowe awarie. Asynchroniczna (Message Queue) — serwisy komunikują się przez kolejki wiadomości (Kafka, RabbitMQ, AWS SQS). Decoupled, resilient, ale trudniejsze w debugowaniu. Best practice: preferuj asynchroniczną komunikację dla event-driven workflows, synchroniczną tylko gdy potrzebujesz natychmiastowej odpowiedzi.

Co to jest Service Mesh?

Service Mesh to dedykowana warstwa infrastruktury zarządzająca komunikacją między mikroserwisami — bez modyfikowania kodu aplikacji. Rozwiązuje typowe problemy distributed systems: service discovery, load balancing, circuit breaking, retry logic, mutual TLS, observability (tracing). Sidecar proxy (np. Envoy) jest wstrzykiwany obok każdego serwisu i transparentnie obsługuje komunikację. Popularne service mesh: Istio (pełnofunkcyjny, złożony), Linkerd (lżejszy, szybszy), Consul Connect.

Czytaj dalej