🥇Mikroteenused: suurus on oluline, isegi kui teil on Kubernetes

19. september Moskvast leidis aset esimene teemaüritus HUG (Highload++ User Group), mis oli pühendatud mikroteenustele. Seal kõlas ettekande pealkirjaga „Mikroteenuste haldamine: suurusel on tähtsus, isegi kui teil on Kubernetes”, kus jagasime ettevõtte „Flant” ulatuslikku kogemust mikroteenustega arendatud projektide haldamisel. Eelkõige on see kasulik kõigile arendajatele, kes mõtlevad selle lähenemise kasutamisele oma käesolevates või tulevastes projektides.

Tutvustame ettekande videot (50 minutit, palju informatiivsem kui artikkel), samuti põhijooned selle kohta kirjalikus vormis.

NB: Video ja esitlus on saadaval ka selle publikatsiooni lõpus.

Sissejuhatus

Tavaliselt on hea lugu, millel on sissejuhatus, põhijutt ja lõpplahendus. See ettekande sarnaneb rohkem sissejuhatusele, ja mis peamine, traagilisele. Oluline on mainida, et selles esitatud vaade mikroteenustele on poolteist lekke.

Alustan sellise graafikuga, mille autor on (2015. aastal) sai Martin Fowler:

Graafikust on näha, et monoliitne rakendus, kui see jõuab teatud suuruseni, hakkab tõhusus kahanema. Mikroteenused eristuvad selle poolest, et nende algne tõhusus on madalam, kuid keerukuse suurenedes ei ole nende efektiivsuse langus nii märgatav.

Täiendame seda graafikut Kubernetes'i kasutamise puhul:

Miks muutus mikroteenustega rakenduse jaoks paremaks? Sest see arhitektuur seab tõsiseid nõudmisi arhitektuurile, mis omakorda katab suurepäraselt Kubernetes'i võimalused. Teiselt poolt, osa sellest funktsionaalsusest on kasulik ka monoliidile, eriti seetõttu, et tüüpiline tänapäeva monoliit ei ole päris monoliit (detailid tulevad edasi ettekandes).

Nagu näha, ei erine lõpp-graafik (kui nii monoliitne kui mikroteenustele rakendused on Kubernetes'i infrastruktuuris) oluliselt algsest. Edasi on juttu rakendustest, mida hallatakse Kubernetes'i abil.

Kasulik ja kahjulik mikroteenuste süsteem

Ja siin on peamine mõte:

Mis siis ikkagi on normaalne mikroteenuste arhitektuur? See peaks tooma teile tõelist kasu, suurendades töö efektiivsust. Kui naasta graafiku juurde, siis siin see on:

Kui nimetada seda kasulikuks, siis graafiku teisel poolel on kahjulik mikroteenuste süsteem (töötamist takistav):

Tulek tagasi peamise mõtte juurde: kas tasub üldse usaldada minu kogemust? Käesoleva aasta algusest olen vaadanud 85 projekti. Mitte kõik need ei olnud mikroteenustel baseeruvad (sellise arhitektuuriga oli umbes kolmandik kuni pooled neist), kuid see on ikkagi suur number. Meie (ettevõte „Flant”) saame väliseid teenusepakkujatena näha laia valikut rakendusi, mida arendavad nii väikesed firmad (5 arendajat) kui ka suured (~500 arendajat). Täiendav pluss on see, et näeme, kuidas need rakendused elavad ja arenevad läbi aastate.

Miks mikroteenused?

Küsimusele mikroteenuste kasulikkuse kohta on väga konkreetne vastus juba mainitud Martin Fowlerilt:

selged modulaarsete piiride määratlemised;
iseseisev juurutamine;
tehnoloogiate vabadus.

Olen palju rääkinud arhitektide ja tarkvaraarendajatega ning küsinud, miks neile mikroteenused vajalikud on. Ja koostasin oma ootuste nimekirja. Siin on, mis välja tuli:

Kui kirjeldada „tunde” kaudu mõningaid punkte, siis:

selged moodulipiirded: meil on hirmus monoliit, aga nüüd on kõik korralikult laiali jagatud Git-repositooriatesse, kus kõik on „riiulitel”, mitte segamini soojaga pehmest;
iseseisev juurutamine: saame teenuseid iseseisvalt välja anda, et arendamine käiks kiiremini (paralleelselt uusi funktsioone avaldades);
arendamise sõltumatud: saame anda selle mikroteenuse ühele meeskonnale/arendajale, ja teise — teisele, mis võimaldab meil kiiremini arendada;
bilotkasuurem usaldusväärsus: kui juhtub osaline halvenemine (kukub üks mikroteenus 20st), siis lakkab töötamast vaid üks nupp, samas süsteem tervikuna jätkab toimimist.

Tüüpiline (kahjulik) mikroteenuste arhitektuur

Kuna selgitada, miks tegelikkuses ei ole kõik nii, nagu me ootame, esitan kogutud pildi mikroteenuste arhitektuurist, mis põhineb kogemustel paljusid erinevaid projekte.

Näiteks võib välja tuua abstraktse veebipoe, mis plaanib konkureerida Amazoniga või vähemalt OZONiga. Tema mikroteenuste arhitektuur näeb välja järgmine:

Kokkuvõtlikult on need mikroteenused kirjutatud erinevatesse platvormidesse:

Kuna igal mikroteenusel peab olema iseseisvus, vajab paljud neist oma andmebaasi ja vahemälu. Lõplik arhitektuur on järgmine:

Millised on selle tagajärjed?

Fowler'il on selle kohta artikkel — «mikroteenuste» kasutamise «hind»:

Ja me vaatame, kas meie ootused on täidetud.

Selged moodulite piirid...

Aga kui palju mikroteenuseid peame tegelikult parandama, et muudatus välja anda? Kas me suudame üldse aru saada, kuidas kõik töötab, ilma jaotamata jälgimiseta (sest iga päringut töötleb pool mikroteenuseid)?

On olemas muster «suur must tükikene», aga siin on see üldse saanud jaotatud tükikeseks. Selle kinnituseks — siin on umbkaudne illustreerimine, kuidas päringud liiguvad:

Juhtimise iseseisus...

Töötatud välja: me saame iga mikroteenuse eraldi välja anda. Kuid praktikas tuleb arvestada, et igal ajal väljastatakse mitmeid mikroteenuseid, ja peame arvestama nende väljaandmise järjekorda.Ideaalis tuleks meil üldse testida eraldi kontuuris, kas me väljastame väljaande õigesti.

Tehnoloogia valimise vabadus...

See on olemas. Kuid tasub meeles pidada, et sageli piirneb vabadus ettearvamatusega. On väga oluline mitte valida tehnoloogiaid lihtsalt selleks, et nendega «mängida».

Arendamise iseseisus...

Kuidas luua testkontuur kogu rakenduse jaoks (nii paljude komponentide hulgast)? Ja selle säilitamine ajakohasena. Kõik see viib selleni, et reaalne testkontuuride arv, mida me üleüldse saame hoida, osutub minimaalseteks..

Aga kuidas kõik see kohapeal käivitada?.. Tundub, et sageli teeb arendaja oma tööd iseseisvalt, kuid «juhuslikult», kuna peab ootama, millal testimiskontuur vabaks saab.

Erinev skaleerimine...

Jah, kuid see on piiratud kasutatavate DBMS-ide valdkonnas. Käsitletud arhitektuuri näites ei ole probleeme Cassandra's, kuid MySQL ja PostgreSQL puhul on need olemas.

Silotkauur usaldusväärsus...

Nagu selgub, rikub ühe mikroteenuse rike sageli kogu süsteemi nõuetekohast toimimist; lisaks on olemas uus probleem: iga mikroteenuse rikkepunktide usaldusväärseks muutmine on väga keeruline. Sest mikroteenustes kasutatakse erinevaid tehnoloogiaid (memcache, Redis jne), igaühe jaoks tuleb kõik hoolikalt läbi mõelda ja rakendada, mis on muidugi võimalik, kuid vajab tohutult ressursse.

Koormuse mõõdetavus…

Sellega on tõesti kõik hästi.

Mikroteenuste „kergeusksus”…

Meil on nüüd mitte ainult suured võrgukoormused (DNS-i ja muude taoliste päringute suurenemine), vaid ka mitmete alam-päringute tõttu oleme hakanud andmeid replikeerima (vahefailide talletamine), mis tõi kaasa märkimisväärse hulga salvestusmahtu.

Ja siin on meie ootuste täitmise tulemus:

Kuid see pole veel kõik!

Sest:

Tõenäoliselt vajame me sõnumite buss.
Kuidas teha ajakohane varukoopia soovitud hetkel? Ainuke reaalne variant on liikluse peatamine. Aga kuidas seda teha tootmises?
Kui räägime mitme piirkonna toetamisest, siis igaühes stabiilsuse tagamine on väga töömahukas ülesanne.
Kesksete muudatuste tegemise probleem kerkib esile. Näiteks, kui peame PHP versiooni uuendama, siis tuleb teha commite igaühesse hoidlasse (neid on kümneid).
Töötamise keerukuse kasv näib esmapilgul eksponentsiaalne.

Mida sellega kõigega teha?

Alustage monoliitse rakendusega. Fowler'i kogemus ütleb kinnitab, et praktiliselt kõik edukad mikroteenuste rakendused algasid monoliidist, mis kasvas liiga suureks ja seejärel jagati. Samal ajal on praktiliselt kõik süsteemid, mis on algusest peale ehitatud mikroteenustena, varem või hiljem tõsiste probleemidega silmitsi seisnud.

Veel üks väärtuslik mõte on see, et mikroteenuste arhitektuuriga projekti edu jaoks peate väga hästi tundma nii teemat kui ka mikroteenuste loomise protsessi.Ja parim viis teema tundmiseks on teha monoliit.

Aga mis teha, kui oleme juba sellesse olukorda sattunud?

Iga probleemi esimene samm on sellega leppida ja mõista, et see on probleem; me ei soovi enam kannatada.

Kui oleme Üleliia kasvanud monoliidi puhul (kui meie võimalused ressursse juurde osta on lõppenud) selle lõhkumiseks, siis sel juhul on vastupidi: kui liigse mikroteenuse hulk ei aita enam, vaid segab — lõigake üleliigne ja suursümme!

Näiteks, arvestades eeltoodud nelja pilti…

Vabanege kahtlastest mikroteenustest:

Kombineerige kõik mikroteenused, mis vastutavad frontendi genereerimise eest:

… ühe mikroteenuse, mis on kirjutatud ühes (kaasaegses ja normaalses, nagu te ise arvate) keeles/frameworkis:

Sel on üks ORM (üks andmebaas) ja alguses paar rakendust:

… aga tegelikult saab sinna viia palju rohkem, saavutades sellise tulemuse:

Kuberneteses käivitame kõik need eraldi eksemplarid, seega saame endiselt mõõta koormust ja skalata neid eraldi.

Kokkuvõtteks

Vaadake suuremalt pilti. Väga sageli tekivad kõik need probleemid mikroteenustega seoses, kui keegi võtis oma ülesande, kuid soovis "mängida mikroteenustega".

Sõnas "mikroteenused" on osa "mikro" liigne. Nad on "mikro" ainult seetõttu, et nad on väiksemad kui tohutu monoliit. Kuid ärge arvake, et nad on midagi väikest.

Ja viimase mõtte jaoks naame esialgse graafiku juurde:

Kirjutatud märkused selle juurde (üleval paremal) kokkuvõttes seisnevad selles, et teie projekti teostava meeskonna oskused on alati esmatähtsad — just nemad mängivad võtmerolli teie valikus mikroteenuste ja monoliidi vahel. Kui meeskonnal puuduvad oskused, kuid nad hakkavad looma mikroteenuseid, on lugu kindlasti saatuslik.