rugsėjo 19 d., Maskvoje pirmasis teminis susitikimas HUG (Highload++ User Group), kuris buvo skirtas mikropaslaugoms. Vyko pristatymas „Operating Microservices: Size Matters, Net If You Have Kubernetes“, kuriame pasidalinome plačia Flant patirtimi valdant projektus su mikro paslaugų architektūra. Visų pirma, tai bus naudinga visiems kūrėjams, kurie galvoja apie šio metodo naudojimą savo dabartiniame ar būsimame projekte.
Pristatome (50 minučių, daug informatyvesnis nei straipsnis), taip pat pagrindinė ištrauka iš jo teksto forma.
NB: vaizdo įrašą ir pristatymą taip pat rasite šio įrašo pabaigoje.
įvedimas
Paprastai gera istorija turi pradžią, pagrindinį siužetą ir sprendimą. Šis pranešimas labiau panašus į preliudiją ir tuo pačiu tragišką. Taip pat svarbu pažymėti, kad tai suteikia pašalinių asmenų požiūrį į mikropaslaugas. išnaudojimas.
Pradėsiu nuo šio grafiko, kurio autorius (2015 m.) Martinas Fowleris:
Tai parodo, kaip monolitinio pritaikymo atveju, kuris pasiekia tam tikrą vertę, produktyvumas pradeda mažėti. Mikropaslaugos skiriasi tuo, kad pradinis produktyvumas jomis yra mažesnis, tačiau didėjant sudėtingumui efektyvumo pablogėjimas joms nėra toks pastebimas.
Prie šios grafikos pridėsiu Kubernetes naudojimo atveju:
Kodėl programa su mikropaslaugomis yra geresnė? Nes tokia architektūra kelia rimtus reikalavimus architektūrai, kuriuos savo ruožtu puikiai atitinka Kubernetes galimybės. Kita vertus, kai kurios šios funkcijos bus naudingos monolitui, ypač todėl, kad tipiškas šiandieninis monolitas nėra visiškai monolitas (išsami informacija bus pateikta vėliau).
Kaip matote, galutinis grafikas (kai infrastruktūroje su Kubernetes yra ir monolitinės, ir mikropaslaugų programos) nelabai skiriasi nuo pradinio. Toliau kalbėsime apie programas, valdomas naudojant Kubernetes.
Naudingos ir kenksmingos mikropaslaugos
Ir čia yra pagrindinė mintis:
Kas yra normalus mikro paslaugų architektūra? Tai turėtų atnešti jums realios naudos, padidinti jūsų darbo efektyvumą. Jei grįšime prie grafiko, čia jis yra:
Jei jai paskambinsi naudinga, tada kitoje grafiko pusėje bus kenksmingas mikropaslaugos (trukdo darbui):
Grįžtant prie „pagrindinės minties“: ar apskritai turėčiau pasitikėti savo patirtimi? Nuo šių metų pradžios žiūriu 85 projektai. Ne visos jos buvo mikropaslaugos (apie trečdalis – pusė jų turėjo tokią architektūrą), bet tai vis tiek yra didelis skaičius. Mes (Flant company) kaip užsakovai sugebame pamatyti įvairiausių programų, sukurtų tiek mažose įmonėse (su 5 kūrėjais), tiek didelėse (~500 kūrėjų). Papildomas pranašumas yra tai, kad matome, kad šios programos veikia ir bėgant metams tobulėja.
Kodėl mikropaslaugos?
Į klausimą apie mikropaslaugų naudą yra iš jau minėto Martino Fowlerio:
- aiškios moduliškumo ribos;
- nepriklausomas dislokavimas;
- laisvė rinktis technologijas.
Daug kalbėjausi su programinės įrangos architektais ir kūrėjais ir klausiau, kam jiems reikalingos mikro paslaugos. Ir aš sudariau savo lūkesčių sąrašą. Štai kas atsitiko:
Jei apibūdinsime kai kuriuos taškus „pojūčiuose“, tada:
- aiškios modulių ribos: pas mus yra baisus monolitas, o dabar viskas bus tvarkingai sutvarkyta Git saugyklose, kuriose viskas „ant lentynų“, nesusimaišo šiltas ir minkštas;
- diegimo nepriklausomumas: galėsime savarankiškai diegti paslaugas, kad plėtra vyktų greičiau (lygiagrečiai skelbti naujas funkcijas);
- kūrimo savarankiškumas: šią mikropaslaugą galime duoti vienai komandai/kūrėjai, o kitą – kitai, kurios dėka galime vystytis greičiau;
- боdidesnis patikimumas: jei įvyksta dalinis gedimas (viena mikropaslauga iš 20 nukrenta), nustos veikti tik vienas mygtukas, o visa sistema veiks toliau.
Tipinė (žalinga) mikro paslaugų architektūra
Norėdami paaiškinti, kodėl tikrovė nėra tokia, kokios tikimės, pateiksiu kolektyvinis mikropaslaugų architektūros vaizdas, pagrįstas daugelio skirtingų projektų patirtimi.
Pavyzdys galėtų būti abstrakti internetinė parduotuvė, kuri konkuruos su Amazon ar bent jau OZON. Jo mikro paslaugų architektūra atrodo taip:
Dėl kelių priežasčių šios mikropaslaugos parašytos skirtingose platformose:
Kadangi kiekviena mikro paslauga turi turėti savarankiškumą, daugeliui jų reikia savo duomenų bazės ir talpyklos. Galutinė architektūra yra tokia:
Kokios jo pasekmės?
Fowleris taip pat turi tai — apie „mokėjimą“ už naudojimąsi mikropaslaugomis:
Ir pamatysime, ar mūsų lūkesčiai pasiteisino.
Aiškios modulių ribos...
bet kiek mikropaslaugų iš tikrųjų turime taisyti?įgyvendinti pakeitimą? Ar galime net suprasti, kaip viskas veikia be paskirstyto traserio (juk bet kokią užklausą apdoroja pusė mikroservisų)?
Yra modelis"“, o čia pasirodė paskirstytas purvo gumulas. Norėdami tai patvirtinti, pateikiame apytikslę užklausų pateikimo iliustraciją:
Diegimo nepriklausomumas...
Techniškai tai pasiekta: kiekvieną mikropaslaugą galime įdiegti atskirai. Tačiau praktiškai reikia atsižvelgti į tai, kad jis visada išsiskleidžia daug mikro paslaugų, ir mes turime į tai atsižvelgti jų išleidimo tvarka. Gerąja prasme, mes paprastai turime atskiroje grandinėje patikrinti, ar išleidžiame leidimą tinkama tvarka.
Laisvė rinktis technologijas...
Ji yra. Tiesiog nepamirškite, kad laisvė dažnai ribojasi su neteisėtumu. Čia labai svarbu nesirinkti technologijų vien tam, kad su jomis „žaisti“.
Plėtros nepriklausomybė...
Kaip sukurti visos programos (su tiek daug komponentų) bandymo kilpą? Bet jūs vis tiek turite jį atnaujinti. Visa tai veda prie to, kad tikrasis bandymo grandinių skaičius, kurį iš esmės galime turėti, pasirodo minimalus.
O kaip visa tai dislokuoti lokaliai?.. Pasirodo, dažnai kūrėjas savo darbą atlieka savarankiškai, bet „atsitiktinai“, nes yra priverstas laukti, kol grandinė atsilaisvins testavimui.
Atskiras mastelio keitimas...
Taip, bet ji yra ribota naudojamos DBVS srityje. Pateiktame architektūros pavyzdyje Cassandra problemų neturės, bet MySQL ir PostgreSQL turės.
Боdidesnis patikimumas...
Ne tik vienos mikropaslaugos gedimas realybėje dažnai sutrikdo visos sistemos tinkamą veikimą, bet ir iškyla nauja problema: Padaryti kiekvieną mikroservisą atspariu gedimams yra labai sunku. Kadangi mikropaslaugos naudoja skirtingas technologijas (memcache, Redis ir kt.), kiekvienai reikia viską apgalvoti ir įgyvendinti, o tai, žinoma, įmanoma, tačiau reikalauja didžiulių resursų.
Apkrovos išmatavimas...
Tai tikrai gerai.
Mikropaslaugų „lengvumas“...
Turime ne tik didžiulius tinklo pridėtinės išlaidos (DNS užklausų daugėja ir pan.), bet ir dėl daugybės pradėtų papildomų užklausų replikuoti duomenis (parduotuvės talpyklos), todėl buvo sukurta daug saugyklos vietos.
Ir štai mūsų lūkesčių pateisinimo rezultatas:
Bet tai dar ne viskas!
Nes:
- Labiausiai tikėtina, kad mums reikės pranešimų magistralės.
- Kaip reikiamu momentu sukurti nuoseklią atsarginę kopiją? Vienintelė tikras galimybė yra išjungti eismą. Bet kaip tai padaryti gamyboje?
- Jei kalbame apie kelių regionų paramą, tai kiekviename iš jų tvarumo organizavimas yra labai daug darbo reikalaujanti užduotis.
- Iškyla centralizuotų pakeitimų problema. Pavyzdžiui, jei mums reikia atnaujinti PHP versiją, turėsime įsipareigoti kiekvienai saugyklai (o jų yra dešimtys).
- Veiklos sudėtingumo augimas yra eksponentinis.
Ką su visu tuo daryti?
Pradėkite nuo monolitinės programos. Fowlerio patirtis kad beveik visos sėkmingos mikro paslaugų programos prasidėjo kaip monolitas, kuris tapo per didelis ir tada buvo sulūžęs. Tuo pačiu metu beveik visos sistemos, nuo pat pradžių sukurtos kaip mikropaslaugos, anksčiau ar vėliau patyrė rimtų problemų.
Dar viena vertinga mintis yra ta, kad norint, kad projektas su mikropaslaugų architektūra būtų sėkmingas, turite labai gerai žinoti ir dalykinė sritis bei kaip sukurti mikropaslaugas. O geriausias būdas išmokti dalykinę sritį – pasidaryti monolitą.
Bet ką daryti, jei jau esame tokioje situacijoje?
Pirmas žingsnis sprendžiant bet kokią problemą – sutikti su ja ir suprasti, kad tai yra problema, kad mes daugiau nenorime kentėti.
Jei apaugusį monolitą (kai pritrūkome galimybės jam įsigyti papildomų resursų) nupjauname, tai šiuo atveju pasirodo priešinga istorija: kai perteklinės mikropaslaugos jau nebe padeda, o trukdo - nupjaukite perteklių ir padidinkite!
Pavyzdžiui, aukščiau aptartam kolektyviniam įvaizdžiui...
Atsikratykite labiausiai abejonių keliančių mikro paslaugų:
Sujunkite visas mikro paslaugas, atsakingas už sąsajos generavimą:
... į vieną mikropaslaugą, parašytą viena (šiuolaikine ir normalia, kaip jūs pats manote) kalba/rėme:
Jis turės vieną ORM (vieną DBVS) ir pirmiausia keletą programų:
... bet apskritai ten galite perkelti daug daugiau ir gauti tokį rezultatą:
Be to, „Kubernetes“ visa tai vykdome atskirais atvejais, o tai reiškia, kad vis tiek galime išmatuoti apkrovą ir jas keisti atskirai.
Apibendrinti
Pažvelkite į didesnį vaizdą. Labai dažnai visos šios mikropaslaugų problemos kyla dėl to, kad kažkas ėmėsi savo užduoties, bet norėjo „pažaisti su mikropaslaugomis“.
Žodyje „mikropaslaugos“ dalis „mikro“ yra perteklinė.. Jie yra „mikro“ tik todėl, kad yra mažesni už didžiulį monolitą. Tačiau negalvokite apie juos kaip apie mažą dalyką.
Ir dėl paskutinės minties grįžkime prie pradinės diagramos:
Ant jo parašyta pastaba (viršutinis dešinysis) susiveda į tai, kad komandos, kuri kuria jūsų projektą, įgūdžiai visada yra pagrindiniai — jie vaidins pagrindinį vaidmenį renkantis tarp mikroservisų ir monolito. Jei komandai neužteks įgūdžių, bet ji pradės daryti mikropaslaugas, istorija tikrai bus lemtinga.
Vaizdo įrašai ir skaidrės
Vaizdo įrašas iš kalbos (~50 min.; deja, neperteikia daugybės lankytojų emocijų, kurios daugiausia nulėmė reportažo nuotaiką, bet taip yra):
Pranešimo pristatymas:
PS
Kiti reportažai mūsų tinklaraštyje:
- «» (Dmitrijus Stoliarovas; 28 m. gegužės 2018 d., RootConf);
- «» (Dmitrijus Stoliarovas; 7 m. lapkričio 2017 d. „HighLoad++“);
- «» (Dmitrijus Stolyarovas; 6 m. birželio 2017 d. RootConf);
- «» (Dmitrijus Stoliarovas; 8 m. lapkričio 2016 d. „HighLoad++“);
- «» (Dmitrijus Stoliarovas; 31 m. gegužės 2016 d., RootConf).
Jus taip pat gali sudominti šie leidiniai:
- «»;
- «»;
- «".
Šaltinis: www.habr.com