Alternatyvos

Mikroserviai yra ateitis. Jeigu kuri naują projektą — rinkis mikroservisų architektūrą. Mikroservisai padės tau išlaikyti paprastumą, kodo išskaidymą, bus paprasčiau leisti naujas versijas. Mirtis monolitams! Jeigu naudosi mikroservisus — pasaulyje įsivyraus taika.

Ne. Tai yra melas. Labai paplitęs melas. Taip paplitęs, kad juo tiki net daugelis patyrusių programuotojų, net gūglis tiki. Bet tai vis tiek yra melas, ant kurio tu, skaitytojau, turėtum nepasimauti. Mikroservisai yra tik viena iš daugelio architektūrų, turinti tiek privalumų, tiek trūkumų. Prieš nerdamas į ją turėtum žinoti, kad yra iš ko rinktis.

Monolitas

Pastaruoju metu ši architektūra yra labiausiai nuvertinama. Nepelnytai, nes tai yra pats paprasčiausias pasirinkimas naujiems projektams. Šiais laikais monolitais vadina ne tik tas programas, kuriose visas kodas sukištas į vieną didelį failą, bet ir normalias, modernias, moduliais išskaidytas sistemas, jeigu tie moduliai publikuojami (relyzinami) vienu metu.

Viskas ko reikia gražaus ir gyvybingo monolito išlaikymui — tai griežtas išskaidymas sluoksniais (layers), vieningo kodo išlaikymas visame projekte — turi būti naudojamas toks pats kodinimo stilius, naudojami tokie patys šablonai (patterns). Teiginys, kad monolitai ilgainiui tampa per dideli ir sunkiai plėtojami nėra visiškai teisingas, nes visos nuolat plėtojamos sistemos, nepriklausomai nuo architektūros ilgainiui tampa didelės ir sudėtingos. Vienintelis priešnuodis — švarus kodas.

Mikroservisai

Labai populiarus terminas šiais laikais. Tai lyg vaistas nuo visų ligų. Tačiau tai bene sudėtingiausia ir mažiausiai apibrėžta architektūra — neišprusėliai viską, kas ne monolitas vadina mikroservisu. Nebūk toks kaip kiti — jei kažkas yra ne mikro ir ne servisas, tai nėra mikroservisas.

Iš kur atsiranda tas mikroservisų sudėtingumas? Neskaitant versionavimo, testavimo, resursų išnaudojimo problemų, papildomai reikia dorotis ir su paralelinio programavimo iššūkiais:

  • Užsirakinimu (deadlock)
  • Lenktynėmis (race condition)
  • Badavimu (starvation)
  • Aklaviete (livelock)

Atskiro paminėjimo nusipelno užsirakinimas, dar vadinamas užsiciklinimu, nes skirtingai nei įprastose lygiagrečiose sistemose, kur užsirakinimas yra tik vienos ar dviejų programų problema, čia pasekmės gali būti daug liūdnesnės. Kai mikroservisas A nori duomenų iš mikroserviso B, o B nori iš A, tai jie vienas kito ir klausinėja. Čia nėra operacinės sistemos, kuri išlaikytų tvarką ir užtikrintų, kad C nebadautų, čia A ir B vienas su kitu besipykdami išnaudos visus tinklo išteklius ir taip nulauš ne tik savo sistemą, bet ir visas kitas, kurios gyvena tame pačiame tinkle.

Taip pat abejonių kelia mikroservisų ypatybė, kuri dažnai minima kaip privalumas — tai prisirišimo prie technologijų ar bibliotekų nebuvimas. Realybėje šis “privalumas” reiškia chaosą. Kai yra parašomas modulis egzotine programavimo kalba, o paskui to modulio programuotojas atsisveikina su visam, įmonei paliekamas didžiulis galvos skausmas. Taip būna, pats mačiau.

Dėl savo sudėtingumo mikroservisų komunikacija turi būti labai kruopščiai projektuojama ir koordinuojama labai patyrusių programuotojų, o stebėjimas (monitoring) yra ne rekomenduojamas, o būtinas.

Iš kur toks populiarumas?

Yra dvi pagrindinės priežastys kodėl mikroservisų architektūra yra visų žurnalų antraštėse.

Pirmoji — tai nauda didelei ir turtingai įmonei. Kadangi prie mikroservisų gali dirbti labai daug žmonių, vadovai tiesiog įmeta daugiau pinigų, pasamdo 100 naujų komandų ir produkto kūrimas pagreitėja 100 kartų. Realybėje 100 kartų pagreitėjimo nebus, bet lyginant su monolito architektūra, kur įmetus 100 naujų komandų vietoj pagreitėjimo būtų sustojimas, tai vis tiek yra labai gerai. Kitas privalumas įmonei — tai galimybė samdyti pigesnius, durnesnius, žemesnės kvalifikacijos programuotojus. Reikia tik vienos protingos komandos, kuri projektuotų ir nuodugniai išmanytų visą sistemą kaip visumą, o kitoms užtenka kvalifikuotis savo siauroje srityje.

Antroji — tai nauda debesų paslaugų tiekėjams. Jei pastebėjai, tai kai tik kalba pasisuka apie mikroservisus, iš karto išgirsti tokius keiksmažodžius kaip AWS, Azure ar GCP. Šioms platformoms labai patinka mikroservisai, nes jos ima pinigus už resursus. O mikroservisams resursų reikia daug. Tikrai daug. Galima prisiminti keliaujančio pirklio problemą: pačiu blogiausiu atveju, kai vienas mikroservisas kreipiasi į visus kitus mikroservisus, o tie kreipiasi į visus kitus, tai bus padaroma n! kreipimųsi. Priminsiu, kad n! yra antra iš greičiausiai augančių funkcijų, kokias tik žino matematikai. Realybėje tiek kreipinių niekada nebus, tai yra pats blogiausias atvejis. Visgi palyginus su monolitu, kur pats blogiausias atvejis yra 1, pasidaro aišku, kad su mikroservisais ką nors sušikti yra daug paprasčiau.

Kodėl tada rinktis mikroservisus?

Kad ir kokia sudėtinga ar neoptimali resursų atžvilgiu tai būtų architektūra, vis dėlto yra atvejų, kai ją rinktis tikrai verta, o kartais ir būtina.

  • Didelis programuotojų kolektyvas: kai prie projekto dirba labai daug žmonių, verta pradėti galvoti tiek apie mažų komandų kūrimą, tiek apie kodo skaidymą.
  • Veikimo aplinkos ribojimai: kai tam tikri komponentai turi veikti kitokios architektūros kompiuteriuose, kai yra keliami papildomi reikalavimai tinklui ar saugumui, yra logiška tas kritines vietas iškelti į atskirus (mikro)servisus.
  • Nutolusios sistemos: Kai dalis sistemos turi veikti trečių šalių aplinkoje, pvz. duomenų agregavimas iš vietinių įrenginių. Tas agregatorius gali veikti kaip mažas servisas.

Agentinės sistemos

Pasikartosiu, kad pasaulyje atsiranda vis daugiau žmonių, kurie viską, kas ne monolitas vadina mikroservisais. Tokiems žmonėms norėčiau primint, kad žodis “mikroservisas” nėra žodžio “architektūra” sinonimas. Pasaulyje yra daugiau architektūrų nei dvi. Viena jų — agentinės sistemos.

Tai architektūra asinchroninėms sistemoms, kurią galima naudoti patikimai atlikti užduotis nelabai patikimose (low availability) ar besikeičiančiose aplinkose.
Kai yra daromas kreipimasis į (mikro)servisą, yra laukiama kol jis gražins kokį nors rezultatą. Agentinės sistemos atveju yra suformuojamas darbas, kurį agentas pasiims ir padarys kai jam bus gera nuotaika. Jei jis darbo nepadarys, tą darbą gali pasiimti kitas agentas. Dažnai manoma, kad agentai turi turėti intelekto, bet tai netiesa, nes kompiuterių intelektas yra dirbtinis, netikras, tai ir imituoti jo dažniausiai neapsimoka.

Realaus pasaulio pavyzdys būtų kirpėja ir šiukšliavežys:

  • Kai nueini į kirpyklą tave kirps tol, kol iki galo nesuteiks šio mikroserviso.
  • Kai šiukšles išpili į konteinerį, net nesusimąstai kada atvažiuos agentai šiukšlininkai ir jį ištuštins. Tu gyveni savo gyvenimą, jie — savo. Tau svarbu tik, kad konteineris būtų neperpildytas. Šiukšlininkai gali naudotis intelektu nustatant kada tas šiukšles išvežti arba gali tiesiog atvažiuoti kiekvieną antradienį. Jei koks šiukšlininkas susirgo — jį pavaduos kolega.

Apsikeitimo žinutėmis sistemos

Tai dar viena architektūra, kuri yra nepelnytai nustelbta mikroservisų. Mikroservisai, kaip kokie rusai, sako, kad tai yra teisėta vien tik jų dalis. Iš tiesų Message queue sistemos gali egzistuoti tiek kaip autonominė architektūra, tiek kaip bet kurios kitos architektūros papildymas. Jei sistema yra asinchroninė, tai ji nebūtina yra mikroservisas.

MQ yra labai panaši į agentines sistemas, skirtumas tas, kad suformavus darbą yra iškarto išsiunčiama žinutė, kad yra darbas ir koks tas darbas. Tada tas, kas gali tą darbą atlikti (consumer) jį pasiima ir apdoroja. Agentų atveju, jie patys ieškosi darbų, jei reikia bendrauja tarpusavyje ar net naudoja intelektą.

Tai ką dabar man rinktis naujam projektui?

Būkim biedni, bet teisingi — didžioji dalis naujų projektų užsilenkia dar net nepasiekę klientų, tavasis bus ne išimtis. Kam tau švaistyti laiką ir energiją sudėtingoms architektūroms, kai gali nueiti paprasčiausiu keliu — monolitu. Jei tavo projektas pasiteisins, atsiras vartotojų, išaugs realus poreikis didinti sudėtingumą — galėsi pasirinkti ką nors sudėtingiau. Jei būsi geras architektas — nenaudosi tik vieno varianto, o kombinuosi kelis, nes radikalų nemėgsta niekas.

Viso šio straipsnio esmė nėra “nenaudok mikroservisų”, šio straipsio esmė yra “nenaudok replių viniui kalti“.