🥇Przypadki użycia siatki usług

Notatka. przeł.: Autor tego artykułu (Luc Perkins) jest rzecznikiem programistów w organizacji CNCF, w której znajdują się takie projekty Open Source, jak Linkerd, SMI (Service Mesh Interface) i Kuma (nawiasem mówiąc, czy zastanawiałeś się również, dlaczego Istio jest nie na tej liście?). Próbując po raz kolejny przybliżyć społeczności DevOps modny szum zwany „service mesh”, wymienia 16 charakterystycznych możliwości, jakie zapewniają tego typu rozwiązania.

Dzisiaj siatka serwisowa – jeden z najgorętszych tematów w dziedzinie inżynierii oprogramowania (i słusznie!). Myślę, że ta technologia jest niezwykle obiecująca i chciałbym, aby została powszechnie przyjęta (oczywiście jeśli ma to sens). Jednak dla większości ludzi nadal otacza go aura tajemnicy. Jednocześnie nawet ci, którzy dobrze znane przy nim często trudno jest sformułować jego zalety i czym dokładnie jest (łącznie z Twoimi). W tym artykule postaram się naprawić sytuację, wymieniając różne przypadków użycia „siatki serwisowe”*.

* Notatka tłumacz.: tutaj i w dalszej części artykułu dokładnie to tłumaczenie („service mesh”) będzie używane dla wciąż nowego terminu service mesh.

Ale najpierw chcę poczynić kilka komentarzy:

Nigdy nie pracowałem z siatkami usług ani nie korzystałem z nich poza projektami rozpoczętymi w ramach mojej własnej edukacji. Z drugiej strony, to ja w 2015 roku napisałem całą dokumentację dla wewnętrznej siatki usług Twittera (wtedy jeszcze nie nazywano tego „siatką usług”) oraz brałem udział w rozwoju strony i dokumentacji dla Linkerda, więc to coś znaczy.
Moja lista jest przybliżona i niekompletna. Mogą istnieć nieznane mi przypadki użycia, a wraz z rozwojem technologii i wzrostem jej popularności prawdopodobnie z czasem pojawią się nowe możliwości.
Jednocześnie nie każda istniejąca implementacja siatki usług obsługuje wszystkie wymienione przypadki użycia. Dlatego moje stwierdzenia typu „service mesh może…” należy czytać jako „indywidualne i być może wszystkie popularne implementacje Service Mesh mogą…”.
Kolejność przykładów nie ma żadnego znaczenia.

Ostateczna lista:

wykrywanie usług;
szyfrowanie;
uwierzytelnianie i autoryzacja;
równoważenie obciążenia;
przerwanie obwodu;
automatyczne skalowanie;
rozmieszczenia na Wyspach Kanaryjskich;
wdrożenia niebiesko-zielone;
Kontrola zdrowia;
odłączanie obciążenia;
odzwierciedlanie ruchu;
izolacja;
ograniczanie szybkości żądań, ponownych prób i przekroczeń limitu czasu;
telemetria;
rewizja;
wyobrażanie sobie.

1. Wykrywanie usług

TL; DR: Połącz się z innymi usługami w sieci, używając prostych nazw.

Usługi powinny mieć możliwość automatycznego „odnajdywania” się nawzajem po odpowiednich nazwach – np. service.api.production, pets/staging lub cassandra. Środowiska chmurowe są elastyczne, a pod jedną nazwą można ukryć wiele wystąpień usługi. Oczywiste jest, że w takiej sytuacji zakodowanie na stałe wszystkich adresów IP jest fizycznie niemożliwe.

Ponadto, gdy jedna usługa znajdzie inną, powinna być w stanie wysyłać żądania do tej usługi bez obawy, że trafią one na wejście uszkodzonej instancji. Innymi słowy, siatka usług musi monitorować stan wszystkich instancji usług i utrzymywać możliwie najbardziej aktualną listę hostów.

Każda siatka usług implementuje mechanizm wykrywania usług w inny sposób. W tej chwili najczęstszym sposobem jest delegowanie do procesów zewnętrznych, takich jak Kubernetes DNS. W przeszłości na Twitterze używaliśmy do tego celu systemu nazewnictwa Finał. Ponadto technologia Service Mesh umożliwia pojawienie się niestandardowych mechanizmów nazewnictwa (chociaż nie widziałem jeszcze żadnej implementacji SM z taką funkcjonalnością).

2. Szyfrowanie

TL; DR: Pozbądź się niezaszyfrowanego ruchu między usługami i zautomatyzuj ten proces i skaluj.

Miło jest wiedzieć, że atakujący nie mogą przeniknąć do Twojej sieci wewnętrznej. Firewalle radzą sobie z tym znakomicie. Ale co się stanie, jeśli haker dostanie się do środka? Czy będzie mógł robić co mu się podoba z ruchem wewnątrzusługowym? Miejmy nadzieję, że jednak tak się nie stanie. Aby zapobiec takiemu scenariuszowi, należy wdrożyć sieć o zerowym zaufaniu, w której cały ruch między usługami jest szyfrowany. Większość nowoczesnych siatek usług osiąga to poprzez wzajemne TLS (wzajemny TLS, mTLS). W niektórych przypadkach mTLS działa w całych chmurach i klastrach (myślę, że komunikacja międzyplanetarna pewnego dnia będzie zorganizowana podobnie).

Oczywiście dla siatki usługi mTLS opcjonalny. Każda usługa może zadbać o swój własny TLS, ale oznacza to, że będziesz musiał znaleźć sposób na wygenerowanie certyfikatów, rozesłanie ich pomiędzy hostami usług i dodanie do aplikacji kodu, który załaduje te certyfikaty z plików. Tak, nie zapomnij o regularnym odnawianiu tych certyfikatów. Siatki usług automatyzują mTLS z systemami takimi jak SPIFFE, co z kolei automatyzuje proces wydawania i rotacji certyfikatów.

3. Uwierzytelnianie i autoryzacja

TL; DR: Ustal, kim jest osoba żądająca i zdefiniuj, co może zrobić, zanim żądanie dotrze do usługi.

Służby często chcą wiedzieć kto realizuje żądanie (uwierzytelnianie) i na podstawie tych informacji podejmuje decyzję że dany podmiot może zrobić (zezwolenie). W tym przypadku zaimek „kto” może ukryć:

Inne usługi. Nazywa się to „uwierzytelnianiem” rówieśnik" Na przykład serwis web chce uzyskać dostęp do usługi db. Siatki usług zazwyczaj rozwiązują takie problemy za pomocą mTLS: certyfikaty w tym przypadku pełnią rolę niezbędnego identyfikatora.
Niektórzy użytkownicy. Nazywa się to „uwierzytelnianiem” wniosek" Na przykład użytkownik haxor69 chce kupić nową lampę. Siatki usług zapewniają różne mechanizmy, m.in. Tokeny sieciowe JSON.
Wielu z nas zrobiło to w kodzie aplikacji. Przychodzi prośba, przeglądamy tabelę users, znajdź użytkownika i porównaj hasło, a następnie sprawdź kolumnę permissions itp. W przypadku siatki usług dzieje się to zanim żądanie dotrze do usługi.

Po ustaleniu, od kogo pochodzi żądanie, musimy określić, co ten podmiot może zrobić. Niektóre siatki usług pozwalają ustawić podstawowe zasady (o tym, kto może co zrobić) w postaci plików YAML lub w wierszu poleceń, podczas gdy inne oferują integrację z frameworkami takimi jak Agent otwartej polityki. Ostatecznym celem jest, aby Twoje usługi zaakceptowały każde żądanie, zakładając, że pochodzi ono z zaufanego źródła и działanie to jest dozwolone.

4. Równoważenie obciążenia

TL; DR: Rozłóż obciążenie pomiędzy instancje usługi zgodnie z określonym wzorcem.

„Usługa” w sekcji usług bardzo często składa się z wielu identycznych instancji. Na przykład dzisiaj serwis cache składa się z 5 egzemplarzy, a jutro ich liczba może wzrosnąć do 11. Prośby wysyłane do cache, muszą być rozpowszechniane zgodnie z określonym celem. Na przykład zminimalizuj opóźnienia lub zmaksymalizuj prawdopodobieństwo dotarcia do działającej instancji. Najczęściej stosowanym algorytmem jest metoda round-robin, ale istnieje wiele innych – na przykład metoda ważona (ważone) zapytania (możesz wybrać preferowane cele), zadzwoń (pierścień) hashowanie (stosowanie spójnego hashowania na hostach nadrzędnych) lub metoda najmniejszego żądania (preferowana jest instancja z najmniejszą liczbą żądań).

Klasyczne balansery mają inne funkcje, takie jak buforowanie HTTP i ochrona DDoS, ale nie są one zbyt istotne dla ruchu wschód-zachód (czyli dla ruchu przepływającego w obrębie centrum danych - ok. tłumaczenie) (typowy zakres siatki usług). Oczywiście nie jest konieczne stosowanie siatki usług do równoważenia obciążenia, ale pozwala to na ustawienie i kontrolowanie zasad równoważenia dla każdej usługi ze scentralizowanej warstwy kontrolnej, eliminując w ten sposób potrzebę uruchamiania i konfigurowania oddzielnych modułów równoważenia obciążenia w stosie sieciowym .

5. Przerwanie obwodu

TL; DR: Zatrzymaj ruch do problematycznej usługi i kontroluj szkody w najgorszych scenariuszach.

Jeśli z jakiegoś powodu usługa nie jest w stanie obsłużyć ruchu, siatka usług udostępnia kilka możliwości rozwiązania tego problemu (inne zostaną omówione w odpowiednich rozdziałach). Przerwanie obwodu jest najpoważniejszą opcją odłączenia usługi od ruchu. Jednak samo w sobie nie ma to sensu - potrzebny jest plan zapasowy. Można zapewnić przeciwciśnienie (ciśnienie zwrotne) do usług wysyłających żądania (tylko nie zapomnij skonfigurować do tego siatki usług!), lub na przykład kolorowanie strony statusu na czerwono i przekierowywanie użytkowników do innej wersji strony z „spadającym wielorybem” („Twitter jest w dół").

Siatki usług pozwalają nie tylko definiować kiedy nastąpi zamknięcie i że to nastąpi. W tym przypadku „kiedy” może obejmować dowolną kombinację określonych parametrów: całkowitą liczbę żądań w danym okresie, liczbę połączeń równoległych, oczekujące żądania, aktywne ponowne próby itp.

Prawdopodobnie nie chcesz nadużywać przerywania obwodów, ale miło jest wiedzieć, że masz plan awaryjny na wypadek sytuacji awaryjnej.

6. Autoskalowanie

TL; DR: Zwiększ lub zmniejsz liczbę wystąpień usługi w zależności od określonych kryteriów.

Siatki usług nie są programami planującymi, więc nie przeprowadzać coś skalowanie siebie. Mogą jednak dostarczyć informacji, na jakich planistach będą opierać swoje decyzje. Ponieważ siatki usług mają dostęp do całego ruchu pomiędzy usługami, mają obszerne informacje o tym, co się dzieje: które usługi doświadczają problemów, które usługi są bardzo lekko obciążone (przydzielona im przepustowość jest marnowana) itp.

Na przykład Kubernetes skaluje usługi w oparciu o wykorzystanie procesora i pamięci przez zasobniki (zobacz nasz raport „Autoskalowanie i zarządzanie zasobami w Kubernetesie" - około. tłumacz.), ale jeśli zdecydujesz się skalować w oparciu o jakąkolwiek inną metrykę (w naszym przypadku związaną z ruchem), będziesz potrzebować specjalnego metryki. Kierownictwo lubię to pokazuje, jak to zrobić za pomocą Wysłannik, Podobnie и Prometheus, ale sam proces jest dość skomplikowany. Chcielibyśmy, aby siatka usług uprościła to, pozwalając nam po prostu ustawić warunki, takie jak „zwiększyć liczbę instancji usługi”. auth, jeśli liczba oczekujących żądań przekroczy próg w ciągu minuty.”

7. Wdrożenia na Wyspach Kanaryjskich

TL; DR: Testuj nowe funkcje lub wersje usług na podzbiorze użytkowników.

Załóżmy, że tworzysz produkt SaaS i zamierzasz wdrożyć jego nową, fajną wersję. Przetestowałeś to podczas inscenizacji i zadziałało świetnie. Jednak nadal istnieją pewne obawy co do jej zachowania w rzeczywistych warunkach. Innymi słowy, musisz przetestować nową wersję na rzeczywistych problemach, nie narażając zaufania użytkowników. Wdrożenia Canary świetnie się do tego nadają. Umożliwiają zademonstrowanie nowej funkcji określonej grupie użytkowników. Podzbiór ten może składać się z najbardziej lojalnych użytkowników lub tych, którzy pracują z bezpłatną wersją produktu, lub użytkowników, którzy wyrazili chęć bycia „królikami doświadczalnymi”.

Siatki usług implementują to, umożliwiając określenie kryteriów określających, kto będzie widział którą wersję aplikacji, i odpowiednio kierowanie ruchu. Dla samych usług nic się jednak nie zmienia. Wersja 1.0 serwisu uważa, że wszystkie żądania pochodzą od użytkowników, którzy powinni go zobaczyć, a wersja 1.1 uważa to samo w przypadku swoich użytkowników. Tymczasem możesz zmienić procent ruchu pomiędzy starą i nową wersją, przekierowując coraz większą liczbę użytkowników do nowej, jeśli działa stabilnie, a Twoje „świnki morskie” dadzą zielone światło.

8. Wdrożenia niebiesko-zielone

TL; DR: Wprowadź nową, fajną funkcję, ale bądź przygotowany na natychmiastowe wycofanie wszystkiego.

Znaczenie wdrożenia niebiesko-zielone jest wdrożenie nowej usługi „niebieskiej”, uruchamiając ją równolegle ze starą, „zieloną”. Jeśli wszystko pójdzie gładko i nowa usługa będzie dobrze działać, to starą będzie można stopniowo wyłączać. (Niestety, pewnego dnia ta nowa „niebieska” usługa powtórzy los „zielonej” i zniknie...) Wdrożenia niebiesko-zielone różnią się od kanarek tym, że nowa funkcja obejmuje wszyscy na raz użytkownicy (nie część); Chodzi o to, aby mieć przygotowaną „bezpieczną przystań” na wypadek, gdyby coś poszło nie tak.

Siatki usług oferują bardzo wygodny sposób na przetestowanie „niebieskiej” usługi i natychmiastowe przejście na działającą „zieloną” w przypadku problemów. Nie wspominając już o tym, że po drodze dostarczają wielu informacji (patrz „Telemetria” poniżej) na temat pracy „niebieskiego”, co pomaga zrozumieć, czy jest on gotowy do pełnej pracy.

Notatka. przeł.: Możesz przeczytać więcej o różnych strategiach wdrażania w Kubernetesie (w tym wspomnianym kanarkowym, niebieskim/zielonym i innych) w ten artykuł.

9. Kontrola stanu zdrowia

TL; DR: Śledź, które instancje usług działają i reaguj na te, które już nie działają.

Kontrola zdrowia (Kontrola zdrowia) pomaga zdecydować, czy instancje usługi są gotowe do akceptowania i przetwarzania ruchu. Na przykład w przypadku usług HTTP kontrola stanu może wyglądać jak żądanie GET skierowane do punktu końcowego /health. Odpowiedź 200 OK będzie oznaczać, że instancja jest w dobrym stanie, a każda inna - że nie jest gotowa do odbierania ruchu. Siatki usług pozwalają określić zarówno sposób, w jaki będzie sprawdzana funkcjonalność, jak i częstotliwość, z jaką ta kontrola będzie przeprowadzana. Informacje te można następnie wykorzystać do innych celów – na przykład do równoważenia obciążenia i wyłączania obwodów.

Dlatego sprawdzanie stanu nie jest samodzielnym przypadkiem użycia, ale zwykle służy do osiągnięcia innych celów. Ponadto, w zależności od wyników kontroli stanu, mogą być wymagane działania zewnętrzne w stosunku do innych celów siatki usług: na przykład aktualizacja strony stanu, utworzenie problemu w GitHub lub wypełnienie zgłoszenia JIRA. Usługa mesh oferuje wygodny mechanizm automatyzacji tego wszystkiego.

10. Zrzucanie obciążenia

TL; DR: Przekierowuje ruch w odpowiedzi na tymczasowy wzrost wykorzystania.

Jeśli dana usługa jest przeciążona ruchem, możesz tymczasowo przekierować część tego ruchu w inne miejsce (czyli „zrzucić”, „przenieść” (szopa) go tam). Na przykład do usługi tworzenia kopii zapasowych lub centrum danych, albo do stałego miejsca prasa temat. W rezultacie usługa będzie nadal przetwarzać niektóre żądania, zamiast zawieszać się i całkowicie zatrzymywać przetwarzanie wszystkiego. Zrzucanie obciążenia jest lepsze niż przerywanie obwodu, ale nadal nie zaleca się jego nadużywania. Pomaga zapobiegać awariom kaskadowym powodującym awarię usług podrzędnych.

11. Równoległość/dublowanie ruchu

TL; DR: Wyślij jedno żądanie do kilku miejsc jednocześnie.

Czasami zachodzi potrzeba wysłania zapytania (lub określonego wyboru żądań) do kilku usług jednocześnie. Typowym przykładem jest wysyłanie części ruchu produkcyjnego do usługi pomostowej. Główny produkcyjny serwer WWW wysyła żądanie do usługi niższego szczebla products.production i tylko dla niego. A siatka usług inteligentnie kopiuje to żądanie i wysyła je do products.staging, o czym serwer WWW nawet nie jest świadomy.

Innym powiązanym przypadkiem użycia siatki usług, który można zaimplementować oprócz równoległości ruchu, jest testy regresyjne. Polega na wysyłaniu tych samych żądań do różnych wersji serwisu i sprawdzaniu, czy wszystkie wersje zachowują się tak samo. Nie spotkałem się jeszcze z implementacją siatki usług ze zintegrowanym systemem testów regresyjnych, np trudne, ale sam pomysł wydaje się obiecujący.

12. Izolacja

TL; DR: Podziel siatkę usług na minisieci.

Znany również jako segmentacjaIzolacja to sztuka dzielenia siatki usług na logicznie odrębne segmenty, które nic o sobie nie wiedzą. Izolacja przypomina trochę tworzenie wirtualnych sieci prywatnych. Podstawowa różnica polega na tym, że nadal możesz korzystać ze wszystkich zalet siatki usług (takich jak wykrywanie usług), ale z dodatkowymi zabezpieczeniami. Na przykład, jeśli atakującemu uda się przeniknąć do usługi w jednej podsieci, nie będzie mógł zobaczyć, jakie usługi działają w innych podsieciach, ani przechwycić ich ruchu.

Korzyści mogą mieć także charakter organizacyjny. Możesz podzielić swoje usługi na podsieci w oparciu o strukturę firmy i odciążyć programistów od obciążenia poznawczego związanego z koniecznością pamiętania o całej siatce usług.

13. Żądaj ograniczenia szybkości, ponownych prób i przekroczeń limitu czasu

TL; DR: Nie musisz już włączać do swojej bazy kodu szczegółowych zadań związanych z zarządzaniem żądaniami.

Wszystkie te rzeczy można uznać za oddzielne przypadki użycia, ale zdecydowałem się je połączyć ze względu na jedną wspólną cechę: przejmują zadania związane z zarządzaniem cyklem życia żądań, które zwykle są obsługiwane przez biblioteki aplikacji. Jeśli tworzysz serwer WWW w Ruby on Rails (niezintegrowany z siatką usług), który wysyła żądania do usług zaplecza za pośrednictwem gRPC, aplikacja będzie musiała zdecydować, co zrobić, jeśli N żądań zakończy się niepowodzeniem. Będziesz także musiał dowiedzieć się, jaki ruch będą w stanie przetworzyć te usługi, i zakodować te parametry na stałe, korzystając ze specjalnej biblioteki. Ponadto aplikacja będzie musiała zdecydować, kiedy należy się poddać i pozwolić, aby żądanie wygasło (w oparciu o limit czasu). Aby zmienić którykolwiek z powyższych parametrów, serwer WWW będzie musiał zostać zatrzymany, ponownie skonfigurowany i uruchomiony ponownie.

Przeniesienie tych zadań do siatki usług oznacza nie tylko, że twórcy usług nie będą musieli o nich myśleć, ale także że będzie można na nie spojrzeć w bardziej globalny sposób. Jeśli używany jest złożony łańcuch usług, powiedzmy A -> B -> C -> D -> E, należy wziąć pod uwagę cały cykl życia żądania. Jeśli zadaniem jest wydłużenie limitów czasu w usłudze C, logiczne jest, aby zrobić to wszystko na raz, a nie w częściach: aktualizując kod usługi i czekając, aż żądanie ściągnięcia zostanie zaakceptowane, a system CI wdroży zaktualizowaną usługę.

14. Telemetria

TL; DR: Zbierz wszystkie niezbędne (i nie do końca) informacje z usług.

Telemetria to termin ogólny obejmujący metryki, rozproszone śledzenie i dzienniki. Siatki usług oferują mechanizmy gromadzenia i przetwarzania wszystkich trzech typów danych. W tym miejscu sytuacja staje się nieco niejasna, ponieważ liczba możliwych opcji jest zbyt duża. Istnieje możliwość gromadzenia metryk Prometheus i inne narzędzia, które można wykorzystać do gromadzenia logów płynnie, Loki, wektor et al. (na przykład ClickHouse z naszym dom z bali dla K8s - ok. tłumacz.), w przypadku śledzenia rozproszonego istnieje Jaeger i tak dalej. Każda siatka usług może obsługiwać niektóre narzędzia, a inne nie. Ciekawe będzie, czy projekt będzie w stanie to osiągnąć Otwórz telemetrię zapewnić pewną zbieżność.

W tym przypadku zaletą technologii Service Mesh jest to, że kontenery z wózkiem bocznym mogą w zasadzie zbierać wszystkie powyższe dane ze swoich usług. Innymi słowy, masz do dyspozycji jeden system zbierania telemetrii, a siatka usług może przetwarzać wszystkie te informacje na różne sposoby. Na przykład:

logi ogonowe z określonej usługi w CLI;
monitoruj liczbę żądań z poziomu dashboardu Service Mesh;
zbieraj rozproszone ślady i przesyłaj je do systemu takiego jak Jaeger.

Uwaga, subiektywna ocena: Ogólnie rzecz biorąc, telemetria jest obszarem, w którym silne zakłócenia ze strony sieci usługowej są niepożądane. Gromadzenie podstawowych informacji i śledzenie na bieżąco niektórych złotych wskaźników, takich jak współczynnik powodzenia żądań i opóźnienia, jest w porządku, ale miejmy nadzieję, że nie pojawią się stosy Frankensteina próbujące zastąpić wyspecjalizowane systemy, z których część już się sprawdziła i jest dobrze zbadana .

15. Audyt

TL; DR: Ci, którzy zapominają lekcje historii, są skazani na ich powtarzanie.

Audyt to sztuka obserwacji ważnych zdarzeń w systemie. W przypadku siatki usług może to oznaczać śledzenie, kto wysłał żądania do określonych punktów końcowych w sprawie określonych usług lub ile razy w ciągu ostatniego miesiąca wystąpiło jakieś zdarzenie związane z bezpieczeństwem.

Oczywiste jest, że audyt jest bardzo ściśle powiązany z telemetrią. Różnica jest taka, że telemetria zwykle kojarzy się z produktywnością i integralnością techniczną, natomiast audyt może dotyczyć kwestii prawnych i innych, wykraczających poza sferę stricte techniczną (np. zgodności z RODO – ogólnym rozporządzeniem UE o ochronie danych).

16. Wizualizacja

TL;DR: Niech żyje React.js - niewyczerpane źródło fantazyjnych interfejsów.

Być może istnieje lepsze określenie, ale ja go nie znam. Mam na myśli po prostu graficzną reprezentację siatki usług lub niektórych jej komponentów. Te wizualizacje mogą obejmować wskaźniki, takie jak średnie opóźnienia, informacje o konfiguracji przyczepki, wyniki kontroli stanu i alerty.

Praca w środowisku zorientowanym na usługi wiąże się ze znacznie większym obciążeniem poznawczym w porównaniu do pracy Jego Królewskiej Mości Monolitu. Dlatego należy za wszelką cenę zmniejszyć presję poznawczą. Prosty interfejs graficzny siatki serwisowej z możliwością kliknięcia przycisku i uzyskania pożądanego rezultatu może zadecydować o wzroście popularności tej technologii.

Nie zostały ujęte na liście

Pierwotnie zamierzałem uwzględnić na liście jeszcze kilka przypadków użycia, ale potem zdecydowałem się tego nie robić. Oto one wraz z uzasadnieniem mojej decyzji:

Centrum wielu danych. Moim zdaniem nie jest to tyle przypadek użycia, co wąski i specyficzny obszar zastosowania siatek usług lub jakiś zestaw funkcji typu Service Discovery.
Wejście i wyjście. Jest to pokrewny obszar, ale ograniczyłem się (być może sztucznie) do przypadku użycia „ruchu wschód-zachód”. Wejście i wyjście zasługują na osobny artykuł.

wniosek

To wszystko na teraz! Ponownie, lista ta jest bardzo arbitralna i najprawdopodobniej niekompletna. Jeśli uważasz, że coś przeoczyłem lub pomyliłem, skontaktuj się ze mną na Twitterze (@luckerkins). Prosimy o przestrzeganie zasad przyzwoitości.

PS od tłumacza

Ilustracja tytułowa artykułu została oparta na obrazie z artykułu „Co to jest Service Mesh (i kiedy z niej korzystać)?„(przez Gregory'ego MacKinnona). Pokazuje, jak część funkcjonalności aplikacji (na zielono) została przeniesiona do siatki usług, która zapewnia połączenia między nimi (na niebiesko).

Przeczytaj także na naszym blogu:

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