19. septembra v Moskvi prvo tematsko srečanje HUG (Highload++ User Group), ki je bilo posvečeno mikrostoritvam. Sledila je predstavitev »Delovanje mikrostoritev: Velikost je pomembna, tudi če imate Kubernetes«, v kateri smo delili Flantove obsežne izkušnje pri upravljanju projektov z arhitekturo mikrostoritev. V prvi vrsti bo koristen vsem razvijalcem, ki razmišljajo o uporabi tega pristopa v svojem trenutnem ali prihodnjem projektu.
Predstavljamo (50 minut, veliko bolj informativen kot članek), kot tudi glavni izvleček iz njega v besedilni obliki.
Opomba: Video in predstavitev sta na voljo tudi na koncu te objave.
Predstavitev
Običajno ima dobra zgodba začetek, glavni zaplet in razrešitev. To poročilo je bolj kot uvod, in to tragičen. Pomembno je tudi omeniti, da ponuja zunanji pogled na mikrostoritve. izkoriščanje.
Začel bom s tem grafom, katerega avtor (leta 2015) Martin Fowler:
Prikazuje, kako v primeru monolitne aplikacije, ki doseže določeno vrednost, produktivnost začne upadati. Mikrostoritve se razlikujejo po tem, da je začetna produktivnost pri njih nižja, z večanjem kompleksnosti pa poslabšanje učinkovitosti pri njih ni tako opazno.
Temu grafu bom dodal za primer uporabe Kubernetesa:
Zakaj je aplikacija z mikrostoritvami boljša? Ker takšna arhitektura postavlja resne zahteve za arhitekturo, ki pa jih zmogljivosti Kubernetesa odlično pokrivajo. Po drugi strani pa bo nekaj te funkcionalnosti uporabno za monolit, še posebej zato, ker današnji tipičen monolit ni ravno monolit (podrobnosti bodo kasneje v poročilu).
Kot lahko vidite, se končni graf (ko so tako monolitne kot mikrostoritvene aplikacije v infrastrukturi s Kubernetesom) ne razlikuje zelo od prvotnega. Nato bomo govorili o aplikacijah, ki jih upravlja Kubernetes.
Koristne in škodljive mikrostoritve
In tukaj je glavna ideja:
Kaj je normalno mikroservisna arhitektura? To bi vam moralo prinesti resnične koristi, povečati vašo delovno učinkovitost. Če se vrnemo k grafu, je tukaj:
Če jo pokličeš uporabno, potem bo na drugi strani grafa škodljivo mikrostoritve (moti delo):
Če se vrnem k "glavni ideji": naj sploh zaupam svojim izkušnjam? Od začetka tega leta sem pogledal 85 projektov. Niso bile vse mikrostoritve (približno tretjina do polovica jih je imela takšno arhitekturo), a je to vseeno velika številka. Nam (podjetje Flant) kot zunanjim izvajalcem uspemo videti široko paleto aplikacij, razvitih tako v majhnih podjetjih (s 5 razvijalci) kot v velikih (~500 razvijalcev). Dodatna prednost je, da te aplikacije vidimo v živo in se z leti razvijajo.
Zakaj mikrostoritve?
Na vprašanje o prednostih mikrostoritev je od že omenjenega Martina Fowlerja:
- jasne meje modularnosti;
- neodvisna namestitev;
- svoboda izbire tehnologij.
Veliko sem se pogovarjal z arhitekti in razvijalci programske opreme in jih vprašal, zakaj potrebujejo mikrostoritve. In naredil sem seznam njihovih pričakovanj. Evo, kaj se je zgodilo:
Če opišemo nekatere točke "v občutkih", potem:
- jasne meje modulov: tukaj imamo grozen monolit, zdaj pa bo vse lepo urejeno v repozitorijih Git, v katerih je vse »na policah«, toplo in mehko se ne mešata;
- neodvisnost uvajanja: storitve bomo lahko uvajali neodvisno, da bo razvoj potekal hitreje (vzporedno objavljajte nove funkcije);
- razvojna neodvisnost: to mikrostoritev lahko damo eni ekipi/razvijalcu, drugo pa drugi, zahvaljujoč kateri se lahko hitreje razvijamo;
- боvečja zanesljivost: če pride do delne degradacije (pade ena mikrostoritev od 20), bo prenehal delovati samo en gumb, sistem kot celota pa bo deloval še naprej.
Tipična (škodljiva) arhitektura mikrostoritev
Da bi pojasnil, zakaj realnost ni to, kar pričakujemo, bom predstavil kolektivno podoba arhitekture mikrostoritve, ki temelji na izkušnjah iz številnih različnih projektov.
Primer bi bila abstraktna spletna trgovina, ki bo konkurirala Amazonu ali vsaj OZON-u. Njegova mikrostoritvena arhitektura izgleda takole:
Zaradi kombinacije razlogov so te mikrostoritve napisane na različnih platformah:
Ker mora imeti vsaka mikrostoritev avtonomijo, mnoge od njih potrebujejo lastno bazo podatkov in predpomnilnik. Končna arhitektura je naslednja:
Kakšne so njegove posledice?
Tudi Fowler ima to — o “plačilu” za uporabo mikrostoritev:
In videli bomo, ali so bila naša pričakovanja izpolnjena.
Jasne meje modulov...
Vendar koliko mikrostoritev moramo dejansko popraviti?uvesti spremembo? Lahko sploh ugotovimo, kako vse deluje brez porazdeljenega sledilnika (navsezadnje vsako zahtevo obdela polovica mikrostoritev)?
Obstaja vzorec "«, in tukaj se je izkazalo, da gre za porazdeljeno kepo umazanije. Za potrditev tega je tukaj približna ilustracija, kako potekajo zahteve:
Neodvisnost uvajanja ...
Tehnično je bilo doseženo: uvedemo lahko vsako mikrostoritev posebej. Toda v praksi morate upoštevati, da se vedno odvije številne mikrostoritve, in moramo upoštevati vrstni red njihovega uvajanja. Na dober način moramo na splošno preizkusiti v ločenem vezju, ali uvajamo izdajo v pravilnem vrstnem redu.
Svoboda izbire tehnologije...
Ona je. Ne pozabite le, da svoboda pogosto meji na nezakonitost. Pri tem je zelo pomembno, da tehnologij ne izbiramo samo zato, da se z njimi »igramo«.
Razvojna neodvisnost...
Kako narediti testno zanko za celotno aplikacijo (s toliko komponentami)? Vendar ga morate še vedno posodabljati. Vse to vodi k dejstvu, da dejansko število preskusnih vezij, ki jih načeloma lahko vsebujemo, se izkaže za minimalno.
Kaj pa uvajanje vsega tega lokalno?.. Izkazalo se je, da pogosto razvijalec svoje delo opravlja neodvisno, vendar "naključno", ker je prisiljen počakati, da je vezje prosto za testiranje.
Ločeno skaliranje ...
Da, vendar je omejen na področju uporabljenega DBMS. V danem primeru arhitekture Cassandra ne bo imela težav, MySQL in PostgreSQL pa bosta.
Боvečja zanesljivost...
Ne samo, da okvara ene mikrostoritve v resnici pogosto prekine pravilno delovanje celotnega sistema, ampak se pojavi tudi nova težava: narediti vsako mikrostoritev odporno na napake je zelo težko. Ker mikrostoritve uporabljajo različne tehnologije (memcache, Redis itd.), Za vsako morate vse premisliti in implementirati, kar je seveda mogoče, vendar zahteva ogromna sredstva.
Merljivost obremenitve...
To je res dobro.
"Lahkoba" mikrostoritev ...
Ne samo, da imamo ogromno režijske stroške omrežja (zahteve za DNS se množijo itd.), ampak tudi zaradi številnih podpoizvedb, ki smo jih začeli podvajanje podatkov (predpomnilniki shranjevanja), kar je privedlo do znatne količine prostora za shranjevanje.
In tukaj je rezultat izpolnitve naših pričakovanj:
A to še ni vse!
Ker:
- Najverjetneje bomo potrebovali sporočilno vodilo.
- Kako narediti dosledno varnostno kopijo v pravem trenutku? Edini resnično možnost je, da za to izklopite promet. Toda kako to narediti v proizvodnji?
- Če govorimo o podpori več regij, potem je organizacija trajnosti v vsaki od njih zelo delovno intenzivna naloga.
- Pojavi se problem centraliziranih sprememb. Na primer, če moramo posodobiti različico PHP, se bomo morali zavezati vsakemu repozitoriju (in teh je na desetine).
- Rast operativne kompleksnosti je eksponentna.
Kaj storiti z vsem tem?
Začnite z monolitno aplikacijo. Fowlerjeva izkušnja da so se skoraj vse uspešne mikrostoritvene aplikacije začele kot monolit, ki je postal prevelik in se nato zlomil. Obenem so skoraj vsi sistemi, ki so že od samega začetka grajeni kot mikrostoritve, prej ali slej imeli resne težave.
Druga dragocena misel je, da morate za uspeh projekta z mikrostoritveno arhitekturo zelo dobro poznati in predmetno področje ter kako narediti mikrostoritve. In najboljši način za učenje predmetnega področja je izdelava monolita.
Kaj pa, če smo že v tej situaciji?
Prvi korak k rešitvi katere koli težave je, da se z njo strinjamo in razumemo, da je težava, da ne želimo več trpeti.
Če v primeru zaraščenega monolita (ko nam je zmanjkalo možnosti nakupa dodatnih sredstev zanj) ga odrežemo, potem se v tem primeru izkaže obratna zgodba: ko pretirane mikrostoritve ne pomagajo več, ampak ovirajo - odrežite presežek in povečajte!
Na primer, za zgoraj obravnavano kolektivno podobo ...
Znebite se najbolj vprašljivih mikrostoritev:
Združite vse mikrostoritve, odgovorne za generiranje vmesnika:
... v eno mikrostoritev, napisano v enem (modernem in normalnem, kot sami mislite) jeziku/ogrodju:
Imel bo en ORM (en DBMS) in najprej nekaj aplikacij:
... vendar na splošno lahko tja prenesete veliko več in dobite naslednji rezultat:
Še več, v Kubernetesu vse to izvajamo v ločenih instancah, kar pomeni, da lahko še vedno ločeno merimo obremenitve in jih skaliramo.
Povzemanje
Poglejte širšo sliko. Zelo pogosto se vse te težave z mikrostoritvami pojavijo zato, ker je nekdo prevzel njihovo nalogo, a se je želel "igrati z mikrostoritvami".
V besedi "mikrostoritve" je del "mikro" odveč.. So »mikro« samo zato, ker so manjši od ogromnega monolita. Vendar ne mislite nanje kot na nekaj malega.
In za konec se vrnimo k izvirnemu grafikonu:
Opomba, napisana na njem (desno zgoraj) se spušča v dejstvo, da veščine ekipe, ki dela vaš projekt, so vedno primarne — igrali bodo ključno vlogo pri vaši izbiri med mikrostoritvami in monolitom. Če ekipa nima dovolj znanja, pa se loti izdelave mikrostoritev, bo zgodba zagotovo usodna.
Video posnetki in diapozitivi
Video iz govora (~50 minut; žal ne prenaša številnih čustev obiskovalcev, ki so v veliki meri določili razpoloženje poročila, a tako je):
Predstavitev poročila:
PS
Druga poročila na našem blogu:
- «» (Dmitry Stolyarov; 28. maj 2018 na RootConf);
- «» (Dmitry Stolyarov; 7. november 2017 na HighLoad++);
- «» (Dmitry Stolyarov; 6. junij 2017 na RootConf);
- «» (Dmitry Stolyarov; 8. november 2016 na HighLoad++);
- «» (Dmitry Stolyarov; 31. maj 2016 na RootConf).
Morda vas bodo zanimale tudi naslednje publikacije:
- «»;
- «»;
- «".
Vir: www.habr.com