ProHoster > Blogs > Administrācija > Mikropakalpojumi - kombinatorisks versiju sprādziens

Mikropakalpojumi - kombinatorisks versiju sprādziens

Sveiks, Habr! Es piedāvāju jÅ«su uzmanÄ«bu raksta autora tulkojums Mikropakalpojumi ā€“ versiju kombinatoriskā eksplozija.
Mikropakalpojumi - kombinatorisks versiju sprādziens
Laikā, kad IT pasaule pamazām virzās uz tādiem mikropakalpojumiem un rÄ«kiem kā Kubernetes, arvien pamanāmāka kļūst tikai viena problēma. Å Ä« problēma - kombinatoriskais sprādziens mikropakalpojumu versijas. Tomēr IT sabiedrÄ«ba uzskata, ka paÅ”reizējā situācija ir daudz labāka nekā "AtkarÄ«bas elle" iepriekŔējās paaudzes tehnoloÄ£ijas. Tomēr mikropakalpojumu versiju veidoÅ”ana ir ļoti sarežģīta problēma. Viens no pierādÄ«jumiem tam var bÅ«t tādi raksti kā "Atdod man manu monolÄ«tu".

Ja, izlasot Å”o tekstu, joprojām nesaprotat problēmu, ļaujiet man paskaidrot. Pieņemsim, ka jÅ«su produkts sastāv no 10 mikropakalpojumiem. Tagad pieņemsim, ka katram no Å”iem mikropakalpojumiem ir izlaista 1 jauna versija. Tikai 1 versija - ceru, ka mēs visi varam piekrist, ka tas ir ļoti triviāls un nenozÄ«mÄ«gs fakts. Tomēr tagad vēlreiz aplÅ«kosim mÅ«su produktu. Izmantojot tikai vienu jaunu katra komponenta versiju, mums tagad ir 2^10 jeb 1024 permutācijas, kā var izveidot mÅ«su produktu.

Ja joprojām ir kāds pārpratums, ļaujiet man sadalÄ«t matemātiku. Tātad mums ir 10 mikropakalpojumi, no kuriem katrs saņem vienu atjauninājumu. Tas ir, mēs iegÅ«stam 2 iespējamās versijas katram mikropakalpojumam (vai nu vecam, vai jaunam). Tagad katrai produkta sastāvdaļai mēs varam izmantot vienu no Ŕīm divām versijām. Matemātiski tas ir tāpat kā tad, ja mums bÅ«tu 10 ciparu binārs skaitlis. Piemēram, pieņemsim, ka 1 ir jaunā versija, bet 0 ir vecā versija - tad vienu iespējamo permutāciju var apzÄ«mēt kā 1001000000 - kur 1. un 4. komponents tiek atjaunināts, bet visi pārējie nav. No matemātikas mēs zinām, ka 10 ciparu bināram skaitlim var bÅ«t 2^10 vai 1024 vērtÄ«bas. Tas ir, mēs esam apstiprinājuÅ”i skaitļa mērogu, ar kuru mums ir darÄ«Å”ana.

Turpināsim savu spriedumu tālāk ā€“ kas notiks, ja mums bÅ«s 100 mikropakalpojumi un katram bÅ«s 10 iespējamās versijas? Visa situācija kļūst diezgan nepatÄ«kama - tagad mums ir 10^100 permutācijas - tas ir milzÄ«gs skaits. Tomēr man labāk patÄ«k Å”o situāciju apzÄ«mēt Ŕādi, jo tagad mēs vairs neslēpjamies aiz tādiem vārdiem kā ā€œkubernetesā€, bet gan skatāmies uz problēmu tādu, kāda tā ir.

Kāpēc mani tik ļoti aizrauj Ŕī problēma? Daļēji tāpēc, ka, iepriekÅ” strādājot NLP un AI pasaulē, mēs apmēram pirms 5-6 gadiem daudz apspriedām kombinatoriskās sprādziena problēmu. Tikai versiju vietā mums bija atseviŔķi vārdi, bet produktu vietā teikumi un rindkopas. Un, lai gan NLP un AI problēmas lielākoties joprojām nav atrisinātas, jāatzÄ«st, ka pēdējos gados ir panākts ievērojams progress. (manuprāt, progress varētu bÅ«tŠ¾BÅ«tu labāk, ja nozares cilvēki nedaudz mazāk uzmanÄ«bas pievērstu maŔīnmācÄ«bai un nedaudz vairāk citiem paņēmieniem ā€“ bet tas jau ir ārpus tēmas).

AtgriezÄ«simies DevOps un mikropakalpojumu pasaulē. Mēs saskaramies ar milzÄ«gu problēmu, maskējoties par ziloni Kunstkamerā, jo bieži dzirdu: "VienkārÅ”i paņemiet kubernetes un stÅ«ri, un viss bÅ«s kārtÄ«bā!" Bet nē, viss nebÅ«s labi, ja viss paliks kā ir. Turklāt Ŕīs problēmas analÄ«tisks risinājums neŔķiet pieņemams tās sarežģītÄ«bas dēļ. Tāpat kā NLP, mums vispirms vajadzētu pievērsties Å”ai problēmai, saÅ”aurinot meklÄ“Å”anas jomu, Å”ajā gadÄ«jumā novērÅ”ot novecojuÅ”as permutācijas.

Viena no lietām, kas varētu palÄ«dzēt, ir tas, ko es uzrakstÄ«ju pagājuÅ”ajā gadā par nepiecieÅ”amÄ«bu saglabāt minimālu atŔķirÄ«bu starp klientiem publicētajām versijām. Ir arÄ« svarÄ«gi atzÄ«mēt, ka labi izstrādāts CI/CD process ievērojami palÄ«dz samazināt atŔķirÄ«bas. Tomēr paÅ”reizējais stāvoklis ar CI/CD nav pietiekami labs, lai atrisinātu permutāciju problēmu bez papildu rÄ«kiem uzskaites un izsekoÅ”anas komponentiem.

Mums ir nepiecieÅ”ama eksperimentu sistēma integrācijas posmā, kurā mēs varam noteikt riska faktoru katram komponentam, kā arÄ« ir automatizēts process dažādu komponentu atjaunināŔanai un testÄ“Å”anai bez operatora iejaukÅ”anās - lai redzētu, kas darbojas un kas ne.

Šāda eksperimentu sistēma varētu izskatÄ«ties Ŕādi:

  1. Izstrādātāji raksta testus (tas ir kritisks posms ā€” jo pretējā gadÄ«jumā mums nav vērtÄ“Å”anas kritērija ā€” tas ir kā datu marÄ·Ä“Å”ana maŔīnmācÄ«bā).
  2. Katrs komponents (projekts) saņem savu CI sistēmu - Å”is process tagad ir labi attÄ«stÄ«ts, un lielā mērā ir atrisināts jautājums par CI sistēmas izveidi vienam komponentam.
  3. ā€œViedā integrācijas sistēmaā€ apkopo dažādu CI sistēmu rezultātus un komplektē komponentu projektus galaproduktā, veic testÄ“Å”anu un visbeidzot aprēķina Ä«sāko ceļu lÄ«dz vēlamās produkta funkcionalitātes iegÅ«Å”anai, pamatojoties uz esoÅ”ajiem komponentiem un riska faktoriem. Ja atjauninājums nav iespējams, Ŕī sistēma informē izstrādātājus par esoÅ”ajiem komponentiem un to, kurÅ” no tiem izraisa kļūdu. Pārbaužu sistēmai Å”eit atkal ir izŔķiroÅ”a nozÄ«me - jo integrācijas sistēma izmanto testus kā vērtÄ“Å”anas kritēriju.
  4. CD sistēma, kas pēc tam saņem datus no viedās integrācijas sistēmas un tieÅ”i veic atjaunināŔanu. Å is posms beidz ciklu.

Rezumējot, man Å”obrÄ«d viena no lielākajām problēmām ir tādas ā€œViedās integrācijas sistēmasā€ trÅ«kums, kas saistÄ«tu dažādas sastāvdaļas produktā un tādējādi ļautu izsekot, kā produkts kopumā tiek salikts. Mani interesēs kopienas domas par Å”o (spoileris - paÅ”laik strādāju pie projekta Reliza, kas var kļūt par tik gudru integrācijas sistēmu).

Pēdējais, ko es vēlos pieminēt, ir tas, ka, manuprāt, monolÄ«ts nav pieņemams nevienam pat vidēja izmēra projektam. Manā skatÄ«jumā lielu skepsi izraisa mēģinājumi paātrināt ievieÅ”anas laiku un izstrādes kvalitāti, atgriežoties pie monolÄ«ta. Pirmkārt, monolÄ«tam ir lÄ«dzÄ«ga komponentu pārvaldÄ«bas problēma - starp dažādām bibliotēkām, no kurām tas sastāv, tomēr tas viss nav tik pamanāms un galvenokārt izpaužas izstrādātāju pavadÄ«tajā laikā. MonolÄ«ta problēmas sekas ir virtuāla neiespējamÄ«ba veikt izmaiņas kodā un ārkārtÄ«gi lēns izstrādes ātrums.

Mikropakalpojumi situāciju uzlabo, bet tad mikropakalpojumu arhitektÅ«ra integrācijas stadijā saskaras ar kombinatoriskās eksplozijas problēmu. Jā, kopumā mēs to paÅ”u problēmu esam pārcēluÅ”i no izstrādes stadijas uz integrācijas posmu. Taču, manuprāt, mikropakalpojumu pieeja tomēr noved pie labākiem rezultātiem, un komandas ātrāk sasniedz rezultātus (iespējams, galvenokārt tāpēc, ka samazinās izstrādes vienÄ«bas apjoms - vai partijas lielums). Taču pāreja no monolÄ«ta uz mikropakalpojumiem vēl nav pietiekami uzlabojusi procesu ā€“ mikropakalpojumu versiju kombinatoriskais sprādziens ir milzÄ«ga problēma, un mums ir liels potenciāls situāciju uzlabot, to risinot.

Avots: www.habr.com

Pievieno komentāru