19. september í Moskvu fyrsti þemafundurinn HUG (Highload++ User Group), sem var tileinkaður örþjónustum. Það var kynning „Operating Microservices: Size Matters, Even If You Have Kubernetes,“ þar sem við deildum víðtækri reynslu Flant í rekstri verkefna með örþjónustuarkitektúr. Í fyrsta lagi mun það vera gagnlegt fyrir alla forritara sem eru að hugsa um að nota þessa nálgun í núverandi eða framtíðarverkefni sínu.
Kynning (50 mínútur, mun fróðlegri en greinin), auk aðalútdráttar úr henni í textaformi.
ATH: Myndband og kynning eru einnig fáanleg í lok þessarar færslu.
Inngangur
Venjulega hefur góð saga upphaf, aðalsöguþráð og upplausn. Þessi skýrsla er meira eins og aðdragandi, og hörmulegur fyrir það. Það er líka mikilvægt að hafa í huga að það veitir utanaðkomandi sýn á örþjónustur. hagnýtingu.
Ég byrja á þessu grafi, höfundur þess (árið 2015) Martin Fowler:
Það sýnir hvernig, þegar um er að ræða einhæfa umsókn sem nær ákveðnu gildi, byrjar framleiðni að minnka. Örþjónustur eru ólíkar að því leyti að upphafsframleiðni með þeim er minni, en eftir því sem flækjustig eykst er hnignun í skilvirkni ekki svo áberandi hjá þeim.
Ég mun bæta við þetta graf fyrir tilvikið með því að nota Kubernetes:
Af hverju er forrit með örþjónustu betra? Vegna þess að slík arkitektúr setur fram alvarlegar kröfur til arkitektúrsins, sem aftur falla fullkomlega undir getu Kubernetes. Á hinn bóginn mun eitthvað af þessari virkni vera gagnlegt fyrir monolith, sérstaklega vegna þess að dæmigerður monolith í dag er ekki nákvæmlega monolith (upplýsingar verða síðar í skýrslunni).
Eins og þú sérð er lokagrafið (þegar bæði einlita og örþjónustuforrit eru í innviðum með Kubernetes) ekki mjög frábrugðin því upprunalega. Næst munum við tala um forrit sem eru rekin með Kubernetes.
Gagnlegar og skaðlegar örþjónustur
Og hér er meginhugmyndin:
Hvað er eðlilegt örþjónustuarkitektúr? Það ætti að skila þér raunverulegum ávinningi, auka vinnu skilvirkni. Ef við förum aftur í línuritið er það hér:
Ef þú hringir í hana nothæft, þá verður hinum megin á línuritinu skaðlegt örþjónustur (truflar vinnu):
Að snúa aftur að „aðalhugmyndinni“: ætti ég yfirhöfuð að treysta upplifun minni? Síðan í byrjun þessa árs hef ég skoðað 85 verkefni. Ekki voru þær allar örþjónustur (um þriðjungur til helmingur þeirra var með slíkan arkitektúr) en þetta er samt mikill fjöldi. Við (Flant fyrirtæki) sem útvistaraðilar náum að sjá fjölbreytt úrval af forritum þróað bæði í litlum fyrirtækjum (með 5 þróunaraðilum) og í stórum (~500 þróunaraðilum). Aukinn ávinningur er að við sjáum þessi forrit lifa og þróast í gegnum árin.
Hvers vegna örþjónustur?
Til spurningarinnar um kosti örþjónustunnar er það frá áðurnefndum Martin Fowler:
- skýr mörk mátunar;
- sjálfstæð dreifing;
- frelsi til að velja tækni.
Ég hef talað mikið við hugbúnaðararkitekta og forritara og spurt hvers vegna þeir þurfi smáþjónustu. Og ég gerði lista yfir væntingar þeirra. Hér er það sem gerðist:
Ef við lýsum sumum atriðum „í skynjun,“ þá:
- skýr mörk eininga: hér erum við með hræðilega einlita, og nú verður öllu haganlega raðað í Git geymslum, þar sem allt er „í hillum“, hinu hlýja og mjúka er ekki blandað saman;
- óháð dreifingu: við munum geta útbúið þjónustu sjálfstætt þannig að þróunin gangi hraðar (birta nýja eiginleika samhliða);
- Þróunarsjálfstæði: við getum veitt einu teymi/framleiðanda þessa örþjónustu og það til annars, þökk sé því getum við þróað hraðar;
- боmeiri áreiðanleiki: ef niðurbrot á sér stað að hluta (ein örþjónusta af 20 fellur), þá hættir aðeins einn hnappur að virka og kerfið í heild sinni heldur áfram að virka.
Dæmigerð (skaðleg) örþjónustuarkitektúr
Til að útskýra hvers vegna raunveruleikinn er ekki það sem við búumst við mun ég kynna sameiginlega mynd af örþjónustuarkitektúr sem byggir á reynslu úr mörgum mismunandi verkefnum.
Dæmi væri abstrakt netverslun sem ætlar að keppa við Amazon eða að minnsta kosti OZON. Örþjónustuarkitektúr þess lítur svona út:
Af ýmsum ástæðum eru þessar örþjónustur skrifaðar á mismunandi kerfum:
Þar sem hver örþjónusta verður að hafa sjálfræði þurfa margar þeirra sinn eigin gagnagrunn og skyndiminni. Endanleg arkitektúr er sem hér segir:
Hverjar eru afleiðingar þess?
Fowler á þetta líka — um „greiðsluna“ fyrir notkun örþjónustu:
Og við munum sjá hvort væntingar okkar stóðust.
Hreinsa mörk eininga...
En hversu margar örþjónustur þurfum við í raun að laga?að rúlla út breytingunni? Getum við jafnvel komist að því hvernig allt virkar án dreifðs rekjaefnis (enda eru allar beiðnir unnar af helmingi örþjónustunnar)?
Það er mynstur "“, og hér reyndist þetta vera dreifður moli. Til að staðfesta þetta er hér áætluð mynd af því hvernig beiðnir fara:
Sjálfstæði dreifingar...
Tæknilega hefur það náðst: við getum sett út hverja örþjónustu fyrir sig. En í reynd þarf að taka með í reikninginn að það rúllar alltaf út margar örþjónustur, og við þurfum að taka tillit til röð uppsetningar þeirra. Á góðan hátt þurfum við almennt að prófa í sérstakri hringrás hvort við séum að rúlla út útgáfunni í réttri röð.
Frelsi til að velja tækni...
Hún er. Mundu bara að frelsi jaðrar oft við lögleysu. Það er mjög mikilvægt hér að velja ekki tækni bara til að „leika“ með hana.
Sjálfstæði þróunar...
Hvernig á að búa til prófunarlykkju fyrir allt forritið (með svo mörgum íhlutum)? En þú þarft samt að hafa það uppfært. Allt þetta leiðir til þess að raunverulegur fjöldi prófunarrása, sem við getum í grundvallaratriðum innihaldið, reynist í lágmarki.
Hvernig væri að dreifa þessu öllu á staðnum?.. Það kemur í ljós að oft vinnur verktaki sjálfstætt, en "af handahófi", vegna þess að hann neyðist til að bíða þar til hringrásin er laus til prófunar.
Aðskilin mælikvarði...
Já, en það er takmarkað á sviði DBMS sem notað er. Í tilteknu dæmi um arkitektúr mun Cassandra ekki eiga í vandræðum, en MySQL og PostgreSQL munu gera það.
Боmeiri áreiðanleiki...
Það er ekki aðeins að bilun í einni örþjónustu brýtur oft rétta virkni alls kerfisins, heldur er líka nýtt vandamál: Það er mjög erfitt að gera sérhverja smáþjónustu bilanaþolin. Vegna þess að örþjónustur nota mismunandi tækni (memcache, Redis, osfrv.), fyrir hvern sem þú þarft að hugsa í gegnum allt og innleiða það, sem auðvitað er mögulegt, en krefst mikils fjármagns.
Mælanleiki álags...
Þetta er virkilega gott.
„Léttleiki“ örþjónustu...
Við eigum ekki bara risastórt net yfir höfuð (beiðnir um DNS margfaldast o.s.frv.), en einnig vegna margra undirfyrirspurna sem við byrjuðum á endurtaka gögn (birgðageymslur), sem leiddi til umtalsverðrar geymslu.
Og hér er niðurstaðan af því að uppfylla væntingar okkar:
En það er ekki allt!
Vegna þess að:
- Líklegast þurfum við skilaboðastrætó.
- Hvernig á að gera stöðugt öryggisafrit á réttu augnabliki í tíma? Sá eini alvöru möguleiki er að slökkva á umferð fyrir þetta. En hvernig á að gera þetta í framleiðslu?
- Ef við erum að tala um að styðja við nokkur svæði, þá er það mjög vinnufrekt verkefni að skipuleggja sjálfbærni í hverju þeirra.
- Vandinn við að gera miðstýrðar breytingar kemur upp. Til dæmis, ef við þurfum að uppfæra PHP útgáfuna, þurfum við að skuldbinda okkur til hverrar geymslu (og það eru heilmikið af þeim).
- Vöxturinn í rekstri flókinnar er, óviðjafnanleg, veldisvísis.
Hvað á að gera við þetta allt?
Byrjaðu með einhæfu forriti. Reynsla Fowler að næstum öll vel heppnuð smáþjónustuforrit byrjuðu sem einliða sem varð of stór og brotnaði síðan. Jafnframt voru nær öll kerfi sem byggð voru sem örþjónustur frá upphafi fyrir alvarlegum vandamálum fyrr eða síðar.
Önnur dýrmæt hugsun er sú að til að verkefni með örþjónustuarkitektúr gangi vel verður þú að vita mjög vel og efnissvið, og hvernig á að búa til örþjónustur. Og besta leiðin til að læra fagsvið er að búa til einlita.
En hvað ef við erum nú þegar í þessari stöðu?
Fyrsta skrefið til að leysa hvers kyns vandamál er að vera sammála því og skilja að það er vandamál, að við viljum ekki þjást lengur.
Ef við skerum það, þegar um er að ræða ofvaxinn einlita (þegar við höfum klárað tækifærið til að kaupa viðbótarauðlindir fyrir hann), þá kemur hið gagnstæða í ljós í þessu tilfelli: þegar óhófleg örþjónusta hjálpar ekki lengur, heldur hindrar - skera burt umfram og stækka!
Til dæmis, fyrir sameiginlega myndina sem fjallað er um hér að ofan...
Losaðu þig við vafasamustu örþjónusturnar:
Sameina allar örþjónustur sem bera ábyrgð á framendaframleiðslu:
... í eina örþjónustu, skrifuð á einu (nútímalegu og eðlilegu, eins og þú heldur sjálfur) tungumál/ramma:
Það mun hafa eitt ORM (eitt DBMS) og fyrst nokkur forrit:
... en almennt er hægt að flytja miklu meira þangað og fá eftirfarandi niðurstöðu:
Þar að auki, í Kubernetes keyrum við þetta allt í aðskildum tilfellum, sem þýðir að við getum samt mælt álagið og skalað það sérstaklega.
Til að draga saman
Horfðu á stærri myndina. Mjög oft koma öll þessi vandamál með örþjónustur upp vegna þess að einhver tók verkefni þeirra, en vildi „leika sér með örþjónustu“.
Í orðinu „microservices“ er „micro“ hlutinn óþarfur.. Þeir eru „ör“ aðeins vegna þess að þeir eru minni en risastór einlitur. En ekki hugsa um þá sem eitthvað lítið.
Og fyrir lokahugsun skulum við fara aftur í upprunalegu töfluna:
Minnisblað skrifað á það (efst til hægri) styttist í að færni teymisins sem gerir verkefnið þitt er alltaf aðal — þeir munu gegna lykilhlutverki í vali þínu á milli örþjónustu og einliða. Ef liðið hefur ekki næga færni, en það byrjar að búa til örþjónustur, mun sagan örugglega verða banvæn.
Myndbönd og glærur
Myndband úr ræðunni (~50 mínútur; því miður kemur það ekki til með að miðla hinum fjölmörgu tilfinningum gesta, sem réðu mestu um stemningu skýrslunnar, en svona er þetta):
Kynning á skýrslunni:
PS
Aðrar skýrslur á blogginu okkar:
- «» (Dmitry Stolyarov; 28. maí 2018 á RootConf);
- «» (Dmitry Stolyarov; 7. nóvember 2017 á HighLoad++);
- «» (Dmitry Stolyarov; 6. júní 2017 á RootConf);
- «» (Dmitry Stolyarov; 8. nóvember 2016 á HighLoad++);
- «» (Dmitry Stolyarov; 31. maí 2016 á RootConf).
Þú gætir líka haft áhuga á eftirfarandi ritum:
- «»;
- «»;
- «'.
Heimild: www.habr.com