Notatka. przeł.: Siatka serwisowa to zjawisko, które nie ma jeszcze stabilnego tłumaczenia na język rosyjski (ponad 2 lata temu proponowaliśmy opcję „siatka dla usług”, a nieco później niektórzy koledzy zaczęli aktywnie promować połączenie „sito serwisowe”). Ciągłe rozmowy na temat tej technologii doprowadziły do sytuacji, w której elementy marketingowe i techniczne są ze sobą zbyt ściśle powiązane. Ten wspaniały materiał jednego z autorów oryginalnego terminu ma na celu zapewnienie przejrzystości inżynierom i innym osobom.
Komiks z
Wprowadzenie
Jeśli jesteś inżynierem oprogramowania pracującym w obszarze systemów zaplecza, termin „siatka usług” prawdopodobnie zakorzenił się w Twojej głowie w ciągu ostatnich kilku lat. Dzięki dziwnemu zbiegowi okoliczności hasło to coraz bardziej przejmuje branżę, a szum i oferty promocyjne z nim związane rosną niczym kula śnieżna lecąca w dół i nie wykazująca oznak spowolnienia.
Siatka usług narodziła się w mętnych, stronniczych wodach rodzimego ekosystemu chmury. Niestety oznacza to, że większość kontrowersji wokół tej kwestii waha się od „niskokalorycznych rozmów” po – używając technicznego terminu – po prostu nonsens. Ale jeśli przebijesz się przez cały ten szum, odkryjesz, że siatka usług ma bardzo realną, zdefiniowaną i ważną funkcję.
W tym poście spróbuję właśnie to zrobić: przedstawić uczciwy, dogłębny i ukierunkowany na inżynierów przewodnik po siatce usług. Nie odpowiem tylko na pytanie: "Co to jest?", - ale również "Czemu?"a także "Dlaczego teraz?". Na koniec spróbuję nakreślić, dlaczego (moim zdaniem) właśnie ta technologia wywołała tak szalone zamieszanie, co samo w sobie jest ciekawą historią.
Кто я?
Cześć wszystkim! Nazywam się . Jestem jednym z twórców — pierwszy projekt service mesh i projekt, który jest odpowiedzialny za pojawienie się tego terminu siatka serwisowa jako taki (przepraszam, chłopaki!). (Uwaga tłumacz.: Swoją drogą, u zarania pojawienia się tego terminu, ponad 2,5 roku temu, przetłumaczyliśmy już wczesny materiał tego samego autora zatytułowany „”.) Ja też kieruję to startup, który tworzy fajne rzeczy z siatki usług, takie jak Linkerd i .
Pewnie się domyślacie, że mam w tej kwestii bardzo stronnicze i subiektywne zdanie. Postaram się jednak ograniczyć stronniczość do minimum (z wyjątkiem jednej sekcji: „Dlaczego tak dużo mówi się o siatce usług?”, - w którym nadal będę dzielić się z góry przyjętymi pomysłami). Dołożę także wszelkich starań, aby niniejszy poradnik był jak najbardziej obiektywny. W przypadku konkretnych przykładów będę się opierał przede wszystkim na doświadczeniu Linkerda, wskazując jednocześnie różnice (jeśli istnieją), które znam w implementacji innych typów siatek usług.
OK, czas przejść do smakołyków.
Co to jest siatka usług?
Pomimo całego szumu struktura siatki usług jest dość prosta. To tylko kilka serwerów proxy w przestrzeni użytkownika zlokalizowanych „obok” usług (o tym, co „następne” będzie trochę później) oraz zestaw procesów kontrolnych. Serwery proxy są wywoływane zbiorczo samolot danych, a procesy kontrolne nazywane są sterowanie samolotem. Płaszczyzna danych przechwytuje połączenia między usługami i wykonuje z nimi „różne rzeczy”; Odpowiednio płaszczyzna kontroli koordynuje zachowanie serwera proxy i zapewnia dostęp, tj. operatora do API, umożliwiając manipulowanie siecią i pomiary jako całość.
Co to za serwer proxy? Jest to serwer proxy TCP obsługujący warstwę 7 (tj. „uwzględnienie” warstwy 7 modelu OSI) jak HAProxy i NGINX. Możesz wybrać serwer proxy według własnych upodobań; Linkerd używa proxy Rusta, zwanego po prostu . Zestawiliśmy to specjalnie dla siatki serwisowej. Inne siatki preferują inne proxy (częstym wyborem jest Envoy). Jednak wybór serwera proxy to tylko kwestia wdrożenia.
Co robią te serwery proxy? Oczywiście pośredniczą w połączeniach do i z usług (ściśle mówiąc, pełnią funkcję proxy i odwrotnego proxy, obsługując zarówno połączenia przychodzące, jak i wychodzące). Implementują także zestaw funkcji skupiający się na połączeniach между usługi. To skupienie się na ruchu między usługami odróżnia serwer proxy siatki usług od, powiedzmy, bram API lub serwerów proxy przychodzących (te ostatnie skupiają się na wywołaniach przychodzących do klastra ze świata zewnętrznego). (Notatka. przeł.: Aby porównać istniejące kontrolery Ingress dla Kubernetes, z których wiele korzysta ze wspomnianego już Envoy, zobacz .)
Zatem uporządkowaliśmy płaszczyznę danych. Płaszczyzna kontroli jest prostsza: jest to zestaw komponentów zapewniających wszystkie mechanizmy potrzebne płaszczyznie danych do skoordynowanego działania, w tym wykrywanie usług, wydawanie certyfikatów TLS, agregację metryk itp. Płaszczyzna danych informuje płaszczyznę kontroli o jego zachowanie; z kolei płaszczyzna sterowania zapewnia interfejs API, który umożliwia zmianę i monitorowanie zachowania płaszczyzny danych jako całości.
Poniżej znajduje się schemat płaszczyzny sterowania i płaszczyzny danych w Linkerdzie. Jak widać, płaszczyzna kontroli obejmuje kilka różnych komponentów, w tym instancję Prometheus, która zbiera metryki z serwerów proxy, a także inne komponenty, takie jak destination (wykrywanie usług), identity (urząd certyfikacji, CA) i public-api (punkty końcowe dla Internetu i interfejsu CLI). W przeciwieństwie do tego płaszczyzna danych jest prostym serwerem proxy linkerd obok instancji aplikacji. To tylko schemat logiczny; W przypadku wdrożenia w świecie rzeczywistym możesz mieć trzy repliki każdego komponentu płaszczyzny sterowania i setki lub tysiące serwerów proxy w płaszczyźnie danych.
(Niebieskie prostokąty na tym diagramie symbolizują granice podów Kubernetes. Możesz zobaczyć, że kontenery z serwerem proxy linkerd znajdują się w tym samym zasobniku, co kontenery aplikacji. Ten schemat jest znany jako kontener z wózkiem bocznym.)
Architektura siatki usług ma kilka ważnych implikacji. Po pierwsze, ponieważ zadaniem serwera proxy jest przechwytywanie połączeń między usługami, siatka usług ma sens tylko wtedy, gdy aplikacja została utworzona dla określonego zestawu usług. Siatka można używać z monolitami, ale jest to wyraźnie zbędne ze względu na jeden serwer proxy, a jego funkcjonalność raczej nie będzie pożądana.
Inną ważną konsekwencją jest to, że wymaga tego siatka usług ogromny liczba proxy. Tak naprawdę Linkerd dołącza linkerd-proxy do każdej instancji każdej usługi (inne implementacje dodają proxy do każdego węzła/hosta/maszyny wirtualnej. To i tak dużo). Takie aktywne korzystanie z serwerów proxy samo w sobie niesie ze sobą szereg dodatkowych komplikacji:
- Serwery proxy w płaszczyźnie danych muszą być szybko, ponieważ na każde wywołanie przypada kilka wywołań do serwera proxy: jedno po stronie klienta, jedno po stronie serwera.
- Serwery proxy też powinny być mały и lekki. Każdy z nich zużywa zasoby pamięci i procesora, a zużycie to będzie rosnąć liniowo wraz z aplikacją.
- Będziesz potrzebował mechanizmu do wdrażania i aktualizowania dużej liczby serwerów proxy. Robienie tego ręcznie nie wchodzi w grę.
Ogólnie rzecz biorąc, siatka usług wygląda tak (przynajmniej z lotu ptaka): wdrażasz kilka serwerów proxy w przestrzeni użytkownika, które „robią coś” z ruchem wewnętrznym, między usługami, i używasz płaszczyzny kontrolnej do monitorowania i zarządzania nimi.
Teraz czas zadać pytanie „Dlaczego?”
Do czego służy siatka usług?
Tym, którzy po raz pierwszy zetknęli się z ideą siatki usług, można wybaczyć lekkie zaniepokojenie. Konstrukcja siatki usług oznacza, że nie tylko zwiększy ona opóźnienia w aplikacji, ale także konsumować zasoby i Doda szereg nowych mechanizmów w infrastrukturze. Najpierw konfigurujesz siatkę usług, a potem nagle okazuje się, że musisz obsługiwać setki (jeśli nie tysiące) serwerów proxy. Pytanie brzmi, kto dobrowolnie to zrobi?
Odpowiedź na to pytanie składa się z dwóch części. Po pierwsze, koszty transakcyjne związane z wdrażaniem tych serwerów proxy można znacznie obniżyć dzięki pewnym zmianom zachodzącym w ekosystemie (więcej o tym później).
Po drugie, takie urządzenie to naprawdę świetny sposób na wprowadzenie dodatkowej logiki do systemu. Nie tylko dlatego, że siatka usług może dodać wiele nowych funkcjonalności, ale także dlatego, że można to zrobić bez ingerencji w ekosystem. W rzeczywistości cały model siatki usług opiera się na tym założeniu: w systemie wielousługowym, bez względu na wszystko robią usługi indywidualne, ruch między nimi to idealny punkt do dodania funkcjonalności.
Na przykład w Linkerdzie (jak w większości siatek) funkcjonalność skupia się przede wszystkim na wywołaniach HTTP, w tym HTTP/2 i gRPC*. Funkcjonalność jest dość bogata – można ją podzielić na trzy klasy:
- Funkcje związane z niezawodność. Powtarzające się żądania, przekroczenia limitu czasu, podejście kanarkowe (podział/przekierowanie ruchu) itp.
- Funkcje związane z monitorowanie. Agregacja wskaźników powodzenia, opóźnień i wolumenów żądań dla każdej usługi lub poszczególnych kierunków; budowa map topologicznych usług itp.
- Funkcje związane z bezpieczeństwo. Wzajemne TLS, kontrola dostępu itp.
* Z punktu widzenia Linkerda gRPC praktycznie nie różni się od HTTP/2: po prostu używa protobuf w ładunku. Z punktu widzenia programisty te dwie rzeczy są oczywiście różne.
Wiele z tych mechanizmów działa na poziomie żądania (stąd „proxy L7”). Na przykład, jeśli usługa Foo wykonuje wywołanie HTTP do usługi Bar, linkerd-proxy po stronie Foo może przeprowadzać inteligentne równoważenie obciążenia i kierować wywołania z instancji Foo do Bar w oparciu o zaobserwowane opóźnienie; może powtórzyć żądanie, jeśli zajdzie taka potrzeba (i jeśli jest idempotentny); może rejestrować kod odpowiedzi i limit czasu itp. Podobnie linkerd-proxy po stronie Bar może odrzucić żądanie, jeśli nie jest dozwolone lub przekroczono limit żądań; może odnotować opóźnienie ze swojej strony itp.
Serwery proxy mogą „coś zrobić” także na poziomie połączenia. Na przykład linkerd-proxy po stronie Foo może inicjować połączenie TLS, a linkerd-proxy po stronie Bar może je zakończyć, a obie strony mogą wzajemnie weryfikować swoje certyfikaty TLS*. Zapewnia to nie tylko szyfrowanie między usługami, ale także bezpieczny kryptograficznie sposób identyfikacji usług: Foo i Bar mogą „udowodnić”, że są tym, za kogo się podają.
* „Wspólny znajomy” oznacza, że weryfikowany jest także certyfikat klienta (wzajemny TLS). W „klasycznym” TLS, np. pomiędzy przeglądarką a serwerem, weryfikowany jest zazwyczaj certyfikat tylko jednej strony (serwera).
Niezależnie od tego, czy działają na poziomie żądania, czy połączenia, należy podkreślić, że wszystkie funkcje siatki usług są operacyjny postać. Linkerd nie jest w stanie przekształcić semantyki ładunku - na przykład dodając pola do fragmentu JSON lub wprowadzając zmiany w protobuf. O tej ważnej funkcji porozmawiamy później, kiedy będziemy mówić o magistrali ESB i oprogramowaniu pośrednim.
Jest to zestaw funkcji oferowanych przez siatkę usług. Powstaje pytanie: dlaczego nie zaimplementować ich bezpośrednio w aplikacji? I po co w ogóle zawracać sobie głowę proxy?
Dlaczego siatka usług jest dobrym pomysłem
Chociaż możliwości siatki usług są ekscytujące, jej podstawowa wartość tak naprawdę nie leży w jej funkcjach. W końcu my Mogą zaimplementuj je bezpośrednio w aplikacji (zobaczymy później, że to było początkiem siatki usług). Aby spróbować podsumować to w jednym zdaniu, wartość siatki usług wynosi: zapewnia funkcje krytyczne dla działania nowoczesnego oprogramowania serwerowego w sposób spójny na całym stosie i niezależny od kodu aplikacji.
Przeanalizujmy tę propozycję.
«Funkcje krytyczne do działania nowoczesnego oprogramowania serwerowego" Jeśli tworzysz aplikację serwera transakcyjnego, która jest podłączona do publicznego Internetu, akceptująca żądania ze świata zewnętrznego i odpowiadająca na nie w krótkim czasie – na przykład aplikacja internetowa, serwer API i zdecydowana większość innych nowoczesnych aplikacji - i jeśli zaimplementujesz go jako zestaw usług, które synchronicznie ze sobą współdziałają, i jeśli stale aktualizujesz to oprogramowanie, dodając nowe funkcje i jeśli jesteś zmuszony utrzymywać ten system w sprawności podczas procesu modyfikacji - w tym przypadku, gratulacje, tworzysz nowoczesne oprogramowanie serwerowe. Wszystkie te wspaniałe funkcje wymienione powyżej okazują się dla Ciebie kluczowe. Aplikacja musi być niezawodna, bezpieczna, a Ty musisz móc obserwować, co robi. To są dokładnie te pytania, które pomaga rozwiązać usługa Service Mesh.
(OK, w poprzednim akapicie nadal utwierdzam się w przekonaniu, że takie podejście jest nowoczesnym sposobem tworzenia oprogramowania serwerowego. Inni wolą tworzyć monolity, „reaktywne mikroserwisy” i inne rzeczy, które nie mieszczą się w podanej powyżej definicji. Ci ludzie prawdopodobnie mają swoje zdanie jest odmienne od mojego. Ja natomiast uważam, że oni są „w błędzie” – choć i tak siatka serwisowa nie jest dla nich zbyt przydatna).
«Jednolite dla całego stosu" Funkcjonalność zapewniana przez siatkę usług ma nie tylko znaczenie krytyczne. Dotyczą one wszystkich usług w aplikacji, niezależnie od tego, w jakim języku są napisane, z jakiego frameworku korzystają, kto je napisał, w jaki sposób zostały wdrożone i inne subtelności związane z ich rozwojem i wykorzystaniem.
«Niezależny od kodu aplikacji" Wreszcie siatka usług nie tylko zapewnia spójną funkcjonalność na całym stosie, ale robi to w sposób, który nie wymaga edycji aplikacji. Podstawowa podstawa funkcjonalności Service Mesh, obejmująca zadania konfiguracji, aktualizacji, obsługi, konserwacji itp., znajduje się całkowicie na poziomie platformy i jest niezależna od aplikacji. Aplikacja może się zmieniać bez wpływu na siatkę usług. Z kolei siatka usług może się zmieniać bez udziału aplikacji.
Krótko mówiąc, siatka usług nie tylko zapewnia istotną funkcjonalność, ale także robi to w sposób globalny, jednolity i niezależny od aplikacji. I tak, chociaż funkcjonalność siatki usług można zaimplementować w kodzie usługi (na przykład jako bibliotekę dołączoną do każdej usługi), to podejście to nie zapewni jednolitości i niezależności, która jest tak cenna w przypadku siatki usług.
Wszystko, co musisz zrobić, to dodać kilka serwerów proxy! Obiecuję, że wkrótce sprawdzimy koszty operacyjne związane z dodaniem tych serwerów proxy. Ale najpierw zatrzymajmy się i spójrzmy na tę ideę niepodległości z różnych perspektyw. ludzie.
Komu pomaga Service Mesh?
Choć może to być niewygodne, aby technologia stała się ważną częścią ekosystemu, musi zostać zaakceptowana przez ludzi. Kto więc jest zainteresowany siatką usług? Kto zyskuje na jego zastosowaniu?
Jeśli tworzysz nowoczesne oprogramowanie serwerowe, możesz z grubsza myśleć o swoim zespole jako o grupie właściciele usługktórzy wspólnie opracowują i wdrażają logikę biznesową, oraz właściciele platformy, rozwijając wewnętrzną platformę, na której działają te usługi. W małych organizacjach mogą to być te same osoby, ale w miarę rozwoju firmy role te stają się coraz wyraźniejsze, a nawet podzielone na role podrzędne... (Jest tu wiele do powiedzenia na temat zmieniającego się charakteru devopsów, wpływ organizacyjny mikrousług itp.) n. Ale na razie przyjmijmy te opisy za podane).
Z tego punktu widzenia wyraźnymi beneficjentami siatki usług są właściciele platform. Ostatecznie ostatecznym celem zespołu ds. platformy jest stworzenie wewnętrznej platformy, na której właściciele usług będą mogli wdrażać logikę biznesową i robić to w sposób zapewniający im jak największą niezależność od niejasnych szczegółów jej działania. Siatka usług nie tylko oferuje możliwości krytyczne dla osiągnięcia tego celu, ale robi to w sposób, który z kolei nie narzuca zależności od właścicieli usług.
Właściciele usług również odnoszą korzyści, chociaż w bardziej pośredni sposób. Celem właściciela usługi jest możliwie jak największa produktywność we wdrażaniu logiki procesu biznesowego, a im mniej musi się martwić kwestiami operacyjnymi, tym lepiej. Zamiast zajmować się wdrażaniem, powiedzmy, zasad ponawiania prób lub TLS, mogą skupić się wyłącznie na celach biznesowych i mieć nadzieję, że platforma zajmie się resztą. To dla nich duża zaleta.
Wartość organizacyjna takiego podziału pomiędzy właścicielami platform i usług jest nie do przecenienia. Myślę, że ona się przyczynia podstawowy wkład w wartość siatki usług.
Dowiedzieliśmy się tej lekcji, gdy jeden z pierwszych fanów Linkerda powiedział nam, dlaczego wybrał usługę Service Mesh: ponieważ pozwoliło im to „ograniczyć do minimum rozmowy”. Oto kilka szczegółów: goście z jednej dużej firmy przenieśli swoją platformę na Kubernetes. Ponieważ aplikacja obsługiwała poufne informacje, chcieli szyfrować całą komunikację w klastrach. Sytuację komplikowała jednak obecność setek serwisów i setek zespołów programistycznych. Perspektywa skontaktowania się ze wszystkimi i przekonania ich, aby w swoich planach uwzględnili obsługę TLS, wcale ich nie napawała radością. Po zainstalowaniu Linkerda przenieśli się odpowiedzialność od deweloperów (z punktu widzenia których był to niepotrzebny kłopot) po platformówki, dla których było to priorytetem najwyższej próby. Innymi słowy, Linkerd rozwiązał dla nich nie tyle problem techniczny, co organizacyjny.
Krótko mówiąc, siatka usługowa jest bardziej rozwiązaniem, a nie technicznym, ale socjotechniczne Problemy. (Dziękuję za wprowadzenie tego terminu.)
Czy siatka usług rozwiąże wszystkie moje problemy?
Tak. Myślę że nie!
Jeśli przyjrzysz się trzem klasom funkcji opisanym powyżej — niezawodności, bezpieczeństwu i obserwowalności — stanie się jasne, że siatka usług nie jest kompletnym rozwiązaniem żadnego z tych problemów. Chociaż Linkerd może ponownie wysyłać żądania (jeśli wie, że są idempotentne), nie jest w stanie podejmować decyzji o tym, co zwrócić użytkownikowi, jeśli usługa trwale zawiedzie – decyzje te muszą zostać podjęte przez aplikację. Linkerd może prowadzić statystyki udanych żądań, ale nie jest w stanie zajrzeć do usługi i podać jej wewnętrznych metryk – aplikacja musi posiadać takie narzędzia. I chociaż Linkerd jest w stanie zorganizować mTLS, pełnoprawne rozwiązania bezpieczeństwa wymagają znacznie więcej.
Dotyczą podzbioru funkcji w tych obszarach oferowanych przez siatkę usług funkcje platformy. Mam tu na myśli funkcje, które:
- Niezależny od logiki biznesowej. Sposób, w jaki konstruowane są histogramy wywołań pomiędzy Foo i Bar, jest całkowicie niezależny od dlaczego Foo dzwoni do Bara.
- Trudne do prawidłowego wdrożenia. W Linkerdzie ponowne próby są parametryzowane za pomocą różnego rodzaju wymyślnych rzeczy, takich jak budżety ponownych prób (ponów próbę budżetów), gdyż niewyrafinowane, bezpośrednie podejście do wdrażania takich rzeczy z pewnością doprowadzi do pojawienia się tzw. „lawiny żądań” (ponowna próba burzy) oraz inne problemy charakterystyczne dla systemów rozproszonych.
- Najbardziej skuteczny, gdy jest stosowany równomiernie. Mechanizm TLS ma sens tylko wtedy, gdy jest stosowany wszędzie.
Ponieważ funkcje te są implementowane na poziomie proxy (a nie na poziomie aplikacji), siatka usług udostępnia je na poziomie platforma, a nie aplikacje. Nie ma zatem znaczenia, w jakim języku są napisane serwisy, w jakim frameworku, kto je napisał i po co. Serwery proxy działają poza tymi wszystkimi szczegółami, a podstawowa podstawa tej funkcjonalności, w tym zadania związane z konfiguracją, aktualizacją, obsługą, konserwacją itp., leży wyłącznie na poziomie platformy.
Przykłady możliwości siatki usług
Podsumowując, siatka usług nie jest kompletnym rozwiązaniem zapewniającym niezawodność, obserwowalność i bezpieczeństwo. Zakres tych obszarów wymaga udziału właścicieli usług, zespołów Ops/SRE i innych podmiotów firmy. Siatka usług zapewnia jedynie „wycinek” na poziomie platformy dla każdego z tych obszarów.
Dlaczego siatka usług stała się teraz popularna?
Pewnie teraz się zastanawiasz: OK, skoro siatka usług jest tak dobra, dlaczego dziesięć lat temu nie zaczęliśmy wdrażać milionów serwerów proxy na stosie?
Odpowiedź na to pytanie jest banalna: dziesięć lat temu wszyscy budowali monolity i nikt nie potrzebował siatki serwisowej. To prawda, ale moim zdaniem ta odpowiedź mija się z celem. Jeszcze dziesięć lat temu koncepcja mikrousług jako obiecującego sposobu budowania systemów na dużą skalę była szeroko dyskutowana i stosowana w takich firmach jak Twitter, Facebook, Google i Netflix. Ogólny pogląd – przynajmniej w tej części branży, z którą miałem styczność – był taki, że mikrousługi to „właściwy sposób” budowania dużych systemów, nawet jeśli jest to cholernie trudne.
Oczywiście, choć dziesięć lat temu istniały firmy obsługujące mikroserwisy, nie umieszczały one proxy wszędzie, gdzie się dało, aby utworzyć siatkę usług. Jeśli jednak przyjrzeć się bliżej, zrobili coś podobnego: wiele z tych firm wymagało użycia specjalnej biblioteki wewnętrznej do komunikacji sieciowej (czasami nazywanej grubą biblioteką klienta, biblioteka grubego klienta).
Netflix miał Hysterix, Google miał Stubby, Twitter miał bibliotekę Finagle. Na przykład Finagle był obowiązkowy w przypadku każdej nowej usługi na Twitterze. Obsługiwał połączenia zarówno po stronie klienta, jak i serwera, umożliwiał powtarzające się żądania, wspierał routing żądań, równoważenie obciążenia i pomiary. Zapewniało spójną warstwę niezawodności i obserwowalności w całym stosie Twittera, niezależnie od tego, co robiła usługa. Działało to oczywiście tylko dla języków JVM i opierało się na modelu programistycznym, który trzeba było zastosować dla całej aplikacji. Jednak jego funkcjonalność była prawie taka sama jak siatki serwisowej. (W rzeczywistości pierwsza wersja Linkerda była po prostu Finagle zawinięta w formularz proxy.)
Tak więc dziesięć lat temu istniały nie tylko mikrousługi, ale także specjalne biblioteki siatki usług proto, które rozwiązywały te same problemy, które rozwiązuje dzisiaj siatka usług. Jednak sama siatka usług wówczas nie istniała. Zanim się pojawiła, musiała minąć jeszcze jedna zmiana.
I tu kryje się głębsza odpowiedź, ukryta w innej zmianie, która zaszła w ciągu ostatnich 10 lat: drastycznie spadły koszty wdrażania mikrousług. Wymienione powyżej firmy, które dziesięć lat temu korzystały z mikroserwisów – Twitter, Netflix, Facebook, Google – były firmami o ogromnej skali i ogromnych zasobach. Mieli nie tylko potrzebę, ale także możliwość tworzenia, wdrażania i obsługi dużych aplikacji opartych na mikrousługach. Energia i wysiłek, jakie inżynierowie Twittera włożyli w przejście od podejścia monolitycznego do podejścia opartego na mikrousługach, są niesamowite. (Szczerze mówiąc, to także fakt, że się udało.) Tego typu manewry infrastrukturalne były wówczas niemożliwe dla mniejszych firm.
Przejdź szybko do teraźniejszości. Są dziś startupy, w których stosunek mikroserwisów do programistów wynosi 5:1 (a nawet XNUMX:XNUMX). ), a co więcej, radzą sobie z nimi skutecznie! Jeśli 5-osobowy startup może z łatwością obsłużyć 50 mikroserwisów, to coś wyraźnie obniżyło koszty ich wdrożenia.
1500 mikroserwisów w Monzo; każda linia jest określoną regułą sieciową, która zezwala na ruch
Radykalne obniżenie kosztów obsługi mikroserwisów jest efektem jednego procesu: rosnąca popularność kontenerów и orkiestratorzy. To właśnie jest głęboka odpowiedź na pytanie, co przyczyniło się do powstania siatki usług. Ta sama technologia uczyniła atrakcyjnymi zarówno siatki usług, jak i mikroserwisy: Kubernetes i Docker.
Dlaczego? Cóż, Docker rozwiązuje jeden duży problem – problem z pakowaniem. Pakując aplikację i jej (niesieciowe) zależności wykonawcze w kontenerze, Docker przekształca aplikację w wymienną jednostkę, którą można hostować i uruchamiać w dowolnym miejscu. Jednocześnie znacznie ułatwia obsługę wielojęzyczny Stos: Ponieważ kontener jest niepodzielną jednostką wykonania, dla celów wdrożeniowych i operacyjnych nie ma znaczenia, co się w nim znajduje, niezależnie od tego, czy jest to aplikacja JVM, Node, Go, Python czy Ruby. Po prostu uruchamiasz i tyle.
Kubernetes przenosi wszystko na wyższy poziom. Teraz, gdy istnieje mnóstwo „rzeczy do uruchomienia” i mnóstwo maszyn, na których można je uruchomić, istnieje zapotrzebowanie na narzędzie, które może je ze sobą skorelować. W szerokim sensie dajesz Kubernetesowi dużo kontenerów i mnóstwo maszyn, a on mapuje je względem siebie (oczywiście jest to proces dynamiczny i ciągle się zmieniający: po systemie przemieszczają się nowe kontenery, maszyny uruchamiają się i zatrzymują itp. Jednak Kubernetes bierze to wszystko pod uwagę).
Po skonfigurowaniu Kubernetes koszt czasu wdrożenia i obsługi jednej usługi niewiele różni się od kosztu wdrożenia i obsługi dziesięciu usług (w rzeczywistości jest prawie taki sam w przypadku 100 usług). Dodaj do tego kontenery jako mechanizm pakowania zachęcający do wielojęzycznej implementacji, a otrzymasz mnóstwo nowych aplikacji zaimplementowanych w formie mikroserwisów napisanych w różnych językach – dokładnie w takim środowisku, do jakiego tak dobrze nadaje się siatka usług.
Dochodzimy zatem do odpowiedzi na pytanie, dlaczego idea service mesh stała się teraz popularna: jednorodność, jaką Kubernetes zapewnia usługom, bezpośrednio przekłada się na wyzwania operacyjne stojące przed siatką usług. Pakujesz proxy w kontenery, dajesz Kubernetesowi zadanie umieszczenia ich gdziekolwiek się da i voila! W rezultacie otrzymujesz siatkę usług, a całą mechaniką jej wdrożenia zarządza Kubernetes. (Przynajmniej z lotu ptaka. Oczywiście proces ten ma wiele niuansów.)
Podsumowując: powodem, dla którego siatki usług stały się popularne teraz, a nie dziesięć lat temu, jest to, że Kubernetes i Docker nie tylko znacząco wzrosły potrzebować w nim, upraszczając wdrażanie aplikacji jako zestawów wielojęzycznych mikrousług, ale także znacznie ograniczając koszty do jego działania, zapewniając mechanizmy wdrażania i wspierania flot zastępczych wózków bocznych.
Dlaczego tak dużo mówi się o siatce usług?
ostrzeżenie: W tej części wykorzystuję wszelkiego rodzaju założenia, przypuszczenia, fabrykacje i informacje poufne.
Wyszukaj „siatkę usług”, a natkniesz się na mnóstwo niskokalorycznych treści pochodzących z recyklingu, dziwne projekty i kalejdoskop zniekształceń godny komory echa. Robi to każda wymyślna nowa technologia, ale w przypadku siatki usług problem jest szczególnie dotkliwy. Dlaczego?
Cóż, po części to moja wina. Ciężko pracowałem, aby promować Linkerd i siatkę usług przy każdej możliwej okazji, poprzez niezliczone posty na blogu i artykuły takie jak ten. Ale nie jestem aż tak potężny. Aby naprawdę odpowiedzieć na to pytanie, musimy porozmawiać trochę o ogólnej sytuacji. I nie da się o tym mówić, nie wspominając o jednym projekcie: to siatka usług typu open source opracowana wspólnie przez Google, IBM i Lyft.
(Te trzy firmy pełnią bardzo różne role: zaangażowanie Lyft wydaje się być jedynie z nazwy; są one autorami Envoy, ale nie korzystają z oprogramowania Istio ani nie uczestniczą w nim. IBM jest zaangażowany w rozwój Istio i wykorzystuje go. Google aktywnie uczestniczy w rozwoju Istio development , ale tak naprawdę z niego nie korzysta, o ile wiem.)
Projekt Istio wyróżnia się dwiema rzeczami. Po pierwsze, w szczególności Google wkłada ogromny wysiłek marketingowy w jego promowanie. Szacuję, że większość osób znających dziś koncepcję siatki usług po raz pierwszy dowiedziała się o niej za pośrednictwem Istio. Druga sprawa to to, jak źle przyjęto Istio. W tej sprawie jestem oczywiście stroną zainteresowaną, ale starając się zachować jak największy obiektywizm, nadal nie mogę pomóc , niezbyt charakterystyczny (choć nie wyjątkowy: przychodzi na myśl systemd, ...) dla projektu Open Source.
(W praktyce Istio wydaje się mieć problemy nie tylko ze złożonością i UX, ale także z wydajnością. Na przykład podczas W badaniu zewnętrznym badacze odkryli sytuacje, w których opóźnienie ogona Istio było 100 razy większe niż Linkerda, a także sytuacje wymagające dużych zasobów, w których Linkerd nadal działał pomyślnie, podczas gdy Istio przestał działać całkowicie.)
Pomijając moje teorie na temat tego, dlaczego tak się stało, uważam, że ogromne emocje wokół siatki usług można wytłumaczyć udziałem Google. Mianowicie kombinacja następujących trzech czynników:
- natrętna promocja Istio przez Google;
- odpowiednia dezaprobata i krytyczna postawa wobec projektu;
- niedawny błyskawiczny wzrost popularności Kubernetesa, o którym wspomnienia są wciąż świeże.
Razem te czynniki tworzą oszałamiające, pozbawione tlenu środowisko, w którym zdolność racjonalnej oceny jest osłabiona, a pozostaje jedynie dziwna różnorodność. .
Z punktu widzenia Linkerda jest to… coś, co określiłbym jako mieszane błogosławieństwo. To znaczy, to wspaniale, że siatka usług wkroczyła do głównego nurtu w taki sposób, w jaki nie zrobiła tego w 2016 roku, kiedy Linkerd zaczynał, i naprawdę trudno było nakłonić ludzi do zwrócenia uwagi na projekt. Teraz nie ma takiego problemu! Zła wiadomość jest jednak taka, że krajobraz siatek usług jest dziś tak zagmatwany, że prawie niemożliwe jest zrozumienie, które projekty w rzeczywistości należą do kategorii siatek usług (nie mówiąc już o zrozumieniu, który z nich najlepiej pasuje do konkretnego przypadku użycia). Jest to zdecydowanie przełom dla wszystkich (i zdecydowanie są przypadki, w których Istio lub inny projekt jest lepszy niż Linkerd, ponieważ ten drugi nadal nie jest rozwiązaniem uniwersalnym).
Ze strony Linkerda nasza strategia polegała na ignorowaniu hałasu, dalszym skupianiu się na rozwiązywaniu rzeczywistych problemów społeczności i zasadniczo czekaniu, aż ucichnie ten szum. Ostatecznie ten szum opadnie i będziemy mogli spokojnie dalej pracować.
Tymczasem wszyscy będziemy musieli uzbroić się jeszcze trochę w cierpliwość.
Czy siatka usług będzie przydatna dla mnie, skromnego inżyniera oprogramowania?
Poniższa ankieta pomoże Ci odpowiedzieć na to pytanie:
Czy zajmujesz się wyłącznie wdrażaniem logiki biznesowej? W takim przypadku siatka usług nie będzie dla Ciebie przydatna. Oznacza to, że możesz być tym zainteresowany, ale w idealnym przypadku siatka usług nie powinna bezpośrednio wpływać na nic w twoim środowisku. Pracuj dalej nad tym, za co ci płacą.
Wspierasz platformę w firmie korzystającej z Kubernetesa? Tak, w tym przypadku potrzebujesz siatki usług (chyba że oczywiście używasz K8 tylko do uruchamiania monolitu lub przetwarzania wsadowego - ale w takim razie chciałbym zapytać, dlaczego potrzebujesz K8). Prawdopodobnie skończy się na wielu mikrousługach napisanych przez różne osoby. Wszystkie one współdziałają ze sobą i są powiązane w plątaninę zależności w czasie wykonywania, a Ty musisz znaleźć sposób, aby sobie z tym wszystkim poradzić. Korzystanie z Kubernetesa pozwala wybrać siatkę usług „dla siebie”. W tym celu zapoznaj się z ich możliwościami i cechami oraz odpowiedz sobie na pytanie, czy któryś z dostępnych projektów jest dla Ciebie odpowiedni (polecam rozpocząć badania od Linkerda).
Czy jesteś firmą platformową w firmie, która NIE korzysta z Kubernetes, ale korzysta z mikrousług? W tym przypadku siatka usług będzie Ci przydatna, ale jej użycie będzie nietrywialne. Oczywiście, że możesz naśladować work service mesh, umieszczając kilka serwerów proxy, ale ważną zaletą Kubernetesa jest model wdrażania: ręczne utrzymanie tych serwerów proxy będzie wymagało znacznie więcej czasu, wysiłku i wydatków.
Odpowiadasz za platformę w firmie zajmującej się monolitami? W tym przypadku prawdopodobnie nie potrzebujesz siatki serwisowej. Jeśli pracujesz z monolitami (lub nawet zbiorami monolitów), które mają dobrze zdefiniowane i rzadko zmieniające się wzorce interakcji, siatka usług będzie miała niewiele do zaoferowania. Możesz więc po prostu to zignorować i mieć nadzieję, że zniknie jak zły sen...
wniosek
Prawdopodobnie service mesh w dalszym ciągu nie powinien być nazywany „najbardziej rozchwytywaną technologią na świecie” – ten wątpliwy zaszczyt prawdopodobnie należy do Bitcoina lub AI. Pewnie jest w pierwszej piątce. Jeśli jednak przebić się przez warstwy szumu, stanie się jasne, że siatka usług przynosi realne korzyści tym, którzy budują aplikacje na Kubernetesie.
Chciałbym, żebyś wypróbował Linkerda - instalując go na klastrze Kubernetes (lub nawet Minikube na laptopie) i przekonasz się sam, o czym mówię.
FAQ
— Czy jeśli zignoruję siatkę usług, zniknie ona?
— Muszę Cię rozczarować: service mesh jest z nami od dawna.
- Ale NIE CHCĘ używać siatki usług!
- Cóż, to nie jest konieczne! Wystarczy przeczytać powyższą ankietę, aby dowiedzieć się, czy warto chociaż zapoznać się z jej podstawami.
— Czy to nie jest stary, dobry ESB/oprogramowanie pośrednie z nowym sosem?
— Siatka usług zajmuje się logiką operacyjną, a nie semantyczną. magistrala usług korporacyjnych (). Utrzymanie tej separacji pomaga siatce usług uniknąć tego samego losu.
— Czym różni się siatka usług od bram API?
— Jest milion artykułów na ten temat. Po prostu wyszukaj to w Google.
— Emisariusz jest siatką usługową?
- Nie, Envoy nie jest siecią usług, jest to serwer proxy. Można go używać do organizowania siatki usług (i wiele więcej - jest to serwer proxy ogólnego przeznaczenia). Ale samo w sobie nie jest to siatka usług.
— Network Service Mesh to siatka usług?
- NIE. Wbrew nazwie nie jest to siatka usługowa (jak Wam się podobają marketingowe cuda?).
— Czy siatka usług będzie pomocna w moim reaktywnym systemie asynchronicznym opartym na kolejce komunikatów?
- Nie, siatka serwisowa ci nie pomoże.
— Której siatki usług powinienem użyć?
- , bez zastanowienia.
- Artykuł jest do bani! / Autor mile widziany!
— Udostępnij link do niego wszystkim swoim znajomym, aby mogli go zobaczyć!
Podziękowanie
Jak można się domyślić z tytułu, ten artykuł został zainspirowany fantastycznym traktatem Jaya Krepsa „" Poznałem Jaya dziesięć lat temu, kiedy przeprowadzałem z nim wywiad na Linked In i od tego czasu jest dla mnie inspiracją.
Chociaż lubię nazywać siebie „programistą Linkerda”, rzeczywistość jest taka, że jestem raczej opiekunem pliku README.md w projekcie. Dzisiaj trwają prace nad Linkerdem , , ludzi, a ten projekt nie powstałby bez udziału wspaniałej społeczności współpracowników i użytkowników.
I na koniec specjalne podziękowania dla twórcy Linkerda, (primus inter pares), który wraz ze mną wiele lat temu rzucił się na całość w to całe zamieszanie z siatką serwisową.
PS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «";
- «".
Źródło: www.habr.com