Čo je to Service Mesh?

Ahoj znovu!.. V predvečer začiatku kurzu „Architekt softvéru“ sme pripravili ešte jeden užitočný preklad.

Service Mesh je konfigurovateľná infraštruktúra s nízkou latenciou, potrebná na spracovanie veľkého objemu sieťových medzi-procesových komunikácií medzi aplikačnými programovými rozhraniami (API). Service Mesh zaisťuje rýchlu, spoľahlivú a bezpečnú komunikáciu medzi kontajnerizovanými a často efemérnymi službami infraštruktúry aplikácií. Service Mesh ponúka funkcie ako objavovanie služieb, vyvažovanie záťaže, šifrovanie, transparentnosť, sledovanie, autentifikáciu a autorizáciu, ako aj podporu vzoru automatického vypnutia (circuit breaker).
Service Mesh sa zvyčajne implementuje poskytnutím inštancie proxy pre každý inštanciu služby, ktorá sa nazýva Sidecar. Sidecar spracováva komunikácie medzi službami, monitoruje a rieši bezpečnostné problémy, teda všetko, čo môže byť abstrahované od jednotlivých služieb. Takto môžu vývojári písať, udržiavať a spravovať kód aplikácie v službách, zatiaľ čo systémoví administrátori môžu pracovať so Service Mesh a spúšťať aplikáciu.

Istio od Google, IBM a Lyft je v súčasnosti najznámejšou architektúrou Service Mesh. Kubernetes, ktorý bol pôvodne vyvinutý v Google, je teraz jediným rámcom pre orchestru kontajnerov, ktorý je podporovaný Istio. Dodávatelia sa snažia vytvoriť komerčne podporované verzie Istio. Zaujímavé je, čo nové môžu priniesť do projektu s otvoreným zdrojovým kódom.

Avšak Istio nie je jedinou možnosťou, keďže sa vyvíjajú aj iné implementácie Service Mesh. Vzor sidecar proxy je najpopulárnejšou implementáciou, čo dokazujú projekty ako Buoyant, HashiCorp, Solo.io a ďalší. Existujú aj alternatívne architektúry: technologický nástroj Netflix je jedným z prístupov, kde sa funkčnosť Service Mesh realizuje pomocou knižníc Ribbon, Hysterix, Eureka, Archaius, ako aj takých platforiem ako Azure Service Fabric.

Service Mesh má tiež svoju vlastnú terminológiu pre komponenty služieb a funkcie:

• Rámec pre orchestru kontajnerov. Ako sa do infraštruktúry aplikácie pridáva stále viac a viac kontajnerov, vzniká potreba samostatného nástroja na monitorovanie a správu kontajnerov – rámca orchestrácie kontajnerov. Kubernetes si túto niku veľmi rýchlo zaujal, a to až tak, že dokonca jeho hlavní konkurenti Docker Swarm a Mesosphere DC/OS ponúkajú ako alternatívu integráciu s Kubernetes.
• Služby a pod instances (Kubernetes pody). Pod je jediná spustená kópia mikroservisu. Niekedy je jeden pod jedným kontajnerom. V Kubernetes je pod tvorený malou skupinou nezávislých kontajnerov, ktoré sa nazývajú pod. Klienti zriedkakedy komunikujú priamo s podom alebo instanciou, častejšie komunikujú so službou, ktorá predstavuje súbor identických, škálovateľných a odolných voči poruchám podov alebo instancií (replík).
• Sidecar Proxy. Sidecar Proxy pracuje s jedným podom alebo instanciou. Zmysel Sidecar Proxy spočíva v smerovaní alebo proxy trafiku prichádzajúceho od kontajnera, s ktorým pracuje, a spätného trafiku. Sidecar komunikuje s inými Sidecar Proxy a je riadený rámcom orchestrácie. Mnoho implementácií Service Mesh využíva Sidecar Proxy na zachytávanie a správu všetkého prichádzajúceho a odchádzajúceho trafiku podu alebo inštancie.
• Objavovanie služieb. Keď potrebuje pod komunikovať s inou službou, musí nájsť (objaviť) platnú a dostupnú inštanciu inej služby. Zvyčajne realizuje inštancia vyhľadávanie pomocou DNS. Rámec orchestrácie kontajnerov uchováva zoznam inštancií, ktoré sú pripravené na prijímanie požiadaviek, a poskytuje rozhranie na DNS dotazy.
• Vyvažovanie záťaže. Väčšina rámcov orchestrácie kontajnerov zabezpečuje vyváženie záťaže na 4. úrovni (transportnej). Service Mesh realizuje zložitejšie vyváženie záťaže na 7. úrovni (aplikovanej), bohaté na algoritmy a účinnejšie pri správe traffiku. Parametre vyvažovania záťaže môžu byť menené pomocou API, čo umožňuje orchestráciu blue-green alebo canary nasadenia.
• ŠifrovanieService Mesh môže šifrovať a dešifrovať požiadavky a odpovede, čím znižuje túto záťaž z služieb. Service Mesh môže tiež zvýšiť výkon prioritizovaním alebo opätovným využívaním existujúcich trvalých pripojení, čo znižuje potrebu nákladných výpočtov na vytváranie nových pripojení. Najbežnejšou realizáciou šifrovania prenášaných údajov je vzájomný TLS (mTLS), kde infraštruktúra verejných kľúčov (PKI) generuje a distribuuje certifikáty a kľúče na ich použitie v Sidecar Proxy.
• Autentifikácia a autorizácia. Service Mesh môže autorizovať a autentifikovať požiadavky, ktoré prichádzajú zvonku alebo zvnútra aplikácie, posielajúc inštanciám iba overené požiadavky.
• Podpora vzoru automatického odstavenia. Service Mesh podporuje vzorec automatického odstavenia, ktorý izoluje nezdravé inštancie a potom ich postupne vracia do skupiny zdravých inštancií, keď je to potrebné.

Časť aplikácie Service Mesh, ktorá spravuje sieťový prenos medzi inštanciami, sa nazýva Data Plane. Vytvorenie a nasadenie konfigurácie, ktorá riadi správanie Data Plane, sa realizuje pomocou samostatnej Control Plane. Control Plane zvyčajne zahŕňa alebo je navrhnutá tak, aby sa pripájala k API, CLI alebo GUI na správu aplikácie.

Ovládacia rovina v Service Mesh distribuuje konfiguráciu medzi Sidecar Proxy a dátovou rovinou.

Architektúra Service Mesh sa často používa na riešenie zložitých operačných úloh s využitím kontajnerov a mikroslužieb. Priekopníkmi v oblasti mikroslužby sú také spoločnosti ako Lyft, Netflix a Twitter, ktoré poskytujú stabilne fungujúce služby miliónom používateľov po celom svete. (Tu sa môžete oboznámiť s podrobným popisom niektorých architektonických výziev, ktorým čelil Netflix). Pre menej náročné aplikačné úlohy bude pravdepodobne stačiť jednoduchšia architektúra.

Architektúra Service Mesh pravdepodobne nikdy nebude odpoveďou na všetky otázky týkajúce sa fungovania aplikácií a ich dodávky. Architekti a vývojári disponujú obrovským arzenálom nástrojov, a jeden z nich je kladivo, ktoré by malo medzi mnohými úlohami slúžiť len na jednu – zatĺkanie klincov. Architektúra mikroservisov od NGINX, napríklad, zahŕňa niekoľko rôznych modelov, ktoré ponúkajú nepretržitý spektrogram prístupov k riešeniu úloh pomocou mikroservisov.

Elementy, ktoré sa spájajú v architektúre Service Mesh, ako NGINX, kontajnery, Kubernetes a mikroservisy ako architektonický prístup, môžu byť rovnako produktívne použité aj v implementáciách bez Service Mesh. Napríklad Istio bolo navrhnuté ako plne funkčná architektúra Service Mesh, ale modulárnosť naznačuje, že vývojári si môžu vyberať a implementovať iba komponenty technológií, ktoré potrebujú. S týmto na pamäti je potrebné vytvoriť jasné pochopenie konceptu Service Mesh, aj keď si nie ste istí, že ho niekedy plne implementujete v aplikácii.

Modulárne monolity a DDD

Zdroj: habr.com