Service Mesh to dobrze znany wzorzec architektoniczny służący do integracji mikroserwisów i migracji do infrastruktury chmurowej. Dziś w świecie kontenerów chmurowych dość trudno się bez niego obejść. Na rynku dostępnych jest już kilka wdrożeń service mesh o otwartym kodzie źródłowym, jednak ich funkcjonalność, niezawodność i bezpieczeństwo nie zawsze są wystarczające, szczególnie jeśli chodzi o wymagania dużych firm finansowych w całym kraju. Dlatego w Sbertech zdecydowaliśmy się dostosować Service Mesh i chcemy porozmawiać o tym, co jest fajnego w Service Mesh, co nie jest fajne i co zamierzamy z tym zrobić.
Popularność wzorca Service Mesh rośnie wraz z popularnością technologii chmurowych. Jest to dedykowana warstwa infrastruktury, która upraszcza interakcję pomiędzy różnymi usługami sieciowymi. Nowoczesne aplikacje chmurowe składają się z setek, a nawet tysięcy takich usług, z których każda może mieć tysiące kopii.
Interakcja pomiędzy tymi usługami i zarządzanie nimi jest kluczowym zadaniem Service Mesh. Tak naprawdę jest to model sieciowy wielu serwerów proxy, zarządzany centralnie i realizujący zestaw bardzo przydatnych funkcji.
Na poziomie proxy (płaszczyzna danych):
- Przypisywanie i dystrybucja polityk routingu i równoważenia ruchu
- Dystrybucja kluczy, certyfikatów, tokenów
- Zbieranie telemetrii, generowanie metryk monitoringowych
- Integracja z infrastrukturą bezpieczeństwa i monitoringu
Na poziomie płaszczyzny sterowania:
- Stosowanie zasad routingu i równoważenia ruchu
- Zarządzanie ponownymi próbami i przekroczeniami limitów czasu, wykrywanie „martwych” węzłów (przerwanie obwodu), zarządzanie wstrzykiwaniem błędów i zapewnianie odporności usług za pomocą innych mechanizmów
- Uwierzytelnianie/autoryzacja połączeń
- Upuszczanie wskaźników (obserwowalność)
Krąg użytkowników zainteresowanych rozwojem tej technologii jest bardzo szeroki – od małych startupów po duże korporacje internetowe, np. PayPal.
Dlaczego Service Mesh jest potrzebny w sektorze korporacyjnym?
Korzystanie z Service Mesh ma wiele wyraźnych korzyści. Przede wszystkim jest to po prostu wygodne dla programistów: do pisania kodu pojawia się platforma technologiczna, co znacząco ułatwia integrację z infrastrukturą chmurową ze względu na całkowite odizolowanie warstwy transportowej od logiki aplikacji.
RљSЂRѕRјRμ S, RѕRіRѕ, Service Mesh upraszcza relacje pomiędzy dostawcami i konsumentami. Dziś dostawcom API i konsumentom znacznie łatwiej jest samodzielnie uzgadniać interfejsy i umowy, bez angażowania specjalnego pośrednika i arbitra integracyjnego – korporacyjnej magistrali usług. Takie podejście znacząco wpływa na dwa wskaźniki. Zwiększa się szybkość wprowadzania nowej funkcjonalności na rynek (time-to-market), ale jednocześnie wzrasta koszt rozwiązania, ponieważ integracja musi zostać przeprowadzona niezależnie. Wykorzystanie Service Mesh przez zespoły zajmujące się rozwojem funkcjonalności biznesowych pomaga zachować tutaj równowagę. Dzięki temu dostawcy API mogą skupić się wyłącznie na komponencie aplikacyjnym swojej usługi i po prostu opublikować go w Service Mesh – API będzie od razu dostępne dla wszystkich klientów, a jakość integracji będzie gotowa do produkcji i nie będzie wymagała ani jednej linia dodatkowego kodu.
Następną zaletą jest to deweloper korzystając z Service Mesh skupia się wyłącznie na funkcjonalności biznesowej — na produkcie, a nie na technologicznym elemencie usługi. Nie musisz już na przykład myśleć o tym, że w sytuacji wywołania usługi przez sieć, gdzieś może nastąpić awaria połączenia. Ponadto Service Mesh pomaga zrównoważyć ruch pomiędzy kopiami tej samej usługi: jeśli jedna z kopii „umrze”, system przełączy cały ruch na pozostałe działające kopie.
Siatka serwisowa - jest to dobra podstawa do tworzenia aplikacji rozproszonych, która ukrywa przed klientem szczegóły realizacji połączeń do swoich usług zarówno wewnętrznie, jak i zewnętrznie. Wszystkie aplikacje korzystające z Service Mesh są odizolowane na poziomie transportu zarówno od sieci, jak i od siebie: nie ma między nimi komunikacji. W tym przypadku deweloper otrzymuje pełną kontrolę nad swoimi usługami.
Należy zauważyć że Aktualizowanie aplikacji rozproszonych w środowisku siatki usług staje się łatwiejsze. Na przykład wdrożenie niebiesko-zielone, w którym do instalacji dostępne są dwa środowiska aplikacji, z których jedno nie jest aktualizowane i znajduje się w trybie gotowości. Powrót do poprzedniej wersji w przypadku nieudanego wydania odbywa się za pomocą specjalnego routera, z którego rolą Service Mesh świetnie sobie radzi. Aby przetestować nową wersję, możesz użyć uwolnienie kanarków — przejdź na nową wersję tylko 10% ruchu lub żądań od pilotażowej grupy klientów. Główny ruch idzie do starej wersji, nic się nie psuje.
również Service Mesh zapewnia nam kontrolę SLA w czasie rzeczywistym. Rozproszony system proxy nie pozwoli na awarię usługi, gdy jeden z klientów przekroczy przypisany mu limit. Jeśli przepustowość API będzie ograniczona, nikt nie będzie w stanie jej przytłoczyć dużą liczbą transakcji: Service Mesh stoi naprzeciw usługi i nie pozwala na niepotrzebny ruch. Po prostu będzie walczyć w warstwie integracyjnej, a same usługi będą dalej działać, nawet tego nie zauważając.
Jeśli firma chce obniżyć koszty rozwoju rozwiązań integracyjnych, Service Mesh pomaga również: Możesz przejść na wersję open source z produktów komercyjnych. Nasza Enterprise Service Mesh opiera się na otwartej wersji Service Mesh.
Kolejna zaleta - dostępność jednego, pełnego zestawu usług integracyjnych. Ponieważ cała integracja opiera się na tym oprogramowaniu pośrednim, możemy zarządzać całym ruchem integracyjnym i połączeniami pomiędzy aplikacjami, które stanowią rdzeń biznesowy firmy. To jest bardzo wygodne.
I wreszcie Service Mesh zachęca firmę do przejścia na dynamiczną infrastrukturę. Obecnie wiele osób patrzy w stronę konteneryzacji. Krojenie monolitu na mikroserwisy, pięknie to wszystko realizując - temat rośnie. Kiedy jednak próbujesz przenieść system, który jest w produkcji od wielu lat, na nową platformę, od razu napotykasz szereg problemów: wepchnięcie tego wszystkiego do kontenerów i wdrożenie na platformie nie jest łatwe. Implementacja, synchronizacja i interakcja tych rozproszonych komponentów to kolejny bardzo złożony temat. Jak będą się ze sobą komunikować? Czy będą kaskadowe awarie? Service Mesh pozwala rozwiązać część tych problemów i ułatwić migrację ze starej architektury na nową dzięki temu, że można zapomnieć o logice wymiany sieciowej.
Dlaczego potrzebujesz dostosowania Service Mesh?
W naszej firmie współistnieją setki systemów i modułów, a środowisko uruchomieniowe jest bardzo obciążone. Zatem prosty schemat, w którym jeden system wywołuje drugi i otrzymuje odpowiedź, nie wystarczy, ponieważ na produkcji chcemy więcej. Czego jeszcze potrzebujesz od siatki usług dla przedsiębiorstw?
Usługa przetwarzania zdarzeń
Wyobraźmy sobie, że potrzebujemy przetwarzania zdarzeń w czasie rzeczywistym – systemu, który analizuje działania klienta w czasie rzeczywistym i może od razu przedstawić mu odpowiednią ofertę. Aby zaimplementować podobną funkcjonalność, użyj wzorzec architektoniczny zwany architekturą sterowaną zdarzeniami (EDA). Żadna z obecnych Service Meshes natywnie nie obsługuje takich wzorców, ale jest to bardzo ważne, zwłaszcza dla banku!
To dość dziwne, że zdalne wywoływanie procedur (RPC) jest obsługiwane przez wszystkie wersje Service Mesh, ale nie są one przyjazne dla EDA. Ponieważ Service Mesh jest rodzajem nowoczesnej rozproszonej integracji, a EDA jest bardzo odpowiednim wzorcem architektonicznym, który pozwala robić unikalne rzeczy pod względem doświadczenia klienta.
Nasza siatka usług korporacyjnych powinna rozwiązać ten problem. Dodatkowo chcemy w nim zobaczyć realizację gwarantowanej dostawy, streamingu i kompleksowego przetwarzania zdarzeń z wykorzystaniem różnorodnych filtrów i szablonów.
Usługa przesyłania plików
Oprócz EDA miło byłoby móc przesyłać pliki: w skali korporacyjnej bardzo często możliwa jest tylko integracja plików. W szczególności wykorzystywany jest wzorzec architektoniczny ETL (Extract, Transform, Load). Z reguły wszyscy wymieniają się w nim wyłącznie plikami: wykorzystywane są duże zbiory danych, co niepraktyczne jest przesyłanie oddzielnych żądań. Możliwość natywnej obsługi transferu plików w Enterprise Service Mesh zapewnia elastyczność potrzebną Twojej firmie.
Usługa orkiestracji
Duże organizacje prawie zawsze mają różne zespoły wytwarzające różne produkty. Np. w banku jedne zespoły pracują z depozytami, inne z produktami kredytowymi, a takich przypadków jest całkiem sporo. To różni ludzie, różne zespoły, które tworzą swoje produkty, rozwijają swoje API i udostępniają je innym. Bardzo często istnieje potrzeba komponowania tych usług, a także implementowania złożonej logiki do sekwencyjnego wywoływania zestawu API. Aby rozwiązać ten problem, potrzebne jest rozwiązanie w warstwie integracji, które uprości całą tę złożoną logikę (wywołanie kilku API, opisanie trasy żądania itp.). Jest to usługa orkiestracji w Enterprise Service Mesh.
Sztuczna inteligencja i uczenie maszynowe
Kiedy mikrousługi komunikują się za pośrednictwem pojedynczej warstwy integracji, Service Mesh w naturalny sposób wie wszystko o wywołaniach każdej usługi. Zbieramy dane telemetryczne: kto do kogo dzwonił, kiedy, jak długo, ile razy i tak dalej. Kiedy takich usług są setki tysięcy i miliardy połączeń, wszystko to kumuluje się i tworzy Big Data. Dane te można analizować za pomocą sztucznej inteligencji, uczenia maszynowego itp., a następnie na podstawie wyników analizy można zrobić kilka przydatnych rzeczy. Wypadałoby choć częściowo oddać kontrolę nad całym tym ruchem sieciowym i wywołaniami aplikacji zintegrowanymi z Service Mesh sztucznej inteligencji.
Usługa bramy API
Zazwyczaj Service Mesh ma serwery proxy i usługi, które komunikują się ze sobą w zaufanym obwodzie. Ale są też kontrahenci zewnętrzni. Wymagania stawiane API eksponowanym dla tej grupy konsumentów są znacznie bardziej rygorystyczne. Zadanie to dzielimy na dwie główne części.
- bezpieczeństwo. Problemy związane z ddos, podatnością protokołów, aplikacji, systemów operacyjnych i tak dalej.
- Waga. Kiedy liczba interfejsów API, które należy udostępnić klientom, sięga tysięcy, a nawet setek tysięcy, pojawia się zapotrzebowanie na pewnego rodzaju narzędzie do zarządzania dla tego zestawu interfejsów API. Musisz stale monitorować API: czy działają, czy nie, jaki jest ich status, jaki przepływa ruch, jakie statystyki itp. Brama API powinna obsłużyć to zadanie, zapewniając jednocześnie łatwość zarządzania i bezpieczeństwo całego procesu. Dzięki temu komponentowi Enterprise Service Mesh uczy się łatwo publikować zarówno wewnętrzne, jak i zewnętrzne API.
Usługa wsparcia dla określonych protokołów i formatów danych (bramka AS)
Obecnie większość rozwiązań Service Mesh może pracować natywnie jedynie z ruchem HTTP i HTTP2 lub w trybie ograniczonym na poziomie TCP/IP. Pojawia się sieć Enterprise Service Mesh z wieloma innymi, bardzo specyficznymi protokołami przesyłania danych. Niektóre systemy mogą korzystać z brokerów komunikatów, inne są zintegrowane na poziomie bazy danych. Jeśli firma posiada SAP, to może także skorzystać z własnego systemu integracyjnego. Co więcej, wszystko to działa i jest ważną częścią biznesu.
Nie można po prostu powiedzieć: „Porzućmy dziedzictwo i stwórzmy nowe systemy, które będą mogły korzystać z Service Mesh”. Aby połączyć wszystkie stare systemy z nowymi (w architekturze mikroserwisowej), systemy, które mogą korzystać z Service Mesh, będą potrzebować jakiegoś adaptera, pośrednika, bramy. Zgadzam się, byłoby miło, gdyby przyszedł w pudełku wraz z usługą. Bramka AC może obsługiwać dowolną opcję integracji. Wyobraź sobie, że po prostu instalujesz Enterprise Service Mesh i jest on gotowy do interakcji ze wszystkimi potrzebnymi protokołami. To podejście jest dla nas bardzo ważne.
Tak mniej więcej wyobrażamy sobie korporacyjną wersję Service Mesh (Enterprise Service Mesh). Opisana personalizacja rozwiązuje większość problemów, które pojawiają się przy próbie wykorzystania gotowych wersji platformy integracyjnej o otwartym kodzie źródłowym. Wprowadzona zaledwie kilka lat temu architektura Service Mesh wciąż ewoluuje i cieszymy się, że możemy przyczynić się do jej rozwoju. Mamy nadzieję, że nasze doświadczenie będzie dla Państwa przydatne.
Źródło: www.habr.com