Vienas iš pokyčių, vykstančių IT srityje po skaitmeninės transformacijos ženklu, yra didelių, monolitinių programų suskaidymas į mikroservisus—maži, atskiri funkcionalumo vienetai, kurie veikia konteineriuose—programinės įrangos paketai, kuriuose yra visas paslaugos kodas ir priklausomybės, kurias galima izoliuoti ir lengvai perkelti iš vieno serverio į kitą.
Tokias konteinerių architektūras lengva išplėsti ir paleisti debesyje, o atskiras mikropaslaugas galima greitai įdiegti ir pakartoti. Tačiau ryšys tarp šių mikropaslaugų tampa vis sudėtingesnis, nes programos tampa vis didesnės ir vienu metu veikia keli tos pačios paslaugos egzemplioriai. Aptarnavimo tinklelis yra nauja architektūrinė forma, kuria siekiama dinamiškai sujungti šias mikropaslaugas taip, kad sumažėtų administravimo ir programavimo pridėtinės išlaidos.
Kas yra paslaugų tinklas?
Plačiąja prasme paslaugų tinklas yra, kaip „Red Hat“ apibūdina, „būdas kontroliuoti, kaip skirtingos programos dalys dalijasi duomenimis tarpusavyje“. Šis aprašymas vis dėlto gali apimti daug įvairių dalykų. Tiesą sakant, tai skamba nepaprastai kaip tarpinė programinė įranga, kurią dauguma kūrėjų žino iš kliento-serverio programų.
Paslaugų tinklelis yra unikalus tuo, kad jis sukurtas taip, kad atitiktų unikalų paskirstytų mikropaslaugų aplinkų pobūdį. Didelės apimties programoje, sukurtoje iš mikro paslaugų, gali būti keli bet kurios paslaugos egzemplioriai, veikiantys įvairiuose vietiniuose arba debesų serveriuose. Dėl visų šių judančių dalių atskiroms mikroservikoms akivaizdžiai sunku rasti kitas paslaugas, su kuriomis reikia bendrauti. Aptarnavimo tinklas automatiškai rūpinasi paslaugų atradimu ir sujungimu kiekvieną akimirką, kad nereikėtų to daryti tiek žmonių kūrėjams, tiek atskiroms mikroservikoms.
Pagalvokite apie tinklo tinklą kaip apie programinės įrangos apibrėžto tinklo (SDN) atitikmenį OSI tinklo modelio 7 lygiui. Kaip SDN sukuria abstrakcijos sluoksnį, kad tinklo administratoriams nereikėtų spręsti fizinių tinklo ryšių, paslaugų tinklas atsieja pagrindinę programos infrastruktūrą nuo abstrakčios architektūros, su kuria bendraujate.
Aptarnavimo tinklo idėja kilo organiškai, kai kūrėjai pradėjo kovoti su tikrai milžiniškų paskirstytų architektūrų problemomis. Pirmasis šios srities projektas „Linkerd“ gimė kaip vidinio projekto „Twitter“ dalis. „Istio“, kitas populiarus paslaugų tinklas, turintis didelę įmonės paramą, atsirado „Lyft“. (Mes akimirksniu apžvelgsime abu šiuos projektus.)
Aptarnavimo tinklo apkrovos balansavimas
Viena pagrindinių savybių, kurias teikia tinklo tinklas, yra apkrovos balansavimas. Mes paprastai galvojame apie apkrovos balansavimą kaip apie tinklo funkciją - jūs norite užkirsti kelią bet kurio serverio ar tinklo saito perpildymui srautu, todėl atitinkamai nukreipiate savo paketus. Tarnybiniai tinklai daro kažką panašaus programų lygiu, kaip aprašo Twainas Tayloras, ir supratimas, leidžiantis suprasti, ką turime omenyje sakydami, kad paslaugų tinklas yra kaip programinės įrangos apibrėžtas tinklas programų lygiui.
Iš esmės, vienas iš tinklo tinklo uždavinių yra stebėti, kurie įvairių mikropaslaugų atvejai, paskirstyti infrastruktūroje, yra „sveikiausi“. Tai gali juos apklausti, norėdami sužinoti, kaip jiems sekasi, arba stebėti, kurie egzemplioriai lėtai reaguoja į paslaugų užklausas, ir siųsti vėlesnes užklausas kitoms instancijoms. Aptarnavimo tinklas gali atlikti panašų darbą tinklo maršrutuose, pastebėdamas, kada pranešimams užtrunka per ilgai pasiekti jų paskirties vietą, ir pasirinkti kitus maršrutus kompensuoti. Šį sulėtėjimą gali lemti problemos, susijusios su pagrindine aparatine įranga, arba paprasčiausiai dėl to, kad paslaugos yra perkrautos užklausomis arba dirba pagal savo apdorojimo pajėgumus. Svarbu tai, kad paslaugų tinklas gali rasti kitą tos pačios paslaugos egzempliorių ir nukreipti į ją, tokiu būdu efektyviausiai išnaudojant bendrą programos pajėgumą.
Aptarnavimo tinklelis prieš „Kubernetes“
Jei esate šiek tiek susipažinęs su konteinerių architektūromis, jums gali kilti klausimas, kur „Kubernetes“, populiari atvirojo kodo konteinerių orkestravimo platforma, telpa į šį paveikslą. Galų gale, ar ne visa „Kubernetes“ esmė yra tai, kad ji valdo, kaip jūsų konteineriai bendrauja tarpusavyje? Kaip „Kublr“ komanda pabrėžia savo korporatyviniame tinklaraštyje, Kubernetes „paslaugos“ išteklius galėtumėte galvoti kaip apie labai paprastą paslaugų tinklo rūšį, nes tai suteikia paslaugų atradimą ir užklausų subalansavimą. Tačiau visapusiškai aprūpintos paslaugų tinkleliai suteikia daug daugiau funkcijų, tokių kaip saugos politikos ir šifravimo valdymas, „grandinės pertraukimas“, norint sustabdyti prašymus lėtai reaguojantiems atvejams, apkrovos balansavimas, kaip aprašėme aukščiau, ir daug daugiau.
Atminkite, kad norint naudoti daugumą paslaugų tinklų, reikalinga orkestravimo sistema, pvz., „Kubernetes“. Aptarnavimo tinklai siūlo išplėstines funkcijas, o ne pakaitalus.
Aptarnavimo tinklas ir API šliuzai
Kiekviena mikroservisa suteiks programos programavimo sąsają (API), kuri bus priemonė, kuria kitos tarnybos su ja bendrauja. Tai kelia klausimą apie paslaugų tinklo ir kitų tradicinių API valdymo formų, tokių kaip API šliuzai, skirtumus. Kaip paaiškina IBM, API šliuzas yra tarp mikro paslaugų grupės ir „išorinio“ pasaulio, prireikus nukreipdamas paslaugų užklausas, kad prašytojui nereikėtų žinoti, kad jis susijęs su mikroservisais pagrįsta programa. Kita vertus, paslaugų tinklas tarpininkauja prašymams „viduje“ mikro paslaugų programoje, o įvairūs komponentai puikiai žino savo aplinką.
Kitas būdas galvoti apie tai, kaip rašo Justinas Warrenas „Forbes“, yra tai, kad paslaugų tinklas skirtas rytų ir vakarų eismui klasteryje, o API šliuzai - eismui į šiaurę ir pietus einant į klasterį ir iš jo. Tačiau visa tinklo tinklo idėja vis dar ankstyva ir sklandi. Daugelis tinklo tinklų, įskaitant „Linkerd“ ir „Istio“, dabar siūlo ir šiaurės – pietų funkcionalumą.
Aptarnavimo tinklo architektūra
Aptarnavimo tinklo idėja atsirado tik per pastaruosius porą metų, ir yra daugybė skirtingų būdų, kaip išspręsti „tarnybinio tinklo“ problemą, t. Y. Valdyti ryšius, susijusius su mikroservisais. Andrew Jenkinsas iš „Aspen Mesh“ nurodo tris galimus pasirinkimus dėl to, kur gali gyventi paslaugų tinklo sukurtas komunikacijos sluoksnis:
- A biblioteka kad kiekviena iš jūsų mikro paslaugų importuoja
- A mazgo agentas kuri teikia paslaugas visiems tam tikro mazgo konteineriams
- A šoninė priekaba sudėtinis rodinys, einantis kartu su jūsų programos sudėtiniu rodiniu
Šoninės priekabos modelis yra vienas iš populiariausių paslaugų tinklo modelių - tiek, kad jis tam tikru požiūriu tapo sinonimu paslaugų tinklams. Nors tai nėra griežtai tiesa, šoninės priekabos požiūris įgavo tiek daug traukos, kad tai yra architektūra, į kurią mes žiūrėsime išsamiau.
Šoninės mašinos tinklelyje
Ką reiškia sakyti, kad šoninio automobilio konteineris „važiuoja kartu“ su jūsų programos konteineriu? „Red Hat“ turi gana gerą paaiškinimą. Kiekviename šio tipo paslaugų tinkle esančiame mikropaslaugų konteineryje yra kitas atitinkamas tarpinio serverio konteineris. Visa logika, reikalinga ryšiui tarp paslaugų, yra ištraukiama iš mikro paslaugos ir dedama į šoninę priekabą.
Tai gali atrodyti sudėtinga - galų gale jūs padvigubinate konteinerių skaičių savo programoje! Bet jūs taip pat naudojate dizaino modelį, kuris yra pagrindinis paprastinant paskirstytas programas. Įdėję visą tą tinklo ir ryšių kodą į atskirą konteinerį, jūs padarėte jį infrastruktūros dalimi ir išlaisvinote kūrėjus nuo jo kaip programos dalies diegimo.
Iš esmės jums beliko mikropaslaugos, kuri gali būti nukreipta lazeriu į jos verslo logiką. Mikroservisui nereikia žinoti, kaip bendrauti su visomis kitomis tarnybomis laukinėje ir pašėlusioje aplinkoje, kurioje jos veikia. Tereikia mokėti bendrauti su šonine priekaba, kuri rūpinasi likusia dalimi.
Tarnybos tinklai: „Linkerd“, „Envio“, „Istio“, konsulas
Taigi, kokie yra tinkliniai tinklai, kuriuos galima naudoti? Na, ten nėra tiksliai parduodamų komercinių produktų. Dauguma paslaugų tinklų yra atvirojo kodo projektai, kuriuos įgyvendinti reikia šiek tiek tobulinti. Didieji vardai yra:
- „Linkerd“ (tariama „linker-dee“) - išleistas 2016 m., Taigi seniausias iš šių pasiūlymų, „Linkerd“ buvo atskirtas iš „Twitter“ sukurtos bibliotekos. Kitas stiprus šios erdvės smūgis „Conduit“ buvo įtrauktas į „Linkerd“ projektą ir yra „Linkerd 2.0“ pagrindas.
- Pasiuntinys - sukurtas „Lyft“, pasiuntinys užima „tinklo“ duomenų tinklo dalį. Norint suteikti visiško aptarnavimo tinklelį, jį reikia suporuoti su „valdymo plokštuma“, pavyzdžiui, ...
- „Istio“ - sukurtas bendradarbiaujant „Lyft“, IBM ir „Google“, „Istio“ yra valdymo planas, skirtas aptarnauti tokius įgaliotinius kaip „Envoy“. Nors „Istio“ ir „Pasiuntinys“ yra numatytoji pora, kiekvienas gali būti suporuotas su kitomis platformomis.
- „HashiCorp Consul“ - pristatyta kartu su „Consul 1.2“, vadinama „Connect“, prie „HashiCorp“ paskirstytos sistemos suteikė paslaugų šifravimą ir tapatybe pagrįstą prieigą prie paslaugų atradimo ir konfigūravimo, paversdama ją visiško aptarnavimo tinklu.
Kuris paslaugų tinklelis jums tinka? Palyginimas nepatenka į šio straipsnio taikymo sritį, tačiau verta paminėti, kad visi aukščiau išvardyti produktai buvo įrodyti didelėje ir sudėtingoje aplinkoje. „Linkerd“ ir „Istio“ turi pačius gausiausius funkcijų rinkinius, tačiau visi jie sparčiai tobulėja. Galbūt norėsite patikrinti George'o Mirandos pateiktą „Linkerd“, „Pasiuntinio“ ir „Istio“ funkcijų išskaidymą, nors nepamirškite, kad jo straipsnis buvo parašytas dar prieš „Conduit“ ir „Linkerd“ suvienijus jėgas.
Taip pat nepamirškite, kad ši erdvė yra nauja ir bet kada gali atsirasti naujų konkurentų. Pavyzdžiui, 2018 m. Lapkričio mėn. „Amazon“ pradėjo siūlyti viešą AWS paslaugų tinklo peržiūrą. Atsižvelgiant į tai, kiek parduotuvių naudoja „Amazon“ viešąjį debesį, „AWS App Mesh“ turėtų turėti didelę įtaką.
