ProHoster > Blog > Administrimi > MikroshĂ«rbimet — shpĂ«rthim kombinatorik i versioneve

MikroshĂ«rbimet — shpĂ«rthim kombinatorik i versioneve

PĂ«rshĂ«ndetje, Habr! Po ju paraqes pĂ«rkthimin ekskluziv tĂ« artikullit Microservices – Eksplozion Kombinatorial i Versioneve.
MikroshĂ«rbimet — shpĂ«rthim kombinatorik i versioneve
Në kohën kur bota IT po kalon gradualisht në mikroservica dhe mjete si Kubernetes, një problem i vetëm po bëhet gjithnjë e më i dukshëm. Ky problem është eksplozioni kombinatorial i versioneve të mikroservicave. Megjithatë, komuniteti IT beson se situata e sotme është dukshëm më e mirë se «Hell-i i varësive» i brezit të mëparshëm të teknologjive. Megjithatë, menaxhimi i versioneve të mikroservicave është një problem shumë kompleks. Një dëshmi për këtë mund të jetë artikujt si «Më kthe monolitin tim».

NĂ«se po e lexoni kĂ«tĂ« tekst dhe nuk e kuptoni problemin, mĂ« lejoni ta shpjegoj. Supozoni se produkti juaj pĂ«rbĂ«het nga 10 mikroservica. Tani supozoni se pĂ«r secilin nga kĂ«ta mikroservica del 1 version i ri. VetĂ«m 1 version — shpresoj tĂ« gjithĂ« mund tĂ« pajtohemi se kjo Ă«shtĂ« njĂ« fakt shumĂ« trivial dhe i parĂ«ndĂ«sishĂ«m. Tani, megjithatĂ«, le tĂ« shikojmĂ« pĂ«rsĂ«ri produktin tonĂ«. Me njĂ« version tĂ« ri pĂ«r secilin komponent tani kemi 2^10 — ose 1024 permutacione se si mund ta formojmĂ« produktin tonĂ«.

NĂ«se ende ka paqartĂ«si, le tĂ« shpjegoj matematikĂ«n. Pra, kemi 10 mikroservica, secili merr njĂ« pĂ«rditĂ«sim. Kjo do tĂ« thotĂ« se ne kemi 2 versionet e mundshme pĂ«r çdo mikroservic (ose versionin e vjetĂ«r, ose atĂ« tĂ« ri). Tani, pĂ«r secilin nga komponentĂ«t e produktit ne mund tĂ« pĂ«rdorim cilin do nga kĂ«to dy versionet. Matematika e bĂ«n kĂ«tĂ« tĂ« njĂ«jtĂ« si tĂ« kishim njĂ« numĂ«r binar prej 10 shifrash. PĂ«r shembull, le tĂ« themi se 1 Ă«shtĂ« versioni i ri, dhe 0 Ă«shtĂ« versioni i vjetĂ«r — kĂ«shtu qĂ« njĂ« permutacion i mundshĂ«m mund tĂ« shĂ«nohet si 1001000000 — ku komponentĂ«t e parĂ« dhe tĂ« katĂ«rt janĂ« pĂ«rditĂ«suar, ndĂ«rsa tĂ« tjerĂ«t jo. Nga matematika e dimĂ« se njĂ« numĂ«r binar prej 10 shifrash mund tĂ« ketĂ« 2^10 ose 1024 vlera. Pra, ne e kemi konfirmuar shkallĂ«n e numrit me tĂ« cilin kemi tĂ« bĂ«jmĂ«.

TĂ« vazhdojmĂ« reflektimet — çfarĂ« do tĂ« ndodhte nĂ«se do tĂ« kishim 100 mikroservica dhe secili prej tyre 10 versione tĂ« mundshme? TĂ« gjitha situata bĂ«het shumĂ« e pakĂ«ndshme — tani kemi 10^100 permutacione — dhe ky Ă«shtĂ« njĂ« numĂ«r i madh. MegjithatĂ«, preferoj ta pĂ«rshkruaj kĂ«tĂ« situatĂ« pikĂ«risht kĂ«shtu, sepse tani nuk po fshihemi pas fjalĂ«ve si «kubernetes», por po e pĂ«rballemi problemin siç Ă«shtĂ«.

Pse mĂ« tĂ«rheq kaq shumĂ« ky problem? PjesĂ«risht sepse punova mĂ« parĂ« nĂ« botĂ«n e NLP dhe AI, kemi diskutuar shumĂ« pĂ«r problematikĂ«n e eksplozionit kombinatioral rreth 5-6 vjet mĂ« parĂ«. VetĂ«m se, nĂ« vend tĂ« versioneve, ne kishim fjalĂ« tĂ« veçanta, dhe nĂ« vend tĂ« produkteve, kishim fjali dhe paragrafĂ«. Dhe megjithĂ«se problemet e NLP dhe AI mbeten deri nĂ« njĂ« masĂ« tĂ« madhe tĂ« pacaktuara, duhet tĂ« pranojmĂ« se gjatĂ« disa viteve tĂ« fundit Ă«shtĂ« bĂ«rĂ« pĂ«rparim i dukshĂ«m (sipariƟtrani, pĂ«rparimi do tĂ« kishte mundur tĂ« ishte mĂ« iomĂ« shumĂ«, nĂ«se njerĂ«zit nĂ« industri do t’u kushtonin pak mĂ« pak vĂ«mendje mĂ«simit tĂ« makinerive dhe pak mĂ« shumĂ« teknikave tĂ« tjera — por kjo Ă«shtĂ« tashmĂ« njĂ« temĂ« tjetĂ«r).

TĂ« kthehemi te bota e DevOps dhe mikroservicave. Para nesh Ă«shtĂ« njĂ« problem i madh, qĂ« fshehesh si njĂ« elefant nĂ« qendĂ«r tĂ« artit — sepse ajo qĂ« dĂ«gjoj shpesh Ă«shtĂ« — «thjesht merr kubernetes dhe helm, dhe gjithçka do tĂ« jetĂ« mirĂ«!» Por jo, gjithçka nuk do tĂ« jetĂ« mirĂ« nĂ«se gjĂ«rat lihen siç janĂ«. MĂ« shumĂ« pĂ«r, njĂ« zgjidhje analitike e kĂ«tij problemi nuk duket e pranueshme pĂ«r shkak tĂ« kompleksitetit. Si nĂ« NLP, duhet tĂ« afrohemi fillimisht kĂ«tij problemi duke ngushtuar fushĂ«n e kĂ«rkimit — nĂ« kĂ«tĂ« rast, duke pĂ«rjashtuar permutacionet e vjetra.

NjĂ« nga gjĂ«rat qĂ« mund tĂ« ndihmojĂ« — kam shkruar vitin e kaluar nĂ« lidhje me nevojĂ«n pĂ«r tĂ« mbajtur njĂ« dallim minimal midis versioneve tĂ« publikuara pĂ«r klientĂ«t. Gjithashtu, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se njĂ« proces i mirĂ« i CI/CD ndihmon shumĂ« nĂ« reduktimin e variacioneve. MegjithatĂ«, situata e sotme me CI/CD nuk Ă«shtĂ« mjaft e mirĂ« pĂ«r tĂ« zgjidhur problemin e permutacioneve pa mjete shtesĂ« pĂ«r llogaritjen dhe ndjekjen e komponentĂ«ve.

Ajo qĂ« na nevojitet — Ă«shtĂ« njĂ« sistem eksperimentesh nĂ« fazĂ«n e integrimit, ku mund tĂ« pĂ«rcaktojmĂ« faktorĂ«t e rrezikut pĂ«r çdo komponent, si dhe tĂ« kemi njĂ« proces automatizimi pĂ«r pĂ«rditĂ«simin e komponentĂ«ve tĂ« ndryshĂ«m dhe testimin pa ndĂ«rhyrjen e operatoret — pĂ«r tĂ« parĂ« se çfarĂ« funksionon dhe çfarĂ« jo.

Një sistem i tillë eksperimentesh mund të duket si më poshtë:

  1. Zhvilluesit shkruajnĂ« teste (ky Ă«shtĂ« njĂ« hap kritik — sepse nĂ« tĂ« kundĂ«rt, ne nuk kemi njĂ« kriter vlerĂ«simi — kjo Ă«shtĂ« si etiketimi i tĂ« dhĂ«nave nĂ« mĂ«simin e makinerive).
  2. Çdo komponent (projekt) merr sistemin e vet CI — ky proces Ă«shtĂ« punuar mirĂ« deri tani, dhe çështja e krijimit tĂ« njĂ« sistemi CI pĂ«r njĂ« komponent tĂ« veçantĂ« Ă«shtĂ« nĂ« shumicĂ«n e rasteve e zgjidhur
  3. Sistemi i menaxhimit tĂ« integrimeve mbledh rezultatet e sistemave tĂ« ndryshme CI dhe grumbullon projektet-komponentĂ« nĂ« njĂ« produkt pĂ«rfundimtar, nis testimin dhe nĂ« fund llogarit rrugĂ«n mĂ« tĂ« shkurtĂ«r pĂ«r tĂ« arritur funksionalitetin e dĂ«shiruar tĂ« produktit bazuar nĂ« komponentĂ«t ekzistues dhe faktorĂ«t e rrezikut. NĂ«se pĂ«rditĂ«simi nuk Ă«shtĂ« i mundur, ky sistem i njofton zhvilluesit pĂ«r komponentĂ«t e disponueshĂ«m dhe pĂ«r cilin prej tyre ndodhi gabimi. Ta themi pĂ«rsĂ«ri, sistemi i testeve kĂ«tu ka rĂ«ndĂ«si kritike — pasi sistemi i integrimeve pĂ«rdor testet si kriter vlerĂ«simi.
  4. Sistemi CD, i cili pastaj merr të dhënat nga «Sistemi i menaxhimit të integrimeve» dhe realizon përditësimin. Ky stad përfundon ciklin.

PĂ«r sa i pĂ«rket pĂ«rmbledhjes, njĂ« nga problemet mĂ« tĂ« mĂ«dha pĂ«r mua tani Ă«shtĂ« mungesa e njĂ« «Sistemi tĂ« menaxhimit tĂ« integrimeve» qĂ« do tĂ« lidhte komponentĂ«t e ndryshĂ«m nĂ« njĂ« produkt dhe kĂ«shtu do tĂ« lejonte tĂ« monitorohej si Ă«shtĂ« formuar produkti nĂ« tĂ«rĂ«si. Do tĂ« isha i interesuar pĂ«r mendimet e komunitetit rreth kĂ«saj (spoiler — tani po punoj nĂ« njĂ« projekt Reliza, i cili mund tĂ« bĂ«het njĂ« sistem i tillĂ« i menaxhimit tĂ« integrimeve).

NjĂ« gjĂ« e fundit qĂ« dua tĂ« pĂ«rmend — pĂ«r mua, monoliti nuk Ă«shtĂ« i pranueshĂ«m pĂ«r asnjĂ« projekt tĂ« paktĂ«n mesatar. Kam skeptikizĂ«m tĂ« madh ndaj pĂ«rpjekjeve pĂ«r tĂ« pĂ«rshpejtuar kohĂ«n e realizimit dhe cilĂ«sinĂ« e zhvillimit pĂ«rmes rikthimit nĂ« monolit. SĂ« pari, monoliti ka njĂ« problem tĂ« ngjashĂ«m me menaxhimin e komponentĂ«ve — mes bibliotekave tĂ« ndryshme, nga tĂ« cilat pĂ«rbĂ«het, por kjo nuk Ă«shtĂ« aq e dukshme dhe shfaqet kryesisht nĂ« kohĂ«n qĂ« shpenzojnĂ« zhvilluesit. Si pasojĂ« e problemit me monolitin Ă«shtĂ« pamundĂ«sia reale pĂ«r tĂ« bĂ«rĂ« ndryshime nĂ« kod — dhe njĂ« shpejtĂ«si tĂ« zhvillimit shumĂ« tĂ« ngadaltĂ«.

MikroshĂ«rbimet e pĂ«rmirĂ«sojnĂ« situatĂ«n, megjithatĂ« mĂ« pas arkitektura e mikroshĂ«rbimeve has njĂ« problem tĂ« shpĂ«rthimit kombinatorial nĂ« fazĂ«n e integrimit. Po, nĂ« pĂ«rgjithĂ«si, ne e kemi lĂ«vizur tĂ« njĂ«jtin problem — nga faza e zhvillimit nĂ« fazĂ«n e integrimit. MegjithatĂ«, nĂ« mendimin tim, qasja e mikroshĂ«rbimeve prapĂ« sjell rezultate mĂ« tĂ« mira, dhe ekipet arrijnĂ« rezultate mĂ« shpejt (ndoshta kryesisht pĂ«r shkak tĂ« reduktimit tĂ« madhĂ«sive tĂ« njĂ«sisĂ« sĂ« zhvillimit — ose batch size). MegjithatĂ«, kalimi nga monoliti nĂ« mikroshĂ«rbime nuk ka dhĂ«nĂ« ende pĂ«rmirĂ«simin e mjaftueshĂ«m tĂ« procesit — shpĂ«rthimi kombinatorial i versioneve tĂ« mikroshĂ«rbimeve Ă«shtĂ« njĂ« problem i madh, dhe ne kemi njĂ« potencial tĂ« madh pĂ«r pĂ«rmirĂ«simin e situatĂ«s ndĂ«rsa e zgjidhim atĂ«.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster