🥇Mikroteenused: mõõt on oluline, isegi kui teil on Kubernetes

19. september Moskvas toimus esimene temaatiline HUG (Highload++ User Group) koosolek, mis oli pühendatud mikroteenustele. Seal esitleti ettekannet "Mikroteenuste kasutamine: suurus on oluline, isegi kui teil on Kubernetes", kus jagasime laialdast kogemust ettevõttest "Flant" mikroteenuste arhitektuuriga projektide käitamisel. See on eelkõige kasulik kõigile arendajatele, kes mõtlevad, kuidas seda lähenemist oma praegustes või tulevastes projektides rakendada.

Tutvustame ettekande video vaatamiseks (50 minutit, palju informatiivsem kui artikkel), samuti peamine kokkuvõte tekstivormis.

NB: Video ja esitlus on samuti saadaval selle publitseerimise lõpus.

Sissejuhatus

Tavaliselt sisaldab hea lugu sissejuhatust, põhijuttu ja lõpetust. See ettekande meenutab rohkem sissejuhatust, tõsi küll, traagilist. Samuti on oluline märkida, et see esitab mikroteenustele vaatepunkti haavatavuse.

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

Graafikult on näha, et monoliitsete rakenduste puhul, mis jõuavad teatud suuruseni, hakkab tootlikkus langema. Mikroteenused erinevad selle poolest, et nende algne tootlikkus on madalam, kuid keerukuse kasvu korral ei ole nende efektiivsuse langus nii märgatav.

Täiendaksin seda graafikut Kubernetes'e kasutamise juhtumi jaoks:

Miks läks mikroteenuste rakendamisel paremaks? Sest selline arhitektuur seab tõsised nõuded arhitektuurile, mida Kubernetes suudab suurepäraselt täita. Teisalt on osa nende funktsionaalsusest kasulik ka monoliitile, eriti kuna tänapäeva tüüpiline monoliit ei ole sugugi monoliit (detailid tulevad hiljem ettekandes).

Nagu näha, ei erine lõpp-graafik (kui monoliitsete ja mikroteenuste rakendused asuvad Kubernetes'e infrastruktuuris) algsest eriti palju. Järgmisel teemal räägime rakendustest, mida hallatakse Kubernetes'e abil.

Kasulik ja kahjulik mikroteenuselisus

Ja siin on peamine mõte:

Mis on siis normaalne mikroteenuste arhitektuur? See peaks andma teile tõelist kasu, suurendades töö efektiivsust. Kui tagasi pöörduda graafiku juurde, siis siin see on:

Kui nimetada seda kasulik, siis graafiku teises otsas on kahjulik mikroteenuselisus (segab tööd):

Tagasi minnes "peamise mõtte" juurde: kas tasub minu kogemusele üldse usaldada? Selle aasta algusest olen vaadanud 85 projekti. Need ei olnud kõik mikroteenused (sellise arhitektuuriga oli umbes kolmandik kuni pool neist), kuid see on ikkagi suur hulk. Meie (ettevõte "Flant") kui välispartnerid saame näha laia valikut rakendusi, mis on arendatud nii väikestes ettevõtetes (5 arendajat) kui ka suurtes (~500 arendajat). Täiendavaks plussiks on see, et näeme, kuidas need rakendused elavad ja arenevad aastate jooksul.

Miks mikroteenused?

Mikroteenuste kasu küsimusele on jäntud konkreetne vastus juba mainitud Martin Fowlerilt:

selged piirid moodulite osas;
iseseisev juurutamine;
tehnoloogiate valiku vabadus.

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

Kui "tunne« mõningaid punkte kirjeldada, siis:

selged moodulite piirid: meil on kole monoliit ja nüüd on kõik kenasti jagatud Git-repositooriatesse, kus kõik on "riiulitel", mitte segamini soe ja pehme;
iseseisev juurutamine: saame teenuseid iseseisvalt välja anda, et arendus oleks kiirem (samal ajal uusi funktsioone välja pakkuda);
arendamise iseseisvus: saame anda selle mikroteenuse ühele meeskonnale/arendajale, ja teise teisele, tänu millele saame kiiremini arendada;
bosuurem usaldusväärsus: kui tekib osaline langus (üks mikroteenus 20-st langeb), siis lakab tööle vaid üks nupp, samas kui süsteem tervikuna jätkab toimimist.

Tüüpiline (kahjulik) mikroteenuste arhitektuur

Kuid et selgitada, miks reaalsus on teistsugune, kui me ootame, esitan kogum mõistet mikroteenuste arhitektuurist, mis põhineb mitmete erinevate projektide kogemusel.

Käesolevaks näiteks on abstraktne veebipood, mis püüab konkureerida Amazoniga või vähemalt OZON-iga. Selle mikroteenuste arhitektuur näeb välja järgmine:

Mitmete põhjuste tõttu on need mikroteenused kirjutatud erinevatel platvormidel:

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

Millised on selle tagajärjed?

Fowler'l on selle kohta samuti on artikkel — mikroteenuste kasutamise „arve tasumisest“:

Ja vaatame, kas meie ootused on täidetud.

Selged moodulite piirid…

Aga kui palju mikroteenuseid peame tegelikult parandama, et muudatus ellu viia? Kas me saame üldse aru, kuidas kõik töötab, ilma jaotatud jälgimiseta (sest iga päringut töötleb pool mikroteenustest)?

On olemas muster „suur must täkk“, aga siin on see muutunud jaotatud mustaks täkkeks. Selle kinnituseks on allpool ligikaudne joonis, kuidas päringud käivad:

Deployimise sõltumatus…

Tehniliselt on see saavutatud: me saame iga mikroteenuse eraldi uuendada. Kuid praktikas tuleb arvestada, et alati koosneb paljusid mikroteenuseid, lisaks peame arvestama nende käivitamise järjekorraga. Idealjuhul peaksime testima, kas me tõepoolest uuendame väljaande õiges järjekorras.

Tehnoloogia valimise vabadus…

See on olemas. Kuid tuleb meeles pidada, et tihti piirab vabadus ka kaost. On äärmiselt tähtis, et valitaks tehnoloogiaid ainult selleks, et „mängida“ nendega.

Arendamise sõltumatus…

Kuidas luua testimistava kogu rakendusele (niivõrd paljude komponentide seas)? Pealegi tuleb seda pidevalt värskendada. Kõik see viib selleni, et reaalne testimisüsteemide arv, mida me praktiliselt suudame hallata, on minimaalne.

Ja kõik see tuleb kohalikult kokku panna?.. Tulemuseks on see, et sageli teeb arendaja oma tööd iseseisvalt, kuid „pime“ — kuna ta peab ootama, kuni testimiskeskkond vabanevad.

Eraldi skaleerimine…

Jah, kuid see on piiratud kasutatavate DB-de osas. Antud arhitektuuri näites pole Cassandra probleem, kuid MySQL ja PostgreSQL-l on.

Suurem usaldusväärsus…oLisaks sellele, et ühe mikroteenuse rike tihti rikub kogu süsteemi korrektset toimimist, on seal veel uus probleem:

iga mikroteenuse töökorras hoidmine on äärmiselt keeruline . Kuna mikroteenustes kasutatakse erinevaid tehnoloogiaid (memcache, Redis jne), tuleb igaühe puhul kõik hoolikalt läbimõelda ja ellu viia, mis muidugi on võimalik, kuid nõuab tohutult ressursse.Koormuse mõõdetavus…

Selle osas on kõik tõeliselt hästi.

Mikroteenuste „kergus“…

Meil ei ole mitte ainult tekkinud tohutuid

võrgukulusid (DNS-i päringud jne kasvu tõestuseks), vaid ka mitme alam-päringu tõttu hakkasime andmeid replikatsiooni (salvestama vahepealseid andmeid), mis viis olulise andmemahu tekkeni. Kuidas see vastab meie ootustele:

Kuid see pole veel kõik!

Aga see pole veel kõik!

Sest:

Tõenäoliselt on meil vajalik sõnumivälja.
Kuidas teha ajakohast koopia kindlal hetkel? Üksnes reaalne lahendus on liikluse peatamine. Kuid kuidas seda tootmisfaasis teha?
Kui on tegemist mitme piirkonna toetamisega, siis on igas piirkonnas stabiilsuse seadmine väga töölise ülesanne.
Ilmneb probleeme kesksete muudatuste tegemisel. Näiteks, kui meil on vaja PHP versiooni uuendada, siis on vajalik teha commit igas repositooriumis (mille arv on hulgaliselt).
Operatiivsete keerukuste suurenemine tundub olevat eksponentsiaalne.

Mida sellega teha?

Alustage monoliitsetest rakendustest. Fowler’i kogemus ütleb on, et peaaegu kõik edukad mikroteenuste rakendused alustasid monoliidist, mis muutus liiga suureks, ning jagunes seejärel. Samuti on peaaegu kõik süsteemid, mis ehitati mikroteenuste baasil alates esmakordselt, varem või hiljem sattunud tõsiste probleemide küüsi.

Veel üks väärtuslik mõte on see, et mikroteenuste arhitektuuri projekt peab olema tõeliselt edukas, peavad teil olema väga head teadmised nii valdkonnast kui ka mikroteenuste loomise kohta.Ja parim viis valdkonda tundma õppida on luua monoliit.

Aga mis siis, kui me oleme juba sellises olukorras?

Iga probleemi lahendamise esimene samm on nõustuda, et see probleem on olemas, ja mõista, et see on probleem, et me enam ei soovi kannatada.

Kui lõpuks on tegu suurenenud monoliidiga (kui meil on lõppenud võimalus selle ressursse juurde osta), lõikame selle lõhki, siis osutub, et meeleolu mikroteenustest ei aita, vaid takistab — lõigake liialdused ja suurendage!

Ja näiteks praeguses kompleksis…

Vabanege kõige kahtlasematest mikroteenustest:

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

… ühte mikroteenusesse, mis on kirjutatud ühes (kaasaegses ja normaalses, nagu teie enda seisukoht) keeles/raamistikus:

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

… aga sinna saab tegelikult üle kanda palju rohkem, saavutades sellise tulemuse:

Ja Kuberneteses käivitame me kõik need eraldi instantsid, mis tähendab, et me saame ikkagi mõõta koormust ja täiesti eraldi neid skaleerida.

Kokkuvõtteks

Vaata pilti laiemalt. Sageli tekivad kõik need probleemid mikroteenustega seoses sellega, et keegi võttis oma ülesande, kuid soovis "mikroteenustega mängida".

Sõnas "mikroteenused" on osa "mikro" ülearune.Need on "mikro" ainult seetõttu, et nad on väiksemad kui suured monoliidid. Kuid ärge mõelge nendele kui millelegi väikesele.

Ja viimase mõtte jaoks naaseme algse graafiku juurde:

Kirjutatud väitekiri (paremal ülal) kurtis, et teie projekti teostava meeskonna oskused on alati esmatähtsad — just nemad mängivad teie valikus mikroteenuste ja monoliidi vahel võtmerolli. Kui meeskonnal puuduvad oskused, kuid nad hakkavad tegema mikroteenuseid, on see lugu kindlasti saatuslik.