Service mesh to wzorzec architektoniczny i zestaw narzędzi używany do zarządzania komunikacją między usługami w architekturze mikroserwisowej. Głównym celem service mesha jest zapewnienie spójnego, bezpiecznego, obserwowalnego i niezawodnego sposobu komunikacji między mikroserwisami – bez konieczności implementowania tych mechanizmów w każdej usłudze z osobna.
Jak działa service mesh?
Service mesh składa się z dwóch głównych komponentów:
Data plane – czyli tzw. płaszczyzna danych. To zestaw lekkich proxy (sidecarów) uruchamianych razem z każdą usługą (np. Envoy). Przechwytują i kontrolują cały ruch wychodzący i przychodzący do usługi.
Control plane – czyli płaszczyzna kontrolna. To centralny komponent zarządzający konfiguracją i politykami, które przekazuje do proxy.
Co oferuje service mesh?
Load balancing – równoważenie obciążenia między instancjami usług.
Service discovery – odnajdywanie usług bez potrzeby ręcznego konfigurowania adresów.
Observability – monitoring, tracing i metryki komunikacji.
Retry, timeout, circuit breaking – zaawansowane mechanizmy odpornościowe.
Security – wzajemne uwierzytelnianie (mTLS), autoryzacja, szyfrowanie ruchu.
Traffic control – możliwość np. przekierowania tylko części ruchu do nowej wersji aplikacji (canary deployments).
Przykłady popularnych service mesh:
Istio
Linkerd
Consul Connect
Kuma (od Kong)
Kiedy warto używać service mesh:
Masz wiele mikroserwisów
Gdy liczba usług rośnie (np. > 10–15), trudniej ręcznie zarządzać połączeniami, retry, timeoutami czy obciążeniem.Potrzebujesz bezpieczeństwa komunikacji
Gdy wymagana jest szyfrowana komunikacja (mTLS) między usługami — mesh może to załatwić automatycznie.Chcesz centralnie zarządzać routingiem i politykami ruchu
Przekierowania, canary deployments, A/B testy – bez zmiany kodu usług.Monitoring i obserwowalność są krytyczne
Service mesh (np. Istio) daje wbudowany tracing, metryki, logi dla każdego połączenia sieciowego.Chcesz rozdzielić logikę biznesową od sieciowej
Retry, circuit breaking, timeouty – konfigurujesz raz dla całej siatki, nie w każdym serwisie.Wymagane są polityki dostępu (RBAC, whitelisty)
Mesh potrafi egzekwować polityki komunikacji np. “Serwis A może rozmawiać z B, ale nie z C”.
Kiedy NIE warto:
Masz monolit lub kilka usług
Narzut operacyjny i wydajnościowy może przewyższyć korzyści.Brak potrzeby zaawansowanej sieciowej logiki
Jeśli retry, security i monitoring są proste lub realizowane inaczej.Nie masz zasobów na zarządzanie meshem
Istio, Linkerd itp. wprowadzają dodatkowe komponenty i wymagają wiedzy DevOps/SRE.
