Irailaren 19an Moskun lehenengo topaketa tematikoa HUG (Highload++ User Group), mikrozerbitzuei eskainitakoa. "Mikrozerbitzu operatiboak: tamainak axola, Kubernetes badaukazu ere" aurkezpena izan zen, eta bertan Flantek mikrozerbitzuen arkitekturarekin proiektuak ustiatzen dituen esperientzia zabala partekatu genuen. Lehenik eta behin, baliagarria izango da beren egungo edo etorkizuneko proiektuan ikuspegi hau erabiltzea pentsatzen ari diren garatzaile guztientzat.
Aurkezten (50 minutu, artikulua baino askoz ere informagarriagoa), baita haren laburpen nagusia testu moduan.
OHARRA: Bideoa eta aurkezpena ere eskuragarri daude post honen amaieran.
Sarrera
Normalean istorio on batek hasiera bat, argumentu nagusia eta ebazpena izaten ditu. Txosten hau aurresku bat baino gehiago da, eta tragikoa, gainera. Garrantzitsua da, gainera, mikrozerbitzuei buruz kanpoko baten ikuspegia ematen duela. esplotazioa.
Grafiko honekin hasiko naiz, egilearen (2015ean) Martin Fowler:
Bertan erakusten da nola, balio jakin batera iristen den aplikazio monolitiko baten kasuan, produktibitatea jaisten hasten den. Mikrozerbitzuak desberdinak dira haiekin hasierako produktibitatea txikiagoa baita, baina konplexutasuna handitu ahala, eraginkortasunaren degradazioa ez da hain nabaria haientzat.
Grafiko honi gehituko diot Kubernetes erabiltzearen kasuan:
Zergatik da hobea mikrozerbitzuak dituen aplikazio bat? Horrelako arkitektura batek arkitekturarako eskakizun serioak jartzen dituelako, Kubernetesen gaitasunek ezin hobeto estaltzen baitituzte. Bestalde, funtzionaltasun horietako batzuk monolito baterako erabilgarriak izango dira, batez ere gaur egungo monolito tipikoa ez delako zehazki monolitoa (xehetasunak aurrerago izango dira txostenean).
Ikus dezakezun bezala, azken grafikoa (aplikazio monolitikoak zein mikrozerbitzuak Kubernetes-en azpiegituran daudenean) ez da jatorrizkoaren oso desberdina. Jarraian, Kubernetes erabiliz operatutako aplikazioei buruz hitz egingo dugu.
Mikrozerbitzu erabilgarriak eta kaltegarriak
Eta hona hemen ideia nagusia:
Zer da normala mikrozerbitzuen arkitektura? Benetako onurak ekarri behar dizkizu, zure lanaren eraginkortasuna areagotuz. Grafikora itzultzen bagara, hona hemen:
Deitzen badiozu erabilgarria, gero grafikoaren beste aldean egongo da kaltegarria mikrozerbitzuak (lana oztopatzen du):
βIdeia nagusiraβ itzuliz: nire esperientzian fidatu behar al naiz? Urte honen hasieratik begiratu dut 85 proiektu. Denak ez ziren mikrozerbitzuak (herenak edo erdiak inguruk zeukaten arkitektura hori), baina oraindik ere kopuru handia da. Guk (Flant enpresa) azpikontratatzaile gisa lortzen dugu hainbat aplikazio garatzen ikustea bai enpresa txikietan (5 garatzailerekin) bai handietan (~ 500 garatzaile). Onura gehigarri bat da aplikazio hauek bizi eta eboluzionatzen ikusten ditugula urteetan zehar.
Zergatik mikrozerbitzuak?
Mikrozerbitzuen abantailei buruzko galdera dago Lehen aipatutako Martin Fowler-etik:
- modularitatearen muga argiak;
- hedapen independentea;
- teknologiak aukeratzeko askatasuna.
Asko hitz egin dut software-arkitektu eta garatzaileekin eta galdetu dut zergatik behar dituzten mikrozerbitzuak. Eta haien itxaropenen zerrenda egin nuen. Hona hemen zer gertatu den:
Puntu batzuk "sentsazioetan" deskribatzen baditugu, orduan:
- Moduluen muga argiak: hemen monolito izugarria dugu, eta orain dena txukun antolatuko da Git biltegietan, zeinetan dena "apaletan" dagoen, epela eta biguna nahasten ez diren;
- hedapen independentzia: zerbitzuak modu independentean zabaldu ahal izango ditugu, garapena azkarrago joan dadin (funtzio berriak paraleloan argitaratu);
- garapenaren independentzia: mikrozerbitzu hau talde/garatzaile bati eman diezaiokegu, eta hori beste bati, horri esker azkarrago garatu gaitezke;
- Π±ΠΎfidagarritasun handiagoa: degradazio partziala gertatzen bada (20tik mikrozerbitzu bat erortzen da), orduan botoi bakarrak funtzionatzeari utziko dio eta sistemak bere osotasunean funtzionatzen jarraituko du.
Mikrozerbitzuen arkitektura tipikoa (kaltegarria).
Errealitatea zergatik ez den espero duguna azaltzeko, aurkeztuko dut kolektiboa proiektu ezberdin askotako esperientzian oinarritutako mikrozerbitzu arkitektura baten irudia.
Adibide bat Amazon edo gutxienez OZONekin lehiatuko den lineako denda abstraktu bat izango litzateke. Bere mikrozerbitzuen arkitekturak honela dauka:
Arrazoi batengatik, mikrozerbitzu hauek plataforma ezberdinetan idatzita daude:
Mikrozerbitzu bakoitzak autonomia izan behar duenez, horietako askok beren datu-base eta cachea behar dute. Azken arkitektura hau da:
Zeintzuk dira bere ondorioak?
Fowler-ek ere badu hori β Mikrozerbitzuak erabiltzeko "ordainketa"ri buruz:
Eta ikusiko dugu gure itxaropenak betetzen diren.
Garbitu moduluen mugak...
Baina zenbat mikrozerbitzu konpondu behar ditugu benetan?aldaketa zabaltzeko? Jakin al dezakegu nola funtzionatzen duen guztia banatutako trazatzailerik gabe (azken finean, edozein eskaera prozesatzen du mikrozerbitzuen erdiak)?
Eredu bat dago"β, eta hemen banatutako zikinkeria bat izan zen. Hori baieztatzeko, hona hemen eskaerak nola joaten diren azaltzen duen gutxi gorabehera:
Hedapen independentzia...
Teknikoki, lortu da: mikrozerbitzu bakoitza bereizita zabaldu dezakegu. Baina praktikan kontuan hartu behar duzu beti zabaltzen dela mikrozerbitzu asko, eta kontuan hartu behar dugu beren zabaltze-ordena. Modu onean, oro har, zirkuitu bereizi batean probatu behar dugu oharra ordena egokian zabaltzen ari garen ala ez.
Teknologia aukeratzeko askatasuna...
Bera da. Gogoratu, besterik gabe, askatasunak askotan legegabekeriarekin muga egiten duela. Hemen oso garrantzitsua da teknologiak ez aukeratzea haiekin "jolasteko" soilik.
Garapenaren independentzia...
Nola egin proba-begizta aplikazio osorako (hainbeste osagai dituena)? Baina oraindik eguneratuta mantendu behar duzu. Horrek guztiak izatera eramaten du proba-zirkuituen benetako kopurua, printzipioz eduki dezakeguna, gutxienekoa bihurtzen da.
Zer moduz hori guztia lokalean zabaltzea?... Gertatzen da askotan garatzaileak bere lana modu independentean egiten duela, baina βausazβ, zirkuitua probak egiteko libre egon arte itxaron behar duelako.
Bereizi eskalatzea...
Bai, baina erabilitako DBMS eremuan mugatuta dago. Emandako arkitektura adibidean, Cassandrak ez du arazorik izango, baina MySQL eta PostgreSQL-k bai.
ΠΠΎfidagarritasun handiagoa...
Errealitatean mikrozerbitzu baten hutsegiteak sistema osoaren funtzionamendu zuzena apurtzen du askotan, baina arazo berri bat ere badago: mikrozerbitzu bakoitza akatsekiko tolerantzia egitea oso zaila da. Mikrozerbitzuek teknologia desberdinak erabiltzen dituztenez (memcache, Redis, etab.), bakoitzarentzat dena pentsatu eta inplementatu behar da, eta horrek, noski, posible da, baina baliabide handiak behar ditu.
Karga neurtzeko gaitasuna...
Hau benetan ona da.
Mikrozerbitzuen "arintasuna"...
Ez dugu bakarrik erraldoia sareko gainkostua (DNS eskaerak biderkatzen ari dira, etab.), baina baita hasi genituen azpikontsulta ugariengatik ere datuak errepikatu (biltegiko cacheak), eta horrek biltegiratze kopuru handia ekarri zuen.
Eta hona hemen gure itxaropenak betetzearen emaitza:
Baina hori ez da guztia!
Zeren:
- Seguruenik mezu-bus bat beharko dugu.
- Nola egin segurtasun kopia koherentea une egokian? Bakarra benetakoa horretarako trafikoa itzaltzea da aukera. Baina nola egin hau ekoizpenean?
- Hainbat eskualde laguntzeaz ari bagara, orduan horietako bakoitzean jasangarritasuna antolatzea oso lan intentsiboa da.
- Aldaketa zentralizatuak egiteko arazoa sortzen da. Adibidez, PHP bertsioa eguneratu behar badugu, biltegi bakoitzarekin konprometitu beharko gara (eta dozenaka daude).
- Konplexutasun operatiboaren hazkundea esponentziala da.
Zer egin honekin guztiarekin?
Hasi aplikazio monolitiko batekin. Fowlerren esperientzia ia arrakastatsuak diren mikrozerbitzuen aplikazio guztiak handiegia bihurtu eta gero hautsi zen monolito gisa hasi zirela. Aldi berean, hasiera-hasieratik mikrozerbitzu gisa eraikitako ia sistema guztiek arazo larriak izan zituzten goiz edo beranduago.
Beste pentsamendu baliotsu bat da mikrozerbitzuen arkitektura duen proiektu batek arrakasta izan dezan oso ondo jakin behar duzula eta gai-arloa, eta mikrozerbitzuak nola egin. Eta irakasgai bat ikasteko modurik onena monolito bat egitea da.
Baina zer gertatzen da dagoeneko egoera honetan bagaude?
Edozein arazo konpontzeko lehen urratsa horrekin ados egotea eta arazo bat dela ulertzea da, ez dugula gehiago sufritu nahi.
Hazten den monolito baten kasuan (horretarako baliabide osagarriak erosteko aukera agortzen dugunean), mozten badugu, kasu honetan kontrako istorioa gertatzen da: gehiegizko mikrozerbitzuek laguntzen ez dutenean, baina oztopatzen dute - soberan moztu eta handitu!
Esaterako, goian aipaturiko irudi kolektiborako...
Kendu mikrozerbitzu zalantzagarrienak:
Konbinatu frontend-a sortzeaz arduratzen diren mikrozerbitzu guztiak:
... mikrozerbitzu batean, hizkuntza/esparru batean (modernoa eta normala, zuk uste duzun bezala) idatzita:
ORM bat (DBMS bat) eta lehenengo aplikazio pare bat izango ditu:
... baina, oro har, askoz gehiago transferitu dezakezu bertan, emaitza hau lortuz:
Gainera, Kubernetes-en hau guztia instantzia ezberdinetan exekutatzen dugu, hau da, oraindik karga neurtu eta eskala ditzakegula bereizita.
Laburbilduz
Begiratu argazki handiagoari. Askotan, mikrozerbitzuekin arazo hauek guztiak norbaitek bere zeregina hartu zuelako sortzen dira, baina "mikrozerbitzuekin jolastu" nahi zuelako.
"Mikrozerbitzuak" hitzean "mikro" zatia erredundantea da.. "Mikro" dira monolito erraldoi bat baino txikiagoak direlako bakarrik. Baina ez pentsa gauza txikitzat.
Eta azken hausnarketa bat egiteko, itzul gaitezen jatorrizko taulara:
Bertan idatzitako ohar bat (goian eskuinean) horretara laburtzen da zure proiektua egiten duen taldearen trebetasunak beti dira nagusi β funtsezko papera izango dute mikrozerbitzuen eta monolito baten artean aukeratzerakoan. Taldeak gaitasun nahikorik ez badu, baina mikrozerbitzuak egiten hasten bada, istorioa hilgarria izango da zalantzarik gabe.
Bideoak eta diapositibak
Hitzaldiko bideoa (~ 50 minutu; tamalez, ez ditu bisitarien emozio ugari transmititzen, eta horrek neurri handi batean erreportajearen giroa zehaztu zuen, baina horrela da):
Txostenaren aurkezpena:
PS
Beste erreportaje batzuk gure blogean:
- «» (Dmitry Stolyarov; 28ko maiatzaren 2018an RootConf-en);
- «» (Dmitry Stolyarov; 7ko azaroaren 2017a HighLoad++-n);
- «» (Dmitry Stolyarov; 6ko ekainaren 2017an RootConf-en);
- «» (Dmitry Stolyarov; 8ko azaroaren 2016a HighLoad++-n);
- «» (Dmitry Stolyarov; 31ko maiatzaren 2016an RootConf-en).
Ondorengo argitalpenetan ere interesa izan zaitezke:
- «»;
- «»;
- Β«'.
Iturria: www.habr.com