Witaj ponownie!.. W przeddzień rozpoczęcia kursu przygotowaliśmy jeszcze jeden przydatny przekład.
Service Mesh to konfigurowalny poziom infrastruktury o niskiej latencji, który jest odpowiedni do obsługi dużej ilości komunikacji międzyprocesowej w aplikacjach za pośrednictwem interfejsów API. Service Mesh zapewnia szybka, niezawodną i bezpieczną komunikację między zmiennymi i często efemerycznymi usługami infrastruktury aplikacji. Service Mesh oferuje takie funkcje, jak odkrywanie usług, równoważenie obciążenia, szyfrowanie, przejrzystość, śledzenie, uwierzytelnianie i autoryzacja oraz wsparcie dla wzorca automatycznego wyłączania (circuit breaker).
Service Mesh zazwyczaj realizuje się poprzez przypisanie każdemu egzemplarzowi usługi instancji proxy, zwanej Sidecar. Sidecar obsługują komunikację między usługami, monitorują i rozwiązują problemy bezpieczeństwa, czyli wszystko, co można abstrahować od poszczególnych usług. W ten sposób programiści mogą pisać, utrzymywać i zarządzać kodem aplikacji w usługach, a administratorzy systemów mogą pracować z Service Mesh i uruchamiać aplikację.
Istio od Google, IBM i Lyft jest obecnie najznaniejszą architekturą Service Mesh. Kubernetes, który pierwotnie był rozwijany w Google, teraz jest jedynym frameworkiem do orkiestracji kontenerów wspieranym przez Istio. Vendorzy starają się stworzyć komercyjnie wspierane wersje Istio. Interesujące, co nowego mogą przynieść do projektu z otwartym źródłem.
Jednak Istio to nie jedyna opcja, ponieważ opracowywane są również inne implementacje Service Mesh. Wzorzec sidecar proxy jest najbardziej popularną implementacją, co można wywnioskować na podstawie projektów Buoyant, HashiCorp, Solo.io i innych. Istnieją również alternatywne architektury: narzędzia Netflixa to jeden z podejść, w którym funkcjonalność Service Mesh realizowana jest za pomocą bibliotek Ribbon, Hysterix, Eureka, Archaius oraz takich platform, jak Azure Service Fabric.
Service Mesh ma również swoją własną terminologię dotyczącą komponentów usług i funkcji:
- Framework do orkiestracji kontenerów. W miarę jak w infrastrukturze aplikacji dodawane są kolejne kontenery, pojawia się potrzeba posiadania osobnego narzędzia do monitorowania i zarządzania kontenerami – frameworka orkiestracji kontenerów. Kubernetes ustanowił swoją pozycję na tym rynku tak mocno, że nawet jego główni konkurenci, Docker Swarm i Mesosphere DC/OS, oferują integrację z Kubernetes jako alternatywę.
- Usługi i instancje (pody Kubernetes). Instancja to jedna uruchomiona kopia mikroserwisu. Czasami jedna instancja to jeden kontener. W Kubernetes instancja składa się z małej grupy niezależnych kontenerów, która nazywa się pod. Klienci rzadko zwracają się bezpośrednio do instancji lub podu, częściej kontaktują się z usługą, która jest zbiorem identycznych, skalowalnych i odpornych na awarie instancji lub podów (replik).
- Proxy Sidecar. Proxy Sidecar działa z jedną instancją lub pod. Idea Proxy Sidecar polega na kierowaniu lub proxyfikacji ruchu przychodzącego od kontenera, z którym współpracuje, oraz ruchu zwrotnego. Sidecar wchodzi w interakcje z innymi Proxy Sidecar i jest zarządzane przez framework orkiestracji. Wiele implementacji Service Mesh wykorzystuje Proxy Sidecar do przechwytywania i zarządzania całym przychodzącym i wychodzącym ruchem danej instancji lub podu.
- Odkrywanie usług. Kiedy instancja musi współpracować z inną usługą, musi znaleźć (odkryć) sprawną i dostępną instancję tej usługi. Zazwyczaj instancja wykonuje wyszukiwanie za pomocą DNS. Framework orkiestracji kontenerów przechowuje listę instancji, które są gotowe do przyjmowania zapytań, i udostępnia interfejs do zapytań DNS.
- Rozkład obciążenia. Większość frameworków orkiestracji kontenerów zapewnia równoważenie obciążenia na poziomie 4 (transportowym). Service Mesh realizuje bardziej złożone równoważenie obciążenia na poziomie 7 (aplikacyjnym), bogate w algorytmy i skuteczniejsze w zarządzaniu ruchem. Parametry równoważenia obciążenia mogą być zmieniane za pomocą API, co umożliwia orkiestrację wdrożeń blue-green lub canary.
- SzyfrowanieService Mesh może szyfrować i odszyfrowywać zapytania oraz odpowiedzi, zdejmując to obciążenie z usług. Service Mesh może także poprawić wydajność poprzez priorytetyzację lub ponowne wykorzystanie istniejących stałych połączeń, co zmniejsza potrzebę kosztownych obliczeń do tworzenia nowych połączeń. Najpowszechniejszą realizacją szyfrowania ruchu jest mutual TLS (mTLS), gdzie infrastruktura publicznych kluczy (PKI) generuje i dystrybuuje certyfikaty oraz klucze do użycia w Sidecar Proxy.
- Autoryzacja i uwierzytelnianie. Service Mesh może autoryzować i uwierzytelniać zapytania pochodzące z zewnątrz lub wewnątrz aplikacji, wysyłając instancjom tylko zweryfikowane zapytania.
- Wsparcie dla wzorca automatycznego wyłączania. Service Mesh wspiera , który izoluje niezdrowe instancje, a następnie stopniowo przywraca je do puli zdrowych instancji w razie potrzeby.
Ta część aplikacji Service Mesh, która zarządza ruchem sieciowym między instancjami, nazywa się Data Plane. Tworzenie i wdrażanie konfiguracji, która zarządza zachowaniem Data Plane, odbywa się za pomocą oddzielnego Control Plane. Control Plane zazwyczaj obejmuje lub jest zaprojektowana tak, aby łączyć się z API, CLI lub GUI do zarządzania aplikacją.
Control Plane w Service Mesh rozdziela konfigurację między Sidecar Proxy a Data Plane.
Architektura Service Mesh jest często stosowana do rozwiązywania złożonych zadań operacyjnych z użyciem kontenerów i mikroserwisów. Pionierami w tej dziedzinie są takie firmy jak Lyft, Netflix i Twitter, które dostarczają stabilnie działające usługi milionom użytkowników na całym świecie. (). Dla mniej wymagających zadań aplikacyjnych prawdopodobnie wystarczą prostsze architektury.
Architektura Service Mesh raczej nigdy nie stanie się odpowiedzią na wszystkie pytania związane z funkcjonowaniem aplikacji i ich dostarczaniem. Architekci i programiści dysponują ogromnym arsenałem narzędzi, a tylko jedno z nich — młotek, który wśród wielu zadań powinien radzić sobie tylko z jednym – wbijaniem gwoździ. , na przykład, obejmuje kilka różnych modeli, które oferują ciągłą gamę podejść do rozwiązywania problemów za pomocą mikroserwisów.
Elementy, które łączą się w architekturze Service Mesh, takie jak NGINX, kontenery, Kubernetes i mikroserwisy jako podejście architektoniczne, mogą być równie produktywnie wykorzystywane w implementacjach bez Service Mesh. Na przykład, Istio zostało zaprojektowane jako kompleksowa architektura Service Mesh, ale modułowość oznacza, że programiści mogą wybierać i stosować tylko te komponenty technologii, które są im potrzebne. Pamiętając o tym, warto stworzyć jasne zrozumienie koncepcji Service Mesh, nawet jeśli nie jesteś pewien, czy kiedykolwiek w pełni zaimplementujesz ją w aplikacji.
Źródło: habr.com
