La 19-an de septembro en Moskvo la unua tema renkontiĝo HUG (Highload++ User Group), kiu estis dediĉita al mikroservoj. Okazis prezento "Operaciaj Mikroservoj: Grandeco Gravas, Eĉ Se Vi Havas Kubernetes", en kiu ni dividis la vastan sperton de Flant pri funkciigado de projektoj kun mikroserva arkitekturo. Antaŭ ĉio, ĝi estos utila al ĉiuj programistoj, kiuj pensas uzi ĉi tiun aliron en sia nuna aŭ estonta projekto.
Enkondukante (50 minutoj, multe pli informa ol la artikolo), same kiel la ĉefa eltiraĵo el ĝi tekste.
NB: Video kaj prezento ankaŭ haveblas ĉe la fino de ĉi tiu afiŝo.
Enkonduko
Kutime bona rakonto havas komencon, ĉefan intrigon kaj rezolucion. Ĉi tiu raporto estas pli kiel preludo, kaj ankaŭ tragika. Ankaŭ gravas noti, ke ĝi provizas eksteran vidon pri mikroservoj. ekspluatado.
Mi komencos per ĉi tiu grafikaĵo, kies aŭtoro (en 2015) Martin Fowler:
Ĝi montras kiel, en la kazo de monolita apliko kiu atingas certan valoron, produktiveco komencas malkreski. Mikroservoj diferencas pro tio, ke la komenca produktiveco kun ili estas pli malalta, sed ĉar komplekseco pliiĝas, la degenero de efikeco ne estas tiel rimarkinda por ili.
Mi aldonos al ĉi tiu grafikaĵo por la kazo de uzado de Kubernetes:
Kial aplikaĵo kun mikroservoj pli bonas? Ĉar tia arkitekturo prezentas seriozajn postulojn por la arkitekturo, kiuj siavice estas perfekte kovritaj de la kapabloj de Kubernetes. Aliflanke, iuj el ĉi tiuj funkcioj estos utilaj por monolito, precipe ĉar la tipa monolito hodiaŭ ne estas ĝuste monolito (detaloj estos poste en la raporto).
Kiel vi povas vidi, la fina grafikaĵo (kiam ambaŭ monolitaj kaj mikroservaj aplikoj estas en la infrastrukturo kun Kubernetes) ne tre malsamas de la originala. Poste ni parolos pri aplikaĵoj operaciitaj per Kubernetes.
Utilaj kaj malutilaj mikroservoj
Kaj jen la ĉefa ideo:
Kio estas tio normala mikroserva arkitekturo? Ĝi devus alporti al vi realajn avantaĝojn, pliigante vian laborefikecon. Se ni reiras al la grafeo, jen ĝi:
Se vi vokas ŝin utila, tiam ĉe la alia flanko de la grafeo estos malutila mikroservoj (enmiksiĝas kun laboro):
Revenante al la "ĉefa ideo": ĉu mi entute fidi mian sperton? Ekde la komenco de ĉi tiu jaro mi rigardis 85 projektoj. Ne ĉiuj estis mikroservoj (ĉirkaŭ triono ĝis duono de ili havis tian arkitekturon), sed ĉi tio ankoraŭ estas granda nombro. Ni (Flant-kompanio) kiel subkontraktantoj sukcesas vidi ampleksan varion de aplikaĵoj disvolvitaj kaj en malgrandaj kompanioj (kun 5 programistoj) kaj en grandaj (~500 programistoj). Plia avantaĝo estas, ke ni vidas ĉi tiujn aplikojn vivi kaj evolui tra la jaroj.
Kial mikroservoj?
Al la demando pri la avantaĝoj de mikroservoj ekzistas de la jam menciita Martin Fowler:
- klaraj limoj de modulareco;
- sendependa deplojo;
- libereco elekti teknologiojn.
Mi multe parolis kun programaraj arkitektoj kaj programistoj kaj demandis kial ili bezonas mikroservojn. Kaj mi faris mian liston de iliaj atendoj. Jen kio okazis:
Se ni priskribas kelkajn el la punktoj "en sentoj", tiam:
- klaraj limoj de moduloj: ĉi tie ni havas teruran monoliton, kaj nun ĉio estos bonorde aranĝita en Git-deponejoj, en kiuj ĉio estas "sur la bretoj", la varma kaj la mola ne estas miksitaj;
- sendependeco de deplojo: ni povos sendepende disvolvi servojn por ke la disvolviĝo iru pli rapide (publikigi novajn funkciojn paralele);
- disvolva sendependeco: ni povas doni ĉi tiun mikroservon al unu teamo/programisto, kaj tiun al alia, danke al kiu ni povas disvolvi pli rapide;
- боpli granda fidindeco: se parta degradado okazas (unu mikroservo el 20 falas), tiam nur unu butono ĉesos funkcii, kaj la sistemo entute daŭre funkcios.
Tipa (malutila) mikroserva arkitekturo
Por klarigi kial la realo ne estas tio, kion ni atendas, mi prezentos kolektiva bildo de mikroserva arkitekturo bazita sur sperto de multaj malsamaj projektoj.
Ekzemplo estus abstrakta reta vendejo, kiu konkuros kun Amazon aŭ almenaŭ OZON. Ĝia mikroserva arkitekturo aspektas jene:
Pro kombinaĵo de kialoj, ĉi tiuj mikroservoj estas skribitaj sur malsamaj platformoj:
Ĉar ĉiu mikroservo devas havi aŭtonomion, multaj el ili bezonas sian propran datumbazon kaj kaŝmemoron. La fina arkitekturo estas kiel sekvas:
Kio estas ĝiaj konsekvencoj?
Fowler havas ĉi tion ankaŭ — pri la "pago" por uzado de mikroservoj:
Kaj ni vidos ĉu niaj atendoj estis plenumitaj.
Klarigi limojn de moduloj...
sed kiom da mikroservoj ni efektive bezonas ripari?fari la ŝanĝon? Ĉu ni povas eĉ eltrovi kiel ĉio funkcias sen distribuita spurilo (post ĉio, ajna peto estas procesita de duono de la mikroservoj)?
Estas ŝablono"“, kaj ĉi tie ĝi montriĝis esti distribuita malpuraĵo. Por konfirmi tion, jen proksimuma ilustraĵo pri kiel iras la petoj:
Deploja sendependeco...
Teknike, ĝi estis atingita: ni povas efektivigi ĉiun mikroservon aparte. Sed praktike vi devas konsideri, ke ĝi ĉiam ruliĝas multaj mikroservoj, kaj ni devas konsideri la ordo de ilia disvolvo. En bona maniero, ni ĝenerale devas testi en aparta cirkvito ĉu ni ruliĝas la eldonon en la ĝusta ordo.
Libereco elekti teknologion...
Ŝi estas. Nur memoru, ke libereco ofte limas al senleĝeco. Estas tre grave ĉi tie ne elekti teknologiojn nur por "ludi" kun ili.
Sendependeco de evoluo...
Kiel fari provan buklon por la tuta aplikaĵo (kun tiom da komponantoj)? Sed vi ankoraŭ devas teni ĝin ĝisdatigita. Ĉio ĉi kondukas al tio, ke reala nombro da testcirkvitoj, kiun ni principe povas enhavi, montriĝas minimuma.
Kio pri deploji ĉion ĉi loke?... Montriĝas, ke ofte la programisto faras sian laboron sendepende, sed "hazarde", ĉar li estas devigita atendi ĝis la cirkvito estas libera por testado.
Aparta skalo...
Jes, sed ĝi estas limigita en la areo de la uzata DBMS. En la donita arkitekturo ekzemplo, Cassandra ne havos problemojn, sed MySQL kaj PostgreSQL havos.
Боpli granda fidindeco...
Ne nur la fiasko de unu mikroservo fakte ofte rompas la ĝustan funkciadon de la tuta sistemo, sed ankaŭ estas nova problemo: fari ĉiun mikroservon erartolerema estas tre malfacila. Ĉar mikroservoj uzas malsamajn teknologiojn (memcache, Redis, ktp.), por ĉiu vi devas pripensi ĉion kaj efektivigi ĝin, kio, kompreneble, eblas, sed postulas grandegajn rimedojn.
Ŝarĝu mezureblon...
Ĉi tio estas vere bona.
La "facileco" de mikroservoj...
Ni ne nur havas grandegan reto supre (petoj pri DNS multiĝas, ktp.), sed ankaŭ pro la multaj subdemandoj, kiujn ni komencis reprodukti datumojn (vendejaj kaŝmemoroj), kio kondukis al signifa kvanto da stokado.
Kaj jen la rezulto de plenumi niajn atendojn:
Sed tio ne estas ĉio!
Ĉar:
- Plej verŝajne ni bezonos mesaĝan buson.
- Kiel fari konsekvencan sekurkopion en la ĝusta momento? La sola reala opcio estas malŝalti trafikon por ĉi tio. Sed kiel fari tion en produktado?
- Se ni parolas pri subteno de pluraj regionoj, tiam organizi daŭripovon en ĉiu el ili estas tre laborintensa tasko.
- La problemo fari centralizitajn ŝanĝojn ekestas. Ekzemple, se ni bezonas ĝisdatigi la PHP-version, ni devos engaĝiĝi al ĉiu deponejo (kaj estas dekoj da ili).
- La kresko en operacia komplekseco estas, senprokraste, eksponenta.
Kion fari kun ĉio ĉi?
Komencu per monolita apliko. La sperto de Fowler ke preskaŭ ĉiuj sukcesaj mikroservaj aplikoj komenciĝis kiel monolito kiu iĝis tro granda kaj tiam estis rompita. Samtempe preskaŭ ĉiuj sistemoj konstruitaj kiel mikroservoj ekde la komenco frue aŭ malfrue spertis gravajn problemojn.
Alia valora penso estas, ke por ke projekto kun mikroserva arkitekturo sukcesu, vi devas scii tre bone kaj temo, kaj kiel fari mikroservojn. Kaj la plej bona maniero lerni temon estas fari monoliton.
Sed kio se ni jam estas en ĉi tiu situacio?
La unua paŝo por solvi ajnan problemon estas konsenti kun ĝi kaj kompreni, ke ĝi estas problemo, ke ni ne volas plu suferi.
Se, en la kazo de superkreskita monolito (kiam ni elĉerpis la ŝancon aĉeti pliajn rimedojn por ĝi), ni tranĉas ĝin, tiam en ĉi tiu kazo rezultas la kontraŭa rakonto: kiam troaj mikroservoj ne plu helpas, sed malhelpas - detranĉi troon kaj pligrandigi!
Ekzemple, por la kolektiva bildo diskutita supre...
Forigu la plej dubindajn mikroservojn:
Kombinu ĉiujn mikroservojn respondecajn pri fasanta generacio:
... en unu mikroservon, skribitan en unu (moderna kaj normala, kiel vi mem pensas) lingvo/kadro:
Ĝi havos unu ORM (unu DBMS) kaj unue kelkajn aplikojn:
... sed ĝenerale vi povas transdoni multe pli tie, ricevante la sekvan rezulton:
Krome, en Kubernetes ni kuras ĉion ĉi en apartaj okazoj, kio signifas, ke ni ankoraŭ povas mezuri la ŝarĝon kaj grimpi ilin aparte.
Resumi
Rigardu la pli grandan bildon. Tre ofte, ĉiuj ĉi tiuj problemoj kun mikroservoj aperas ĉar iu prenis sian taskon, sed volis "ludi kun mikroservoj".
En la vorto "mikroservoj" la "mikro" parto estas redunda.. Ili estas "mikro" nur ĉar ili estas pli malgrandaj ol grandega monolito. Sed ne pensu pri ili kiel io malgranda.
Kaj por fina penso, ni revenu al la originala diagramo:
Noto skribita sur ĝi (supre dekstre) resumas al tio, ke la kapabloj de la teamo, kiu faras vian projekton, estas ĉiam ĉefaj — ili ludos ŝlosilan rolon en via elekto inter mikroservoj kaj monolito. Se la teamo ne havas sufiĉe da kapabloj, sed ĝi komencas fari mikroservojn, la rakonto certe estos fatala.
Filmetoj kaj diapozitivoj
Vidbendo el la parolado (~50 minutoj; bedaŭrinde, ĝi ne transdonas la multajn emociojn de la vizitantoj, kiuj plejparte determinis la humoron de la raporto, sed jen kiel ĝi estas):
Prezento de la raporto:
PS
Aliaj raportoj en nia blogo:
- «» (Dmitry Stolyarov; la 28-an de majo 2018 ĉe RootConf);
- «» (Dmitry Stolyarov; la 7-an de novembro 2017 ĉe HighLoad++);
- «» (Dmitry Stolyarov; junio 6, 2017 ĉe RootConf);
- «» (Dmitry Stolyarov; la 8-an de novembro 2016 ĉe HighLoad++);
- «» (Dmitry Stolyarov; la 31-an de majo 2016 ĉe RootConf).
Vi ankaŭ povas interesiĝi pri la jenaj publikaĵoj:
- «»;
- «»;
- «".
fonto: www.habr.com