Kuriant programas su mikropaslaugomis, kūrėjai gauna didesnį greitį ir judrumą nei tradicinės architektūros. Tačiau kiekvienas kodo pakeitimas vis tiek kelia riziką, nustatydamas galimų gedimų etapą, jei neatrastos ir neišspręstos kodo kokybės problemos. Norėdami sušvelninti šią riziką, programų grupės turėtų įgyvendinti šiuolaikines, debesyje nukreiptas maršruto parinkimo strategijas, kurios palengvintų pavojų patikrinimą ir užtikrintų, kad programos yra tikrai pasirengusios diegti gamybos aplinkoje.
Šiose keturiose diegimo strategijose naudojami maršruto parinkimo metodai, siekiant saugiai pristatyti naujas paslaugas ir funkcijas, išbandyti funkcionalumą ir atlikti pakartotinius patobulinimus, nustatyti ir pašalinti pažeidžiamumus ir dar daugiau. Šie metodai kartu yra virtualus įrankių rinkinys, kurį programų komandos gali pasiekti, kad sumažintų riziką kuriant ir diegiant mikroservisų valdomas programas. Suprasti jų skirtumus ir panašumus bus raktas į žinias, kaip jas kuo geriau išnaudoti savo aplinkoje.
Kanarų dislokavimas
Pavadinta istorinės paukščių siuntimo į anglies kasyklas praktika, siekiant sužinoti, ar oro kokybė yra saugi žmonėms, kanarėlių dislokavimas yra būdas patikrinti faktinį produkcijos išdėstymą su mažiausiu poveikiu ar rizika. Vadinamasis „Canary“ yra kandidato į paslaugą versija, kuri gauna tam tikrą procentą gaunamų užklausų (tarkime, 1%), kad išbandytų naujas funkcijas ar versijas. Tada komandos gali išnagrinėti rezultatus ir, jei viskas vyksta sklandžiai, palaipsniui didinkite diegimą iki 100% serverių ar mazgų. O jei ne? Eismas gali būti greitai nukreiptas iš kanarų dislokavimo, kol pažeidžiantį kodą peržiūrės ir derins.
Kanarų diegimas gali būti įgyvendinamas integruojant su krašto maršruto komponentais, atsakingais už gaunamo vartotojo srauto apdorojimą. Pvz., „Kubernetes“ aplinkoje kanarų diegimas gali paliesti įėjimo valdiklio konfigūraciją, kad priskirtų tam tikrus srauto užklausų procentus stabiliam ir kanarietiškam diegimui. Tokiu būdu nukreipiant srautą, užtikrinama, kad naujos paslaugos turėtų galimybę įrodyti save prieš gaunant pilną išleidimą. Jei jie to nepadaro, jie siunčiami ištaisyti problemas ir, kai bus pasirengę, atliks dar vieną Kanarų dislokavimo testą.
A / B testavimas
A / B bandymai yra panašūs į kanarų dislokavimą, turint vieną svarbų skirtumą. Kanarų kanaluose dažniausiai sutelktas dėmesys į klaidų ir našumo nustatymą, o A / B bandymai skirti įvertinti vartotojo sutikimas naujų programų funkcijų. Pvz., Kūrėjai gali norėti sužinoti, ar naujos funkcijos yra populiarios vartotojams, ar jas lengva atrasti, ar sąsaja veikia tinkamai.
Šis modelis naudoja programinės įrangos nukreipimą, kad suaktyvintų ir išbandytų specifines funkcijas su skirtingais srauto segmentais, atskleisdami naujas funkcijas nurodytam srauto procentui ar ribotoms grupėms. A ir B maršruto segmentai gali siųsti srautą į skirtingas programinės įrangos versijas, arba paslaugų egzemplioriai netgi gali naudoti tą pačią programinės įrangos versiją, bet su skirtingais konfigūracijos atributais (kaip nurodyta orkestratoriuje ar kitur).
Mėlynai žalios spalvos dislokavimas
Mėlynai žalios spalvos diegimo schema apima lygiagrečią dviejų gamybos aplinkų valdymą: vieną dabartiniam stabiliam leidimui (mėlyną), o kitą - kitam leidimui (žalia). Ši strategija leidžia lengvai pakartotinai išleisti atnaujintas programinės įrangos versijas. „Devops“ komandos gali naudoti šią metodiką, kad automatizuotų naujos versijos išleidimą naudodami CI / CD vamzdyną.
Taikydami mėlynai žalią strategiją, kūrėjai kartu su esamu egzemplioriumi, kuris šiuo metu tvarko gamybos srautą, įdiegia naują paslaugos versiją. CI / CD vamzdynas turėtų būti nustatytas atlikti automatinius dūmų bandymus, siekiant patikrinti, ar naujajai versijai pavyksta atlikti pagrindinius funkcionalumus. Kai nauja paslauga išlaikys paskutinius bandymus, srautas gali būti saugiai ir automatiškai nukreiptas į ją, naudojant programinės įrangos maršrutą, kad sklandžiai valdytų eismo perjungimą nuo mėlynos iki žalios. Lygiai taip pat svarbu tai, kad kilus kritinėms, paskutinės minutės problemoms, iškilus kritinėms problemoms, paprasta sugrąžinti diegimą į mėlynąją versiją.
Eismo šešėlis
Eismo šešėliai yra panašūs į mėlynai žalius diegimus, tačiau, užuot naudoję sintetinius bandymus „žaliai“ aplinkai patvirtinti, maršruto parinkimo technologija dubliuoja visą gaunamą gamybos srautą ir atspindi atskirą bandomąjį diegimą, kuris dar nėra viešas. Taigi eismo šešėlis sukuria tikslų vaizdą apie tai, kas nutiktų, jei būtų įdiegta nauja versija, remiantis tikru srautu. Tuo pat metu eismo šešėlis užtikrina, kad bandymai neturės įtakos faktinei produkcijai. Praktiškai kūrėjai gali nuspręsti kopijuoti nustatytą procentinę užklausų dalį bandymų tarnybai, kur jie tada gali atlikti integracijos testavimą ir našumo palyginimą (rankiniu būdu arba automatinio CI / CD vamzdyno sistemoje).
Įmonių kūrėjai jau naudoja daugybę bandymo metodų, skirtų užtikrinti, kad naujas programos kodas atitiktų tam tikrus reikalavimus. Pavyzdžiui, vieneto ir funkciniai testai išlieka pagrindinėmis priemonėmis, kurias kodas turi išvalyti. Tačiau dėl mikropaslaugomis pagrįstų architektūrų pobūdžio visiško integravimo testavimas yra svarbesnis nei bet kada. Atsižvelgiant į tarpusavio priklausomybės apimtį ir ilgalaikio sąsajos dreifo riziką, būdingą mikropaslaugų architektūroms, sintetiniai bandymai vis tiek turi vertę, tačiau galiausiai nepakaks tiksliai atspindėti visos paslaugų sąveikos gamybos aplinkoje.
Keturios strategijos, vienas tikslas
Šie maršruto parinkimo būdai siūlo skirtingus, tačiau susijusius metodus, padedančius atrasti, sušvelninti ir išbandyti mikroservisais pagrįstų programų defektus. Jie yra veiksmingi įrankiai, šalinantys klaidas, našumo problemas ir saugumo spragas, ypač kai jie diegiami kaip nuolatinio integravimo ir pristatymo (CI / CD) vamzdyno dalis.
Kuris iš šių metodų yra tinkamiausias jūsų pačių atveju, labai priklausys nuo to, kokie rūpesčiai yra patys svarbiausi. Pavyzdžiui, pagrindiniam vartotojo sąsajos atnaujinimui gali būti labai naudinga atlikti A / B bandymus, o mėlynai žalios spalvos diegimas gali būti neįkainojamas, kad sužinotumėte, kaip nauja funkcija gali paveikti esamos duomenų saugyklos našumą.
Dažniausiai šių būdų derinys gali pasiūlyti geriausią aprėptį. Tačiau svarbu atsižvelgti į tai, kaip gerai kiekvienas integruosis į jūsų esamą plėtros modelį. Kanarų atskirų funkcijų diegimas gali būti geriau pritaikytas judriems kūrimo metodams, nei, pavyzdžiui, mėlynai žalios spalvos visiškų versijų diegimas. Nors eismo šešėliai gali suteikti puikų matomumą prieš diegiant programos našumą, tai gali būti sunku ir daug laiko reikalaujanti bei brangiai kainuojanti skaičiavimo išteklius.
Kad ir kaip jūs juos taikytumėte, tokie maršruto parinkimo būdai gali būti neįkainojama programinės įrangos kūrimo proceso dalis, ypač kai pramonė pereina nuo tradicinių, monolitinių programų prie debesų sistemos, pagrįstos mikroservisais. Taikydamos vieną, kai kuriuos ar visus šiuos metodus, nepamiršdamos savo specifinių pranašumų, programų grupės gali geriau užtikrinti savo projektų vientisumą ir sėkmę bei užtikrintiau pereiti prie gamybos.
Manuelis Zapfas yra „OS Containous“, debesų tinklo tinklo įmonės, vadovaujanti atvirojo kodo projektams „Traefik“ ir „Maesh“, vadovas.
—
Naujųjų technologijų forumas suteikia galimybę tyrinėti ir aptarti besiformuojančios įmonės technologijas beprecedentiame gylyje. Atranka yra subjektyvi, atsižvelgiant į mūsų pasirinktas technologijas, kurios, mūsų manymu, yra svarbios ir labiausiai domina skaitytojus. nepriima rinkodaros užtikrinimo priemonės paskelbimui ir pasilieka teisę redaguoti visą pateiktą turinį. Visus klausimus siųskite adresu [email protected].
