Sveiki, Habr! Jūsų dėmesiui pristatau straipsnio vertimą „Paslaugų tinklo duomenų plokštuma vs valdymo plokštuma“ autorius Mattas Kleinas.

Šį kartą „norėjau ir išverčiau“ abiejų paslaugų tinklo komponentų, duomenų plokštumos ir valdymo plokštumos aprašymus. Šis aprašymas man pasirodė suprantamiausias ir įdomiausias, o svarbiausia – vedantis į supratimą „Ar tai apskritai būtina?

Per pastaruosius dvejus metus vis labiau populiarėjant „Paslaugų tinklelio“ idėjai (originalus straipsnis 10 m. spalio 2017 d.) ir didėjant erdvės dalyvių skaičiui, pastebėjau proporcingai išaugusį painiavą tarp visų. technologijų bendruomenė apie tai, kaip palyginti ir supriešinti skirtingus sprendimus.

Situaciją geriausiai apibendrina ši liepą parašytų tviterių serija:

Paslaugų tinklo painiava Nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = pasiuntinys. Nė vienas iš jų neprilygsta Istio. Istio yra kažkas visiškai kitokio. 1 /

Pirmosios yra tiesiog duomenų plokštumos. Patys jie nieko nedaro. Jie turi būti nusiteikę kažkam daugiau. 2/

Istio yra valdymo plokštumos, kuri sujungia dalis, pavyzdys. Tai dar vienas sluoksnis. /galas

Ankstesniuose tviteriuose minimi keli skirtingi projektai (Linkerd, NGINX, HAProxy, Envoy ir Istio), bet dar svarbiau pristatomos bendrosios duomenų plokštumos, paslaugų tinklo ir valdymo plokštumos sąvokos. Šiame įraše žengsiu žingsnį atgal ir labai aukštai pakalbėsiu apie tai, ką turiu omenyje sakydamas sąvokas „duomenų plokštuma“ ir „valdymo plokštuma“, o tada pakalbėsiu apie tai, kaip terminai taikomi tviteriuose minimiems projektams.

Kas iš tikrųjų yra paslaugų tinklelis?

1 pav. Aptarnavimo tinklo apžvalga

Pav 1 iliustruoja paslaugų tinklo sąvoką pačiame pagrindiniame lygmenyje. Yra keturios paslaugų grupės (AD). Kiekvienas paslaugos egzempliorius yra susietas su vietiniu tarpiniu serveriu. Visas tinklo srautas (HTTP, REST, gRPC, Redis ir kt.) iš vieno programos egzemplioriaus per vietinį tarpinį serverį perduodamas į atitinkamas išorinių paslaugų grupes. Tokiu būdu programos egzempliorius nežino viso tinklo ir žino tik savo vietinį tarpinį serverį. Iš tikrųjų paskirstytos sistemos tinklas buvo pašalintas iš paslaugos.

Duomenų plokštuma

Paslaugų tinkle tarpinis serveris, esantis vietoje, programai atlieka šias užduotis:

• Paslaugos atradimas. Kokios paslaugos / programos yra prieinamos jūsų programai?
• Sveikatos patikrinimas. Ar paslaugų egzemplioriai, grąžinti naudojant paslaugos aptikimą, yra sveiki ir pasirengę priimti tinklo srautą? Tai gali apimti ir aktyvius (pvz., atsako/sveikatos patikros) ir pasyvius (pvz., naudojant 3 iš eilės 5xx klaidas kaip netinkamos paslaugos būklės požymį) sveikatos patikrinimus.
• Maršrutas. Kuriam paslaugų klasteriui reikia siųsti užklausą, kai gaunama užklausa „/foo“ iš REST paslaugos?
• Apkrovos balansavimas. Kuriam paslaugos egzemplioriui reikia siųsti užklausą, kai maršruto parinkimo metu pasirinktas paslaugų klasteris? Su kokiu laiku? Su kokiais grandinės pertraukimo nustatymais? Jei užklausa nepavyksta, ar ją reikia bandyti dar kartą?
• Autentifikavimas ir įgaliojimas. Ar įeinančių užklausų atveju skambinimo paslauga gali būti kriptografiškai identifikuojama / autorizuojama naudojant mTLS ar kitą mechanizmą? Jei jis atpažįstamas / įgaliotas, ar paslauga gali iškviesti prašomą operaciją (galinį tašką), ar reikia grąžinti neautentifikuotą atsakymą?
• Stebimumas. Išsami statistika, žurnalai / žurnalai ir paskirstyti sekimo duomenys turėtų būti generuojami kiekvienai užklausai, kad operatoriai galėtų suprasti paskirstyto srauto ir derinimo problemas, kai jos kyla.

Duomenų plokštuma yra atsakinga už visus ankstesnius aptarnavimo tinklo taškus. Tiesą sakant, vietinis paslaugos tarpinis serveris (šoninė priekaba) yra duomenų plokštuma. Kitaip tariant, duomenų plokštuma yra atsakinga už sąlyginį kiekvieno tinklo paketo, siunčiamo į paslaugą arba iš jos, transliavimą, persiuntimą ir stebėjimą.

Valdymo plokštuma

Tinklo abstrakcija, kurią duomenų plokštumoje teikia vietinis tarpinis serveris, yra stebuklinga (?). Tačiau kaip įgaliotasis serveris iš tikrųjų žino apie „/foo“ maršrutą į paslaugą B? Kaip galima naudoti paslaugų aptikimo duomenis, kurie yra užpildyti tarpinio serverio užklausomis? Kaip sukonfigūruoti apkrovos balansavimo, skirtojo laiko, grandinės pertraukimo ir kt. parametrai? Kaip įdiegti programą naudojant mėlyną / žalią metodą arba grakštų srauto perėjimo metodą? Kas konfigūruoja visos sistemos autentifikavimo ir autorizacijos nustatymus?

Visus aukščiau išvardintus elementus valdo aptarnavimo tinklo valdymo plokštuma. Valdymo plokštuma paima atskirų be būsenų tarpinių serverių rinkinį ir paverčia juos paskirstyta sistema.

Manau, kad priežastis, dėl kurios daugelis technologų mano, kad atskiros duomenų plokštumos ir valdymo plokštumos sąvokos yra painiojamos, yra ta, kad daugumai žmonių duomenų plokštuma yra pažįstama, o valdymo plokštuma yra svetima / nesuprantama. Su fiziniais tinklo maršrutizatoriais ir komutatoriais dirbame jau seniai. Suprantame, kad paketai/užklausos turi eiti iš taško A į tašką B ir kad tam galime naudoti aparatinę ir programinę įrangą. Naujos kartos programinės įrangos tarpiniai serveriai yra tiesiog įmantrios įrankių, kuriuos naudojome ilgą laiką, versijos.

2 pav. Žmogaus valdymo plokštuma

Tačiau valdymo plokštumas naudojame jau seniai, nors dauguma tinklo operatorių šios sistemos dalies gali ir nesusieti su jokiu technologijos komponentu. Priežastis paprasta:
Dauguma šiandien naudojamų valdymo plokštumų yra... mes.

Apie 2 paveikslas rodo tai, ką aš vadinu „žmogaus valdymo plokštuma“. Šio tipo diegimo metu, kuris vis dar yra labai paplitęs, tikriausiai rūstus žmogus operatorius sukuria statines konfigūracijas – galbūt per scenarijus – ir per tam tikrą specialų procesą diegia jas visuose tarpiniuose serveriuose. Tada tarpiniai serveriai pradeda naudoti šią konfigūraciją ir pradeda apdoroti duomenų plokštumą naudodami atnaujintus nustatymus.

3 pav. Išplėstinės priežiūros tinklo valdymo plokštuma

Apie 3 paveikslas rodo „išplėstą“ aptarnavimo tinklo valdymo plokštumą. Jį sudaro šios dalys:

• Žmogus: Vis dar yra žmogus (tikiuosi, mažiau piktas), kuris priima aukšto lygio sprendimus visos sistemos atžvilgiu.
• Valdymo plokštumos vartotojo sąsaja: asmuo sąveikauja su tam tikro tipo vartotojo sąsaja, kad valdytų sistemą. Tai gali būti žiniatinklio portalas, komandų eilutės programa (CLI) ar kita sąsaja. Naudodamas vartotojo sąsają, operatorius turi prieigą prie visuotinių sistemos konfigūracijos parametrų, tokių kaip:
  • Diegimo kontrolė, mėlyna / žalia ir (arba) laipsniškas eismo perėjimas
  • Autentifikavimo ir autorizacijos parinktys
  • Maršruto lentelės specifikacijos, pavyzdžiui, kai programa A prašo informacijos apie „/foo“, kas vyksta
  • Apkrovos balansavimo priemonės nustatymai, pvz., skirtis laikas, pakartotiniai bandymai, grandinės pertraukimo nustatymai ir kt.
• Darbo krūvio planuotojas: paslaugos teikiamos infrastruktūroje naudojant tam tikro tipo planavimo / orkestravimo sistemas, pvz., Kubernetes arba Nomad. Planuotojas yra atsakingas už paslaugos įkėlimą kartu su vietiniu įgaliotuoju serveriu.
• Paslaugos atradimas. Kai planuoklis paleidžia ir sustabdo paslaugų egzempliorius, jis praneša apie sveikatos būklę paslaugų aptikimo sistemai.
• Šoninio automobilio tarpinio serverio konfigūracijos API : vietiniai tarpiniai serveriai dinamiškai išskiria būseną iš įvairių sistemos komponentų, naudodamiesi nuosekliu modeliu be operatoriaus įsikišimo. Visa sistema, kurią sudaro visi šiuo metu veikiantys paslaugų egzemplioriai ir vietiniai tarpiniai serveriai, galiausiai susijungia į vieną ekosistemą. „Envoy“ universali duomenų plokštumos API yra vienas iš pavyzdžių, kaip tai veikia praktiškai.

Iš esmės valdymo plokštumos tikslas yra nustatyti politiką, kuri galiausiai bus priimta duomenų plokštumoje. Pažangesnės valdymo plokštumos pašalins daugiau kai kurių sistemų dalių nuo operatoriaus ir reikės mažiau rankinio valdymo, jei jos tinkamai veiks!...

Duomenų plokštuma ir valdymo plokštuma. Duomenų plokštumos ir valdymo plokštumos santrauka

• Aptarnavimo tinklo duomenų plokštuma: Paveikia kiekvieną paketą / užklausą sistemoje. Atsakingas už taikomųjų programų / paslaugų aptikimą, sveikatos patikrinimą, maršruto parinkimą, apkrovos balansavimą, autentifikavimą / autorizavimą ir stebėjimą.
• Serviso tinklelio valdymo plokštuma: teikia politiką ir konfigūraciją visoms paslaugų tinkle veikiančioms duomenų plokštumoms. Neliečia jokių paketų/užklausų sistemoje. Valdymo plokštuma visas duomenų plokštumas paverčia paskirstyta sistema.

Dabartinis projekto kraštovaizdis

Supratę aukščiau pateiktą paaiškinimą, pažvelkime į dabartinę paslaugų tinklo projekto būklę.

• Duomenų plokštumos: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Valdymo plokštumos: Istio, Nelsonas, SmartStack

Užuot pradėjęs nuodugnią kiekvieno iš aukščiau pateiktų sprendimų analizę, trumpai pakalbėsiu apie kai kuriuos dalykus, kurie, mano nuomone, šiuo metu sukelia daug painiavos ekosistemoje.

„Linkerd“ buvo vienas iš pirmųjų duomenų plokštumos tarpinių serverių, skirtų paslaugų tinkleliui 2016 m. pradžioje, ir atliko fantastišką darbą didindamas informuotumą ir dėmesį paslaugų tinklo projektavimo modeliui. Praėjus maždaug 6 mėnesiams po to, pasiuntinys prisijungė prie Linkerd (nors kartu su Lyft dirbo nuo 2015 m. pabaigos). Linkerd ir Envoy yra du projektai, kurie dažniausiai minimi aptariant paslaugų tinklelius.

„Istio“ buvo paskelbta 2017 m. gegužės mėn. Istio projekto tikslai yra labai panašūs į išplėstinę valdymo plokštumą, parodytą paveikslėlyje 3 paveikslas. „Istio“ pasiuntinys yra numatytasis įgaliotasis serveris. Taigi Istio yra valdymo plokštuma, o pasiuntinys yra duomenų plokštuma. Per trumpą laiką „Istio“ sukėlė daug įspūdžių, o kitos duomenų plokštumos pradėjo integruotis kaip „Envoy“ pakaitalas (ir „Linkerd“, ir „NGINX“ demonstravo integraciją su „Istio“). Tai, kad toje pačioje valdymo plokštumoje gali būti naudojamos skirtingos duomenų plokštumos, reiškia, kad valdymo plokštuma ir duomenų plokštuma nebūtinai yra glaudžiai sujungtos. API, pvz., „Envoy“ bendrosios duomenų plokštumos API, gali sudaryti tiltą tarp dviejų sistemos dalių.

Nelson ir SmartStack padeda toliau iliustruoti valdymo plokštumos ir duomenų plokštumos atskyrimą. Nelsonas naudoja „Envoy“ kaip tarpinį serverį ir sukuria patikimą aptarnavimo tinklo valdymo plokštumą, pagrįstą „HashiCorp“ krūva, t.y. Nomadas ir kt. „SmartStack“ tikriausiai buvo pirmasis iš naujos paslaugų tinklų bangos. „SmartStack“ sukuria valdymo plokštumą aplink HAProxy arba NGINX, parodydamas galimybę atsieti valdymo plokštumą nuo aptarnavimo tinklo nuo duomenų plokštumos.

„Microservice“ architektūra su paslaugų tinkleliu sulaukia vis daugiau dėmesio (teisingai!), vis daugiau projektų ir tiekėjų pradeda veikti šia kryptimi. Per ateinančius kelerius metus pamatysime daug naujovių tiek duomenų plokštumoje, tiek valdymo plokštumoje, taip pat tolimesnį skirtingų komponentų maišymą. Galiausiai mikro paslaugų architektūra turėtų tapti skaidresnė ir magiškesnė (?) operatoriui.
Tikiuosi, vis mažiau susierzins.

Raktai išsinešti

• Aptarnavimo tinklelis susideda iš dviejų skirtingų dalių: duomenų plokštumos ir valdymo plokštumos. Reikalingi abu komponentai, o be jų sistema neveiks.
• Visi yra susipažinę su valdymo plokštuma, ir šiuo metu valdymo plokštuma gali būti jūs!
• Visos duomenų plokštumos konkuruoja tarpusavyje dėl funkcijų, našumo, konfigūravimo ir išplečiamumo.
• Visos valdymo plokštumos konkuruoja tarpusavyje dėl funkcijų, konfigūravimo, išplečiamumo ir naudojimo paprastumo.
• Vienoje valdymo plokštumoje gali būti tinkamos abstrakcijos ir API, kad būtų galima naudoti kelias duomenų plokštumas.

Šaltinis: www.habr.com