Service Mesh to znany wzorzec architektoniczny do integracji mikrousług i przejścia na infrastrukturę chmurową. Obecnie w świecie chmur i kontenerów trudno obejść się bez niego. Na rynku dostępne są już różne otwarte realizacje service mesh, ale ich funkcjonalność, niezawodność i bezpieczeństwo nie zawsze są wystarczające, zwłaszcza gdy mowa o wymaganiach dużych firm finansowych o krajowym zasięgu. Dlatego w Sbertech postanowiliśmy dostosować Service Mesh i chcemy opowiedzieć o tym, co w Service Mesh jest świetne, co niekoniecznie, oraz o tym, co zamierzamy z tym zrobić.
Popularność wzorca Service Mesh rośnie wraz z rosnącą popularnością technologii chmurowych. Jest to wyodrębniona warstwa infrastrukturalna, która upraszcza interakcje mię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 między tymi usługami i ich zarządzanie to kluczowe zadania Service Mesh. W praktyce jest to model sieciowy składający się z wielu proxy, zarządzany centralnie i wykonujący zestaw bardzo przydatnych funkcji.
Na poziomie proxy (data plane):
- Przypisanie i rozdzielanie polityk routingu oraz równoważenia obciążenia
- Dystrybucja kluczy, certyfikatów, tokenów
- Zbieranie telemetryki, generowanie metryk monitorowania
- Integracja z infrastrukturą zabezpieczeń i monitoringu
Na poziomie kontrolera (control plane):
- Wdrażanie polityk routingu i równoważenia obciążenia
- Zarządzanie powtórzeniami i limitami czasu, identyfikacja 'martwych' węzłów (circuit breaking), zarządzanie sytuacjami awaryjnymi (injecting faults) oraz zapewnianie odporności (resilience) usług poprzez inne mechanizmy
- Autoryzacja/uwierzytelnienie wywołań
- Odrzucanie metryk (observability)
Krąg użytkowników zainteresowanych rozwojem tej technologii jest bardzo szeroki — od niewielkich startupów po duże korporacje internetowe, takie jak PayPal.
Jakie jest zastosowanie Service Mesh w sektorze korporacyjnym
Wykorzystanie Service Mesh przynosi wiele oczywistych korzyści. Przede wszystkim jest to bardzo wygodne dla programistów: do pisania kodu powstaje platforma technologiczna, co znacznie upraszcza integrację z chmurą, ponieważ warstwa transportowa jest całkowicie oddzielona od logiki aplikacji.
Ponadto, Service Mesh upraszcza relacje między dostawcami a konsumentami. Dziś dostawcom i konsumentom API znacznie łatwiej jest ustalić interfejsy i kontrakty samodzielnie, bez angażowania specjalnego pośrednika integracyjnego i arbitra – korporacyjnej szyny usług. Taka strategia ma znaczący wpływ na dwa wskaźniki. Przyspiesza czas wprowadzenia nowej funkcjonalności na rynek (time-to-market), ale jednocześnie zwiększa koszt rozwiązania, ponieważ integrację trzeba przeprowadzać samodzielnie. Użycie Service Mesh przez zespoły deweloperskie funkcjonalności biznesowej pozwala zachować równowagę. Ostatecznie dostawcy API mogą skupić się wyłącznie na aplikacyjnej części swojego serwisu i po prostu opublikować go w Service Mesh – API stanie się dostępne dla wszystkich klientów, a jakość integracji będzie gotowa do produkcji i nie wymaga żadnej dodatkowej linii kodu.
Następną zaletą jest to, że deweloper, korzystając z Service Mesh, skupia się wyłącznie na funkcjonalności biznesowej — na aspekcie produktowym, a nie technologicznym swojego serwisu. Na przykład, nie ma już potrzeby martwić się o to, że w sytuacji, gdy usługa jest wywoływana przez sieć, gdzieś może wystąpić przerwa w połączeniu. Ponadto, Service Mesh pomaga zrównoważyć ruch pomiędzy kopiami tej samej usługi: jeśli jedna z kopii "umarła", system przekieruje cały ruch na pozostałe aktywne kopie.
Service Mesh — to solidna podstawa do budowy rozproszonych aplikacji, która ukrywa przed klientem szczegóły zapewnienia wywołań jego usług zarówno wewnętrznie, jak i zewnętrznie. Wszystkie aplikacje korzystające z Service Mesh są na poziomie transportowym odizolowane zarówno od sieci, jak i od siebie nawzajem: nie ma między nimi żadnego połączenia. Przy tym deweloper uzyskuje pełną kontrolę nad swoimi usługami.
Nie można nie zauważyć, że aktualizacja rozproszonych aplikacji w środowisku, w którym stosuje się Service Mesh, staje się prostsza. Na przykład, wdrożenie typu blue/green, w którym dostępne są dwa środowiska aplikacji, z których jedno nie jest aktualizowane i pozostaje w trybie oczekiwania. Przywracanie wcześniejszej wersji w przypadku nieudanego wydania odbywa się za pomocą specjalnego routera, z zadaniem którego doskonale radzi sobie Service Mesh.. Do testowania nowej wersji można również wykorzystać wydanie kanaryjne — przekierowanie na nową wersję tylko 10% ruchu lub zapytań od pilotowej grupy klientów. Główny ruch kierowany jest do starej wersji, nic nie ulega awarii.
Również Service Mesh daje nam kontrolę nad SLA w czasie rzeczywistym. System rozproszonych proxy nie pozwoli na przeciążenie usługi, gdy któryś z klientów przekroczy przyznany mu limit. Jeśli przepustowość API jest ograniczona, nikt nie będzie mógł dodać dodatkowych obciążeń: Service Mesh stoi przed usługą i nie wpuszcza zbędnego ruchu. Po prostu będzie odpierać ataki na poziomie integracji, a same usługi będą działać, nie zauważając tego.
Jeśli firma chce zredukować koszty rozwoju rozwiązań integracyjnych, Service Mesh również w tym pomaga: można przejść na jego wersję open-source z produktów komercyjnych.Nasza Enterprise Service Mesh opiera się na wersji open-source Service Mesh.
Kolejną zaletą jest posiadanie jednego, pełnowartościowego zestawu usług integracyjnych. Ponieważ cała integracja odbywa się przez tę warstwę pośrednią, możemy zarządzać całym ruchem integracyjnym i relacjami między aplikacjami, które tworzą rdzeń biznesowy firmy. To bardzo wygodne.
I wreszcie Service Mesh pobudza firmę do przejścia na dynamiczną infrastrukturę. Obecnie wiele osób zwraca uwagę na konteneryzację. Rozdzielanie monolitu na mikroserwisy i ich eleganckie wdrażanie to trend, który zyskuje na znaczeniu. Jednak gdy próbujesz przenieść na nowe tory system, który jest już od lat w produkcji, napotykasz szereg problemów: wprowadzenie wszystkiego do kontenerów i uruchomienie na platformie jest trudne. A implementacja, synchronizacja i interakcja tych rozproszonych komponentów to kolejny bardzo złożony temat. Jak będą się komunikować? Czy nie dojdzie do kaskadowych awarii? Service Mesh pozwala rozwiązać część tych problemów i ułatwia migrację ze starej architektury na nową, ponieważ można zapomnieć o logice wymiany sieciowej.
Po co potrzebna jest personalizacja Service Mesh
W naszej firmie współdziała setki systemów i modułów, a runtime jest bardzo obciążony. Dlatego prosta zasada, w której jeden system wywołuje drugi i otrzymuje odpowiedź, nie jest wystarczająca, ponieważ w produkcji oczekujemy więcej. Czego jeszcze potrzebujemy od korporacyjnego Service Mesh?
Usługa przetwarzania zdarzeń
Załóżmy, że musimy stworzyć system przetwarzania zdarzeń w czasie rzeczywistym - system, który w czasie rzeczywistym analizuje działania klienta i może od razu przedstawić mu odpowiednią ofertę. Aby zrealizować taką funkcjonalność, używa się wzoru architektonicznego o nazwie architektura oparta na zdarzeniach (EDA). Żaden z aktualnych Service Mesh nie obsługuje takich wzorów natywnie, a to bardzo ważne, zwłaszcza dla banku!
Dość dziwne, że »zdalne wywołanie« zdalnego wywołania procedur (RPC) obsługują wszystkie wersje Service Mesh, a z EDA nie mogą się zaprzyjaźnić. Ponieważ Service Mesh jest podobne do nowoczesnej rozproszonej integracji, a EDA to bardzo aktualny wzór architektoniczny, który pozwala na realizację unikalnych doświadczeń klienta.
Nasz Enterprise Service Mesh powinien rozwiązać ten problem. Poza tym chcemy widzieć w nim realizację gwarantowanej dostawy, przetwarzania zdarzeń strumieniowych i kompleksowego z wykorzystaniem różnych filtrów i szablonów.
Usługa przesyłania plików
Oprócz EDA dobrze byłoby mieć możliwość przesyłania plików: w skali Enterprise bardzo często możliwa jest tylko integracja plikowa. W szczególności stosowany jest wzorzec architektoniczny ETL (Extract, Transform, Load — „wyodrębnianie, przekształcanie, ładowanie”). Z reguły wszystko wymienia się wyłącznie za pomocą plików: wykorzystuje się duże dane, których nieopłacalne jest wprowadzać pojedynczymi zapytaniami. Natywne wsparcie dla przesyłania plików w Enterprise Service Mesh daje niezbędną elastyczność dla biznesu.
Usługa orkiestracji
W dużych organizacjach prawie zawsze istnieją różne zespoły, które tworzą różne produkty. Na przykład w banku jedne zespoły pracują nad depozytami, a inne nad produktami kredytowymi, i takich przypadków jest całkiem sporo. To różni ludzie, różne zespoły, które tworzą swoje produkty, rozwijają swoje API i oferują je innym. Bardzo często pojawia się potrzeba kompozycji tych usług oraz implementacji złożonej logiki sekwencyjnego wywołania zestawu API. Aby rozwiązać ten problem, potrzebne jest rozwiązanie w warstwie integracyjnej, które uprości całą tę kompozycyjną logikę (wywołanie kilku API, opis trasy zapytań itd.). To właśnie jest usługa orkiestracji w Enterprise Service Mesh.
AI i ML
Kiedy mikrousługi komunikują się przez jedną warstwę integracyjną, Service Mesh naturalnie wie wszystko o wywołaniach każdej usługi. Zbieramy telemetrię: kto kogo wywoływał, kiedy, jak długo, ile razy itd. Gdy tych usług jest setki tysięcy, a wywołań miliardy, wszystko to gromadzi się i tworzy Big Data. Te dane można przeanalizować za pomocą AI, uczenia maszynowego itd., a następnie na podstawie wyników analizy zrobić coś przydatnego. Byłoby odpowiednie, aby przynajmniej częściowo przekazać sztucznej inteligencji zarządzanie całym tym ruchem sieciowym i wywołaniami aplikacji zintegrowanych w Service Mesh.
Usługa API Gateway (Brama API)
Z reguły w Service Mesh znajdują się proxy i usługi, które komunikują się ze sobą wewnątrz zaufanej strefy. Ale istnieją także zewnętrzni kontrahenci. Wymagania dotyczące API dostarczanych tej grupie konsumentów są znacznie poważniejsze. To zadanie dzielimy na dwie główne części.
- Bezpieczeństwo. Pytania związane z DDoS, podatnościami protokołów, aplikacji, systemów operacyjnych itd.
- Skala. Kiedy liczba interfejsów API, które należy przekazać klientom, sięga tysięcy lub nawet setek tysięcy, pojawia się potrzeba narzędzia do zarządzania tym zestawem API. Należy stale monitorować API: czy działają, w jakim są stanie, jaki jest ruch, jakie są statystyki itp. Brama API musi radzić sobie z tym zadaniem, czyniąc cały proces zarządzanym i bezpiecznym. Dzięki temu komponentowi Enterprise Service Mesh uczy się publikować zarówno wewnętrzne, jak i zewnętrzne API bez zbędnych komplikacji.
Usługa wsparcia specyficznych protokołów i formatów danych (brama AS)
Na chwilę obecną większość rozwiązań Service Mesh potrafi natywnie obsługiwać tylko ruch HTTP i HTTP2 lub w ograniczonym trybie na poziomie TCP/IP. Enterprise Service Mesh wprowadza wiele innych, dość specyficznych protokołów przesyłania danych. Niektóre systemy mogą używać brokerów wiadomości, inne są zintegrowane na poziomie baz danych. Jeśli w firmie jest SAP, to również może on korzystać z własnego systemu integracji. A wszystko to działa i stanowi ważną część biznesu.
Nie można po prostu powiedzieć: „Zrezygnujmy ze starszych systemów i stwórzmy nowe, które będą mogły korzystać z Service Mesh”. Aby połączyć wszystkie stare systemy z nowymi (opartymi na architekturze mikroserwisowej), systemy, które mogą korzystać z Service Mesh, potrzebują jakiegoś adaptera, pośrednika, bramy. Zgodzić się można, że byłoby dobrze, gdyby był dostarczany razem z usługą. Brama AS może wspierać każdy wariant integracji. Wyobraźcie sobie, że po prostu instalujecie Enterprise Service Mesh i jest już gotowy do interakcji ze wszystkimi protokołami, których potrzebujecie. Takie podejście jest dla nas bardzo ważne.
Właśnie tak 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 korzystania z gotowych wersji open-source platformy integracyjnej. Pojawiwszy się zaledwie kilka lat temu, architektura Service Mesh wciąż się rozwija, a my cieszymy się, że możemy przyczynić się do jej rozwoju. Mamy nadzieję, że nasze doświadczenie okaże się dla Was przydatne.
Źródło: habr.com
