Sveiki, Habr! Pristatau jūsų dėmesiui autoriaus straipsnio vertimas .
Tuo metu, kai IT pasaulis pamažu juda prie mikropaslaugų ir įrankių, tokių kaip „Kubernetes“, vis labiau pastebima tik viena problema. Ši problema - mikro paslaugų versijos. Visgi IT bendruomenė mano, kad dabartinė situacija yra daug geresnė nei ankstesnės kartos technologija. Tačiau mikropaslaugų versijų kūrimas yra labai sudėtinga problema. Vienas iš to įrodymų gali būti tokie straipsniai kaip .
Jei skaitydami šį tekstą vis tiek nesuprantate problemos, leiskite man paaiškinti. Tarkime, kad jūsų produktą sudaro 10 mikro paslaugų. Dabar tarkime, kad kiekvienai iš šių mikropaslaugų yra išleista 1 nauja versija. Tik 1 versija – tikiuosi visi sutiksime, kad tai labai trivialus ir nereikšmingas faktas. Tačiau dabar dar kartą pažvelkime į mūsų produktą. Turėdami tik vieną naują kiekvieno komponento versiją, dabar turime 2^10 arba 1024 permutacijas, kaip galima sukurti mūsų produktą.
Jei vis dar yra kokių nors nesusipratimų, leiskite man išskaidyti matematiką. Taigi turime 10 mikro paslaugų, kurių kiekviena gauna po vieną atnaujinimą. Tai reiškia, kad kiekvienai mikro paslaugai (senai arba naujai) gauname 2 galimas versijas. Dabar kiekvienam produkto komponentui galime naudoti bet kurią iš šių dviejų versijų. Matematiškai tai tas pats, lyg turėtume dvejetainį 10 skaitmenų skaičių. Pavyzdžiui, tarkime, kad 1 yra nauja versija, o 0 yra senoji versija – tada viena galima permutacija gali būti pažymėta kaip 1001000000 – kur 1-as ir 4-asis komponentai atnaujinami, o visi kiti ne. Iš matematikos žinome, kad 10 skaitmenų dvejetainis skaičius gali turėti 2^10 arba 1024 reikšmes. Tai yra, mes patvirtinome skaičiaus, su kuriuo susiduriame, mastą.
Tęskime savo samprotavimus toliau – kas bus, jei turėsime 100 mikropaslaugų ir kiekviena turės po 10 galimų versijų? Visa situacija tampa gana nemaloni – dabar turime 10^100 permutacijų – tai yra didžiulis skaičius. Tačiau man labiau patinka šią situaciją pavadinti taip, nes dabar nebeslepiame už tokių žodžių kaip „kubernetes“, o susiduriame su problema tokia, kokia ji yra.
Kodėl mane taip žavi ši problema? Iš dalies todėl, kad anksčiau dirbę NLP ir AI pasaulyje, maždaug prieš 5–6 metus daug diskutavome apie kombinatorinio sprogimo problemą. Tik vietoj versijų turėjome atskirus žodžius, o vietoj gaminių – sakinius ir pastraipas. Ir nors NLP ir AI problemos iš esmės lieka neišspręstos, reikia pripažinti, kad per pastaruosius kelerius metus buvo padaryta didelė pažanga. (mano nuomone, pažanga gali būti padarytaоBūtų geriau, jei pramonės žmonės šiek tiek mažiau dėmesio skirtų mašininiam mokymuisi ir šiek tiek daugiau kitoms technikoms – bet tai jau ne į temą).
Grįžkime į „DevOps“ ir mikropaslaugų pasaulį. Mes susiduriame su didžiule problema, apsimetę drambliu Kunstkameroje – nes dažnai girdžiu: „Tiesiog imk kubernetes ir vairą, ir viskas bus gerai! Bet ne, viskas nebus gerai, jei viskas bus palikta kaip yra. Be to, analitinis šios problemos sprendimas neatrodo priimtinas dėl jos sudėtingumo. Kaip ir NLP, pirmiausia turėtume spręsti šią problemą susiaurindami paieškos apimtį – šiuo atveju pašalindami pasenusias permutacijas.
Vienas iš dalykų, kuris gali padėti, yra tai, ką parašiau praėjusiais metais . Taip pat svarbu pažymėti, kad gerai suplanuotas CI / CD procesas labai padeda sumažinti skirtumus. Tačiau dabartinė CI/CD padėtis nėra pakankamai gera, kad būtų galima išspręsti permutacijų problemą be papildomų apskaitos ir komponentų sekimo įrankių.
Mums reikia eksperimentavimo sistemos integravimo etape, kurioje galėtume nustatyti kiekvieno komponento rizikos faktorių, taip pat turėti automatizuotą įvairių komponentų atnaujinimo ir testavimo procesą be operatoriaus įsikišimo – pamatyti, kas veikia, o kas ne.
Tokia eksperimentų sistema galėtų atrodyti taip:
- Kūrėjai rašo testus (tai kritinis etapas – nes kitu atveju neturime vertinimo kriterijaus – tai tarsi duomenų žymėjimas mašininio mokymosi metu).
- Kiekvienas komponentas (projektas) gauna savo CI sistemą - šis procesas dabar yra gerai išvystytas, o CI sistemos sukūrimo vienam komponentui klausimas iš esmės išspręstas
- „Išmaniosios integracijos sistema“ renka įvairių CI sistemų rezultatus ir surenka komponentų projektus į galutinį produktą, atlieka testavimą ir galiausiai apskaičiuoja trumpiausią kelią iki pageidaujamo produkto funkcionalumo, remdamasi esamais komponentais ir rizikos veiksniais. Jei atnaujinti neįmanoma, ši sistema praneša kūrėjams apie esamus komponentus ir kurie iš jų sukelia klaidą. Vėlgi, testų sistema čia yra labai svarbi, nes integravimo sistema naudoja testus kaip vertinimo kriterijų.
- CD sistema, kuri vėliau gauna duomenis iš Smart Integration System ir tiesiogiai atlieka atnaujinimą. Šis etapas užbaigia ciklą.
Apibendrinant, man viena didžiausių problemų šiuo metu yra tokios „Išmaniosios integracijos sistemos“, kuri susietų įvairius komponentus į gaminį ir taip leistų sekti, kaip visas produktas yra sudėtas, trūkumas. Man bus įdomios bendruomenės mintys šiuo klausimu (spoileris – šiuo metu dirbu su projektu , kuri gali tapti tokia išmania integravimo sistema).
Paskutinis dalykas, kurį noriu paminėti, yra tai, kad man monolitas nėra priimtinas jokiam net ir vidutinio dydžio projektui. Didelį skepticizmą man kelia bandymai pagreitinti diegimo laiką ir kūrimo kokybę grįžtant prie monolito. Pirma, monolitas turi panašią komponentų valdymo problemą - tarp įvairių bibliotekų, iš kurių jis susideda, tačiau visa tai nėra taip pastebima ir pirmiausia pasireiškia kūrėjų praleidžiamu laiku. Monolito problemos pasekmė yra virtualus kodo pakeitimų neįmanomas ir itin lėtas kūrimo greitis.
Mikropaslaugos pagerina situaciją, tačiau tada mikro paslaugų architektūra susiduria su kombinacinio sprogimo problema integracijos etape. Taip, apskritai tą pačią problemą iš kūrimo etapo perkėlėme į integracijos etapą. Tačiau, mano nuomone, mikropaslaugų požiūris vis tiek veda prie geresnių rezultatų, o komandos greičiau pasiekia rezultatų (tikriausiai daugiausia dėl to, kad sumažėjo plėtros padalinio – arba partijos dydis). Tačiau perėjimas nuo monolitinių prie mikropaslaugų dar nepakankamai patobulino procesą – kombinacinis mikroserviso versijų sprogimas yra didžiulė problema, kurią spręsdami turime daug galimybių pagerinti situaciją.
Šaltinis: www.habr.com