Service mesh a tradycyjne trasowanie ruchu: porównanie podejść
Źródło: Nadmid0822, CC BY-SA 4.0, Wikimedia Commons
Spis treści
Tradycyjne trasowanie ruchu
W tradycyjnym podejściu do komunikacji między mikrousługami, logika trasowania ruchu — w tym ponawianie żądań, limity czasowe czy szyfrowanie połączeń — jest implementowana bezpośrednio w kodzie każdej usługi lub w bibliotekach współdzielonych między usługami. Podejście to jest stosunkowo proste we wdrożeniu przy niewielkiej liczbie usług, jednak wymaga spójnej implementacji tej samej logiki w wielu miejscach kodu.
Podejście service mesh
Service mesh to dodatkowa warstwa infrastruktury, w której logika trasowania ruchu, bezpieczeństwa i obserwowalności zostaje wydzielona z kodu aplikacji do osobnych komponentów proxy (tzw. sidecar), działających obok każdej instancji usługi. Takie podejście pozwala scentralizować zarządzanie ruchem sieciowym niezależnie od języka programowania czy frameworka, w którym napisana jest dana usługa.
Kiedy uzasadnione jest wdrożenie service mesh
Wdrożenie service mesh wiąże się z dodatkową złożonością operacyjną — koniecznością zarządzania warstwą proxy oraz jej wpływem na opóźnienia komunikacji między usługami. Z tego względu podejście to bywa uzasadnione przede wszystkim w środowiskach obejmujących dużą liczbę niezależnie rozwijanych mikrousług, gdzie spójne zarządzanie ruchem i bezpieczeństwem komunikacji staje się trudne do utrzymania na poziomie kodu aplikacji.
W mniejszych architekturach, obejmujących kilka lub kilkanaście usług, tradycyjne podejście do trasowania ruchu bywa wystarczające i nie wymaga dodatkowej warstwy infrastruktury — decyzja ta powinna wynikać z konkretnej architektury systemu, opisanej szerzej w artykule Architektura mikrousług w kontekście orkiestracji kontenerów.