Hej Habro! Zwracam uwagę na tłumaczenie artykułu „Płaszczyzna danych siatki usług a płaszczyzna sterowania” autor Matt Kleina.

Tym razem „chciałem i przetłumaczyłem” opis obu komponentów siatki usług, płaszczyzny danych i płaszczyzny sterowania. Opis ten wydał mi się najbardziej zrozumiały i ciekawy, a co najważniejsze prowadzący do zrozumienia pytania „Czy to w ogóle konieczne?”

Ponieważ idea „siatki usług” stała się coraz bardziej popularna w ciągu ostatnich dwóch lat (oryginalny artykuł z 10 października 2017 r.), a liczba uczestników w przestrzeni wzrosła, zaobserwowałem proporcjonalny wzrost zamieszania wśród całej społeczności społeczności technologicznej w zakresie porównywania i kontrastowania różnych rozwiązań.

Sytuację najlepiej podsumowuje następująca seria tweetów, które napisałem w lipcu:

Zamieszanie w siatce usług nr 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Żaden z nich nie jest równy Istio. Istio to coś zupełnie innego. 1 /

Pierwsza to po prostu płaszczyzny danych. Sami nic nie zrobią. Muszą mieć ochotę na coś więcej. 2/

Istio jest przykładem płaszczyzny sterowania, która łączy części ze sobą. To jest kolejna warstwa. /koniec

Poprzednie tweety wspominają o kilku różnych projektach (Linkerd, NGINX, HAProxy, Envoy i Istio), ale co ważniejsze, przedstawiają ogólne koncepcje płaszczyzny danych, siatki usług i płaszczyzny kontroli. W tym poście cofnę się o krok i omówię na bardzo wysokim poziomie znaczenie terminów „płaszczyzna danych” i „płaszczyzna sterowania”, a następnie omówię, w jaki sposób te terminy odnoszą się do projektów wspomnianych w tweetach.

Czym tak naprawdę jest siatka usług?

Rysunek 1: Przegląd siatki usług

Rysunek 1 ilustruje koncepcję siatki usług na najbardziej podstawowym poziomie. Istnieją cztery klastry usług (AD). Każda instancja usługi jest powiązana z lokalnym serwerem proxy. Cały ruch sieciowy (HTTP, REST, gRPC, Redis itp.) z pojedynczej instancji aplikacji jest przekazywany przez lokalny serwer proxy do odpowiednich klastrów usług zewnętrznych. W ten sposób instancja aplikacji nie jest świadoma sieci jako całości i zna jedynie swój lokalny serwer proxy. W efekcie sieć systemu rozproszonego została usunięta z usługi.

Płaszczyzna danych

W siatce usług serwer proxy zlokalizowany lokalnie dla aplikacji wykonuje następujące zadania:

• Odkrycie usług. Jakie usługi/aplikacje są dostępne dla Twojej aplikacji?
• Sprawdzanie stanu zdrowia. Czy instancje usługi zwrócone przez wykrywanie usług są zdrowe i gotowe do akceptowania ruchu sieciowego? Może to obejmować zarówno aktywne (np. odpowiedź/kontrola stanu usługi), jak i pasywne (np. użycie 3 kolejnych błędów 5xx jako wskazania złego stanu usługi).
• Wytyczanie. Do jakiego klastra usług należy wysłać żądanie do „/foo” z usługi REST?
• Równoważenie obciążenia. Po wybraniu klastra usług podczas routingu, do której instancji usługi należy wysłać żądanie? Z jakim limitem czasu? Z jakimi ustawieniami wyłączania obwodu? Jeśli żądanie nie powiedzie się, czy należy je ponowić?
• Uwierzytelnianie i autoryzacja. Czy w przypadku żądań przychodzących usługę wywołującą można zidentyfikować/autoryzować kryptograficznie przy użyciu mTLS lub innego mechanizmu? Jeśli zostanie rozpoznany/autoryzowany, czy można wywołać żądaną operację (punkt końcowy) w usłudze, czy też należy zwrócić nieuwierzytelnioną odpowiedź?
• Obserwowalność. Dla każdego żądania należy wygenerować szczegółowe statystyki, dzienniki/dzienniki i rozproszone dane śledzenia, aby operatorzy mogli zrozumieć rozproszony przepływ ruchu i problemy z debugowaniem w miarę ich pojawiania się.

Płaszczyzna danych jest odpowiedzialna za wszystkie poprzednie punkty siatki usług. W rzeczywistości lokalnym serwerem proxy usługi (wózkiem bocznym) jest płaszczyzna danych. Innymi słowy, płaszczyzna danych jest odpowiedzialna za warunkowe rozgłaszanie, przekazywanie i monitorowanie każdego pakietu sieciowego wysyłanego do lub z usługi.

Płaszczyzna sterująca

Abstrakcja sieci, którą zapewnia lokalny serwer proxy w płaszczyźnie danych, jest magiczna (?). Jednakże, skąd serwer proxy faktycznie wie o trasie „/foo” do usługi B? W jaki sposób można wykorzystać dane dotyczące wykrywania usług, które są wypełniane przez żądania proxy? Jak skonfigurowane są parametry równoważenia obciążenia, przekroczenia limitu czasu, przerwania obwodu itp.? Jak wdrożyć aplikację przy użyciu metody niebieskiej/zielonej lub metody płynnego przejścia ruchu? Kto konfiguruje ustawienia uwierzytelniania i autoryzacji w całym systemie?

Wszystkie powyższe elementy znajdują się pod kontrolą płaszczyzny kontrolnej siatki serwisowej. Płaszczyzna sterująca pobiera zestaw izolowanych bezstanowych serwerów proxy i przekształca je w system rozproszony.

Myślę, że powodem, dla którego wielu technologów uważa oddzielne koncepcje płaszczyzny danych i płaszczyzny kontroli za mylące, jest to, że dla większości ludzi płaszczyzna danych jest znana, podczas gdy płaszczyzna sterowania jest obca/niezrozumiana. Od dłuższego czasu pracujemy z fizycznymi routerami i przełącznikami sieciowymi. Rozumiemy, że pakiety/żądania muszą przejść z punktu A do punktu B i że możemy w tym celu wykorzystać sprzęt i oprogramowanie. Nowa generacja programowych proxy to po prostu fantazyjne wersje narzędzi, z których korzystamy od dawna.

Rysunek 2: Płaszczyzna kontroli człowieka

Jednak od dawna korzystamy z płaszczyzn sterowania, chociaż większość operatorów sieci może nie kojarzyć tej części systemu z żadnym komponentem technologii. Powód jest prosty:
Większość samolotów sterujących używanych obecnie to... my.

Na Rycina 2 pokazuje to, co nazywam „ludzką płaszczyzną kontroli”. W tego typu wdrożeniach, które wciąż jest bardzo powszechne, prawdopodobnie zrzędliwy operator tworzy statyczne konfiguracje - potencjalnie za pomocą skryptów - i wdraża je w specjalnym procesie na wszystkich serwerach proxy. Następnie serwery proxy rozpoczynają korzystanie z tej konfiguracji i przetwarzanie płaszczyzny danych przy użyciu zaktualizowanych ustawień.

Rysunek 3: Płaszczyzna sterowania zaawansowaną siatką usług

Na Rycina 3 pokazuje „rozszerzoną” płaszczyznę kontrolną siatki serwisowej. Składa się z następujących części:

• Człowiek: Nadal istnieje osoba (miejmy nadzieję, mniej zła), która podejmuje decyzje na wysokim szczeblu dotyczące całego systemu jako całości.
• Interfejs płaszczyzny kontrolnej: Osoba wchodzi w interakcję z pewnego rodzaju interfejsem użytkownika, aby sterować systemem. Może to być portal internetowy, aplikacja wiersza poleceń (CLI) lub inny interfejs. Za pomocą interfejsu użytkownika operator ma dostęp do globalnych parametrów konfiguracyjnych systemu takich jak:
  • Kontrola wdrożenia, kolor niebieski/zielony i/lub stopniowe przejście ruchu
  • Opcje uwierzytelniania i autoryzacji
  • Specyfikacje tablicy routingu, na przykład, gdy aplikacja A żąda informacji o tym, co się dzieje z „/foo”.
  • Ustawienia modułu równoważenia obciążenia, takie jak limity czasu, ponowne próby, ustawienia przerywania obwodu itp.
• Harmonogram obciążenia: Usługi działają w infrastrukturze za pośrednictwem pewnego rodzaju systemu planowania/organizacji, takiego jak Kubernetes lub Nomad. Harmonogram jest odpowiedzialny za załadowanie usługi wraz z jej lokalnym serwerem proxy.
• Odkrycie usług. Gdy program planujący uruchamia i zatrzymuje instancje usługi, zgłasza stan kondycji systemowi wykrywania usług.
• Interfejsy API konfiguracji serwera proxy Sidecar : Lokalne serwery proxy dynamicznie wyodrębniają stan z różnych komponentów systemu przy użyciu ostatecznie spójnego modelu bez interwencji operatora. Cały system, składający się ze wszystkich aktualnie uruchomionych instancji usług i lokalnych serwerów proxy, ostatecznie łączy się w jeden ekosystem. Uniwersalny interfejs API płaszczyzny danych Envoy jest jednym z przykładów tego, jak to działa w praktyce.

Zasadniczo celem płaszczyzny kontroli jest ustalenie zasad, które zostaną ostatecznie zaakceptowane przez płaszczyznę danych. Bardziej zaawansowane płaszczyzny sterujące usuną od operatora więcej części niektórych systemów i będą wymagały mniej ręcznej obsługi, pod warunkiem, że działają poprawnie!...

Płaszczyzna danych i płaszczyzna sterowania. Podsumowanie płaszczyzny danych i płaszczyzny sterowania

• Płaszczyzna danych siatki usług: Wpływa na każdy pakiet/żądanie w systemie. Odpowiedzialny za wykrywanie aplikacji/usług, sprawdzanie kondycji, routing, równoważenie obciążenia, uwierzytelnianie/autoryzację i obserwowalność.
• Płaszczyzna sterowania siatką usług: Zapewnia zasady i konfigurację dla wszystkich działających płaszczyzn danych w sieci usługowej. Nie wpływa na żadne pakiety/żądania w systemie. Płaszczyzna sterowania przekształca wszystkie płaszczyzny danych w system rozproszony.

Obecny krajobraz projektu

Po zrozumieniu powyższego wyjaśnienia przyjrzyjmy się bieżącemu stanowi projektu siatki usług.

• Samoloty danych: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Samoloty sterujące: Istio, Nelson, SmartStack

Zamiast wdawać się w dogłębną analizę każdego z powyższych rozwiązań, pokrótce odniosę się do niektórych punktów, które moim zdaniem powodują obecnie najwięcej zamieszania w ekosystemie.

Linkerd był jednym z pierwszych serwerów proxy płaszczyzny danych dla siatki usług na początku 2016 roku i wykonał fantastyczną robotę, zwiększając świadomość i uwagę na model projektowania siatki usług. Około 6 miesięcy później Envoy dołączył do Linkerd (choć w Lyft był związany od końca 2015 roku). Linkerd i Envoy to dwa projekty, o których najczęściej wspomina się przy omawianiu siatek usług.

Istio zostało ogłoszone w maju 2017 r. Cele projektu Istio są bardzo podobne do pokazanej na rozszerzonej płaszczyźnie sterowania Rycina 3. Domyślnym serwerem proxy jest Envoy dla Istio. Zatem Istio jest płaszczyzną sterowania, a Envoy jest płaszczyzną danych. W krótkim czasie Istio wywołało wiele emocji, a inne płaszczyzny danych zaczęły się integrować w zastępstwie Envoy (zarówno Linkerd, jak i NGINX wykazały integrację z Istio). Fakt, że w tej samej płaszczyźnie sterowania można używać różnych płaszczyzn danych, oznacza, że ​​płaszczyzna sterowania i płaszczyzna danych niekoniecznie są ściśle powiązane. Interfejs API, taki jak ogólny interfejs API platformy danych Envoy, może utworzyć pomost pomiędzy dwiema częściami systemu.

Nelson i SmartStack pomagają w dalszym zilustrowaniu oddzielenia płaszczyzny sterowania od płaszczyzny danych. Nelson używa Envoy jako swojego proxy i buduje niezawodną płaszczyznę kontroli dla siatki usług w oparciu o stos HashiCorp, tj. Nomad itp. SmartStack był prawdopodobnie pierwszą z nowej fali siatek usług. SmartStack buduje płaszczyznę kontroli wokół HAProxy lub NGINX, demonstrując możliwość oddzielenia płaszczyzny kontroli od siatki usług od płaszczyzny danych.

Architektura mikroserwisowa z siatką usług zyskuje coraz więcej uwagi (słusznie!), a coraz więcej projektów i dostawców zaczyna działać w tym kierunku. W ciągu najbliższych kilku lat będziemy świadkami wielu innowacji zarówno w płaszczyźnie danych, jak i kontroli, a także dalszego mieszania różnych komponentów. Docelowo architektura mikroserwisów powinna stać się bardziej przejrzysta i magiczna (?) dla operatora.
Mam nadzieję, że coraz mniej zirytowanych.

Kluczowe wnioski

• Siatka usług składa się z dwóch różnych części: płaszczyzny danych i płaszczyzny kontrolnej. Obydwa komponenty są wymagane i bez nich system nie będzie działał.
• Każdy zna płaszczyznę kontroli i w tym momencie płaszczyzną kontroli możesz być Ty!
• Wszystkie płaszczyzny danych konkurują ze sobą pod względem funkcji, wydajności, konfigurowalności i rozszerzalności.
• Wszystkie płaszczyzny sterowania konkurują ze sobą pod względem funkcji, konfigurowalności, rozszerzalności i łatwości użytkowania.
• Jedna płaszczyzna kontroli może zawierać odpowiednie abstrakcje i interfejsy API, dzięki czemu można używać wielu płaszczyzn danych.

Źródło: www.habr.com