Mikrousługi (ang. microservices) to styl architektury, w którym jedną aplikację dzielisz na zbiór małych, niezależnych usług. Każda z nich odpowiada za jeden fragment biznesu (np. logowanie, koszyk, płatności), działa we własnym procesie i rozmawia z resztą przez sieć — najczęściej przez REST API, gRPC albo kolejkę komunikatów. Przeciwieństwem jest monolit, czyli jedna wielka aplikacja, w której wszystko siedzi w tym samym kodzie i tym samym procesie.
Jak to działa i po co to komuś
Kluczowa idea to luźne powiązanie (loose coupling) i niezależne wdrażanie. Każdą usługę możesz osobno rozwijać, testować, wdrażać i skalować — bez ruszania reszty. Sklep ma czarny piątek i koszyk się dusi? Skalujesz tylko usługę koszyka, a nie całą aplikację. Zespół płatności pisze w Javie, a zespół rekomendacji w Pythonie? Spoko, każda usługa może mieć własny stack i własną bazę danych.
Cena za tę elastyczność jest realna: zamiast jednej aplikacji utrzymujesz rozproszony system. Dochodzą problemy, których w monolicie nie ma — opóźnienia sieci, awarie częściowe, spójność danych między usługami i monitoring rozsiany po kilkunastu serwisach.
Przykład z praktyki
Typowy zestaw: usługi pakujesz w kontenery Docker, a orkiestrujesz je w Kubernetes. Każda usługa to osobny Deployment, a skalowanie to dosłownie jedna komenda:
kubectl scale deployment cart-service --replicas=5
Do komunikacji wewnętrznej często używa się gRPC albo brokera typu RabbitMQ czy Kafka (komunikacja asynchroniczna, gdy usługa nie musi czekać na odpowiedź od razu). Ruch z zewnątrz wpuszczasz przez API Gateway, który kieruje żądania do właściwej usługi.
Częste błędy i mity
- Mit „mikro = małe = lepsze”. Liczy się granica biznesowa, nie liczba linii kodu. Setka usług dzielących jedną bazę danych to nie mikrousługi, tylko rozproszony monolit — masz wszystkie wady obu światów naraz.
- Start od mikrousług na nowym projekcie. Zwykle lepiej zacząć od porządnego monolitu i wydzielać usługi, gdy realnie zaczyna boleć. Przedwczesny podział to góra konfiguracji zamiast działającego produktu.
- Współdzielona baza danych. Każda usługa powinna mieć swoje dane na wyłączność. Wspólna tabela to ukryte, sztywne powiązanie, które niweczy całą niezależność.
- Brak obserwowalności. Bez centralnych logów, metryk i distributed tracing (np. OpenTelemetry) debugowanie błędu wędrującego przez pięć usług to wróżenie z fusów.
Pojęcia powiązane: monolit, konteneryzacja (Docker), Kubernetes, API Gateway, REST, gRPC, message broker (Kafka, RabbitMQ), Domain-Driven Design, distributed tracing, CI/CD.