Architektura z service mesh jest zaprojektowana do zarządzania złożonymi interakcjami między mikrousługami za pomocą odrębnej warstwy infrastrukturalnej. Service mesh automatycznie zapewnia takie funkcje jak trasowanie, balansowanie, odkrywanie usług, bezpieczeństwo (np. mTLS), logowanie, śledzenie i powtórzenia żądań bez konieczności realizacji ich w każdej usłudze. Wszystko to osiągane jest dzięki specjalnym proxy (sidecar), które uruchamiane są obok każdej mikrousługi i przechwytują cały ruch sieciowy.
Tradycyjna architektura mikrousługowa wymaga, aby wiele z tych funkcji było realizowanych wewnątrz samych usług lub na poziomie platformy, co utrudnia rozwój i wsparcie projektu przy dużej liczbie usług.
Przykład kodu konfiguracji Istio service mesh dla Kubernetes:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-service spec: hosts: - my-service http: - route: - destination: host: my-service subset: v1
Kluczowe cechy:
Centralne trasowanie i zarządzanie politykami interakcji sieciowych.
Minimalizacja duplikacji kodu logiki interakcji w każdej usłudze.
Ulepszone bezpieczeństwo i monitorowanie bez zmiany logiki biznesowej aplikacji.
Czy service mesh całkowicie zastępuje API gateway?
Nie, service mesh i API gateway uzupełniają się nawzajem: API gateway zapewnia kontrolę wejściową, a service mesh zarządza komunikacją east-west między usługami.
Czy należy modyfikować kod usług przy wdrażaniu service mesh?
Zazwyczaj nie. W większości przypadków serwisowy proxy jest uruchamiany w trybie sidecar, a kod logiki biznesowej nie wymaga zmian.
Czy service mesh pogarsza wydajność mikrousług?
Service mesh rzeczywiście wprowadza niewielkie opóźnienie z powodu przetwarzania ruchu przez proxy, ale w większości scenariuszy jest to nieistotne w porównaniu z zyskami w zarządzalności i niezawodności.