Jedným z posunov v IT pod hlavičkou digitálnej transformácie je rozpad veľkých monolitických aplikácií na mikroslužby.—malé, diskrétne jednotky funkčnosti - ktoré bežia v kontajneroch—softvérové balíčky, ktoré obsahujú všetok kód služby a závislosti, ktoré je možné izolovať a ľahko presunúť z jedného servera na druhý.
Kontejnerizované architektúry, ako sú tieto, sa dajú ľahko zväčšiť a spustiť v cloude a jednotlivé mikroslužby je možné rýchlo zaviesť a opakovať. Komunikácia medzi týmito mikroslužbami sa však stáva čoraz zložitejšou, pretože aplikácie sa zväčšujú a súčasne beží viac inštancií tej istej služby. Servisná sieť je nastupujúca architektonická forma, ktorej cieľom je dynamické prepojenie týchto mikroslužieb spôsobom, ktorý znižuje réžiu správy a programovania.
Čo je sieť služieb?
V najširšom slova zmysle je sieť služieb, ako ju popisuje Red Hat, „spôsob riadenia toho, ako rôzne časti aplikácie navzájom zdieľajú údaje.“ Tento popis by však mohol obsahovať veľa rôznych vecí. V skutočnosti to znie strašne ako middleware, ktorý väčšina vývojárov pozná z aplikácií klient-server.
Vďaka čomu je služba mesh jedinečná, je to, že je postavená tak, aby vyhovovala jedinečnej povahe distribuovaných prostredí mikroslužieb. V rozsiahlej aplikácii zostavenej z mikroslužieb môže existovať viac inštancií akejkoľvek danej služby, ktoré bežia na rôznych miestnych alebo cloudových serveroch. Všetky tieto pohyblivé časti očividne sťažujú jednotlivým mikroslužbám nájsť ďalšie služby, s ktorými potrebujú komunikovať. Sieť služieb sa automaticky stará o objavovanie a prepájanie služieb z času na čas, aby to nemuseli robiť ani ľudskí vývojári, ani jednotlivé mikroslužby.
Predstavte si sieť služieb ako ekvivalent softvérovo definovaných sietí (SDN) pre úroveň 7 sieťového modelu OSI. Rovnako ako SDN vytvára vrstvu abstrakcie, aby správcovia siete nemuseli riešiť fyzické sieťové pripojenia, sieť služieb oddelí základnú infraštruktúru aplikácie od abstraktnej architektúry, s ktorou interagujete.
Myšlienka siete služieb vznikla organicky, keď sa vývojári začali vyrovnávať s problémami skutočne obrovských distribuovaných architektúr. Linkerd, prvý projekt v tejto oblasti, sa zrodil ako odnož interného projektu na Twitteri. Istio, ďalšia populárna sieť služieb s hlavnou firemnou podporou, vznikla v spoločnosti Lyft. (Obom týmto projektom sa za chvíľu pozrieme podrobnejšie.)
Vyvažovanie záťaže sieťou služieb
Jednou z kľúčových funkcií, ktorú poskytuje sieť služieb, je vyrovnávanie zaťaženia. Vyvažovanie záťaže zvyčajne považujeme za sieťovú funkciu - chcete zabrániť tomu, aby ktorýkoľvek server alebo sieťové spojenie bolo zahltené prenosom, a preto budete podľa toho smerovať svoje pakety. Servisné siete robia niečo podobné na aplikačnej úrovni, ako popisuje Twain Taylor, a porozumenie, ktoré vám dá dobrý pocit z toho, čo máme na mysli, keď hovoríme, že sieť služieb je ako softvérovo definované sieťovanie pre aplikačnú vrstvu.
Jednou z úloh siete služieb je v podstate sledovať, ktoré inštancie rôznych mikroslužieb distribuovaných v rámci infraštruktúry sú „najzdravšie“. Môže ich vyzvať, aby zistili, ako sa im darí, alebo sledovať, ktoré inštancie pomaly reagujú na požiadavky na služby, a odosielať následné žiadosti do ďalších inštancií. Sieť služieb môže robiť podobné práce pre sieťové trasy, všimne si, keď sa správy dostanú príliš dlho do cieľa, a kompenzuje iné trasy. Tieto spomalenia môžu byť spôsobené problémami so základným hardvérom alebo jednoducho preťažením služieb požiadavkami alebo prácou na ich kapacite spracovania. Dôležité je, že sieť služieb dokáže nájsť inú inštanciu tej istej služby a namiesto nej k nej nasmerovať cestu, čím čo najefektívnejšie využije kapacitu celej aplikácie.
Servisná sieť vs Kubernetes
Ak ste trochu oboznámení s architektúrami založenými na kontajneroch, možno by vás zaujímalo, kam zapadá Kubernetes, populárna platforma orchestrácie kontajnerov s otvoreným zdrojom, do tohto obrázka. Nie je koniec koncov to, o čom Kubernetes hovorí, že riadi vzájomnú komunikáciu vašich kontajnerov? Ako upozorňuje tím Kublr na svojom firemnom blogu, zdroj „služieb“ spoločnosti Kubernetes by ste mohli považovať za veľmi základný druh sieťovej siete, pretože poskytuje vyhľadávanie služieb a vyváženie požiadaviek každý s každým. Ale plne vybavené siete služieb poskytujú oveľa viac funkcií, ako je správa bezpečnostných politík a šifrovanie, prerušenie okruhu na pozastavenie požiadaviek na pomaly reagujúce inštancie, vyvažovanie záťaže, ako sme to opísali vyššie, a oveľa viac.
Pamätajte, že väčšina servisných sietí skutočne vyžaduje, aby bol zavedený systém orchestrácie, ako je Kubernetes. Servisné siete ponúkajú rozšírenú funkčnosť, nie náhradu.
Brány služieb vs. brány API
Každá mikroslužba poskytne aplikačné programové rozhranie (API), ktoré slúži ako prostriedok, pomocou ktorého s ňou komunikujú ďalšie služby. To nastoľuje otázku rozdielov medzi sieťou služieb a inými tradičnejšími formami správy API, ako sú brány API. Ako vysvetľuje IBM, brána API stojí medzi skupinou mikroslužieb a „vonkajším“ svetom a podľa potreby smeruje požiadavky na službu, aby žiadateľ nemusel vedieť, že sa zaoberá aplikáciou založenou na mikroslužbách. Servisná sieť na druhej strane sprostredkováva požiadavky „vo vnútri“ aplikácie mikroslužieb, pričom rôzne komponenty si plne uvedomujú svoje prostredie.
Ďalším spôsobom, ako o tom premýšľať, ako píše Justin Warren Forbes, je to, že sieť služieb je pre prenos z východu na západ v klastri a brána API je na prenos zo severu na juh smerujúci do a z klastra. Celá myšlienka siete služieb je však stále skoro a v chode. Mnoho sieťových sietí - vrátane Linkerd a Istio - teraz tiež ponúka funkcie sever-juh.
Architektúra siete služieb
Myšlienka siete služieb sa objavila až v posledných niekoľkých rokoch a existuje množstvo rôznych prístupov k riešeniu problému „siete služieb“, t. J. Správa komunikácií pre mikroslužby. Andrew Jenkins z Aspen Mesh identifikuje tri možné možnosti týkajúce sa toho, kde by mohla žiť komunikačná vrstva vytvorená sieťou služieb:
- V knižnica ktoré každá vaša mikroslužba importuje
- V agent uzla ktorá poskytuje služby všetkým kontajnerom na konkrétnom uzle
- V postranný vozík kontajner, ktorý beží popri vašom aplikačnom kontajneri
Model založený na postrannom vozíku je jedným z najpopulárnejších vzorov sieťových služieb - až tak, že sa v niektorých ohľadoch stal synonymom všeobecne pre servisné siete. Aj keď to nie je úplne pravda, prístup sajdkár získal toľko trakcie, že ide o architektúru, na ktorú sa pozrieme podrobnejšie.
Sajdkáry v služobnom pletive
Čo to znamená, povedať, že kontajner s prívesným vozíkom „beží vedľa“ vášho kontajnera s aplikáciou? Red Hat má celkom dobré vysvetlenie. Každý kontajner mikroslužieb v sieti služieb tohto typu má iný zodpovedajúci kontajner proxy. Celá logika požadovaná pre komunikáciu medzi službami je vyňatá z mikroslužby a vložená do vedľajšieho vozíka.
Môže sa to zdať komplikované - koniec koncov vlastne zdvojnásobujete počet kontajnerov vo svojej aplikácii! Používate však aj návrhový vzor, ktorý je kľúčom k zjednodušeniu distribuovaných aplikácií. Vložením celého tohto sieťového a komunikačného kódu do samostatného kontajnera ste sa stali súčasťou infraštruktúry a zbavili vývojárov jeho implementácie ako súčasti aplikácie.
V podstate vám zostáva mikroslužba, ktorú je možné laserovo zamerať na jej obchodnú logiku. Mikroslužba nemusí vedieť, ako komunikovať so všetkými ostatnými službami v divokom a bláznivom prostredí, kde pôsobia. Potrebuje iba vedieť, ako komunikovať s postranným vozíkom, ktorý sa stará o zvyšok.
Servisné siete: Linkerd, Envio, Istio, Consul
Aké sú teda servisné siete k dispozícii na použitie? Nie sú tam úplne bežné komerčné produkty. Väčšina sietí služieb sú projekty s otvoreným zdrojom, ktoré je potrebné implementovať. Veľké mená sú:
- Linkerd (vyslovuje sa „linker-dee“) - Spoločnosť Linkerd, ktorá bola vydaná v roku 2016 a je teda najstaršou z týchto ponúk, bola vyčlenená z knižnice vyvinutej na Twitteri. Ďalší ťažký stopér v tomto priestore, spoločnosť Conduit, bol zahrnutý do projektu Linkerd a tvorí základ pre Linkerd 2.0.
- Vyslanec - vyslanec vytvorený v spoločnosti Lyft zaberá časť „dátovej roviny“ siete služieb. Na zaistenie úplnej siete služieb je potrebné ju spárovať s „riadiacou rovinou“, napríklad ...
- Istio - vyvinutý v spolupráci spoločností Lyft, IBM a Google. Istio je kontrolný plán pre poskytovanie služieb proxy, ako je Envoy. Zatiaľ čo Istio a Envoy sú predvoleným párom, každú je možné spárovať s inými platformami.
- HashiCorp Consul - predstavený s konzolou Consul 1.2, funkciou nazvanou Connect, ktorá pridala šifrovanie služieb a autorizáciu založenú na identite do distribuovaného systému HashiCorp na účely zisťovania a konfigurácie služieb, čím sa zmenila na celú sieť služieb.
Ktorá sieť služieb je pre vás to pravé? Porovnanie presahuje rámec tohto článku, ale stojí za zmienku, že všetky vyššie uvedené produkty boli osvedčené vo veľkých a náročných prostrediach. Linkerd a Istio majú najrozsiahlejšie sady funkcií, ale všetky sa vyvíjajú rýchlo. Možno by ste sa mali pozrieť na rozpis funkcií Linkerda, Envoya a Istia od Georga Mirandu, aj keď nezabudnite, že jeho článok bol napísaný skôr, ako sa Conduit a Linkerd spojili.
Pamätajte tiež, že tento priestor je nový a kedykoľvek by sa mohli objaviť noví konkurenti. Napríklad v novembri 2018 začal Amazon ponúkať verejný náhľad na sieť služieb AWS. Vzhľadom na to, koľko obchodov používa verejný cloud spoločnosti Amazon, by mala mať AWS App Mesh zásadný vplyv.
