19 Îlonê li Moskowê yekem civîna tematîk HUG (Highload ++ Koma Bikarhêner), ku ji mîkroservisan re hate veqetandin. Pêşandanek "Karkirina Microservices: Mezinahî Girîng e, Tewra Ku Kubernetes Hebin jî" hebû, ku tê de me ezmûna berfereh ya Flant di xebata projeyên bi mîmariya mîkroxizmetê de parve kir. Berî her tiştî, ew ê ji hemî pêşdebirên ku li ser karanîna vê nêzîkbûnê di projeya xwe ya heyî an pêşerojê de difikirin re kêrhatî be.
Nasandin (50 hûrdem, ji gotarê pir agahdartir), û her weha jêhatiya sereke ji wê di forma nivîsê de.
NB: Vîdyo û pêşkêşî jî di dawiya vê postê de hene.
Pîrozbahiyê
Bi gelemperî çîrokek baş xwedî destpêkek, planek bingehîn û çareseriyek e. Ev rapor bêtir dişibihe pêşgotinekê û bi wê re jî trajîk e. Di heman demê de girîng e ku were zanîn ku ew nêrînek ji derveyî mîkroservisan peyda dike. kedmêjî.
Ez ê bi vê grafîkê dest pê bikim, ku nivîskarê wê (di sala 2015 de) Martin Fowler:
Ew nîşan dide ku di rewşa serîlêdana yekparêz a ku digihîje nirxek diyarkirî de, hilberî çawa dest pê dike. Mîkroxizmet ji ber ku hilberîna destpêkê ya bi wan re kêm e cûda ne, lê her ku tevlihevî zêde dibe, hilweşîna karîgeriyê ji bo wan ew qas ne diyar e.
Ez ê ji bo doza karanîna Kubernetes li vê grafîkê zêde bikim:
Çima serîlêdanek bi microservices çêtir e? Ji ber ku mîmariyek wusa ji bo mîmariyê hewcedariyên ciddî derdixe pêş, ku di encamê de ji hêla kapasîteyên Kubernetes ve bêkêmasî têne vegirtin. Ji hêla din ve, hin ji vê fonksiyonê dê ji bo monolîtek bikêr be, nemaze ji ber ku monolîta tîpîk îro ne tam monolîtek e (hûragahiyan dê paşê di raporê de bin).
Wekî ku hûn dikarin bibînin, grafiya paşîn (gava ku hem serîlêdanên monolîtîk û hem jî mîkroxizmet di binesaziya Kubernetes de ne) ji ya orîjînal ne pir cûda ye. Piştre em ê li ser sepanên ku bi Kubernetes têne xebitandin biaxivin.
Mîkroxizmetên kêrhatî û zirardar
Û li vir fikra sereke ye:
Ew çi ye normal mîmariya microservice? Divê ew feydeyên rastîn ji we re bîne, karbidestiya xebata we zêde bike. Ger em vegerin ser grafîkê, li vir ev e:
Ger hûn jê re dibêjin bikartê, paşê li aliyê din ê grafîkê dê hebe zirarane microservices (destwerdana xebatê):
Vegera "ramana sereke": Ma ez bi tevahî ji ezmûna xwe bawer bikim? Ji destpêka vê salê ve ez lê geriyam 85 proje. Ne hemî wan mîkroxizmet bûn (nêzîkî sêyek û nîvê wan mîmariyek wusa bûn), lê ev hîn jî hejmareke mezin e. Em (şîrketa Flant) wekî dervî çavkaniyê bi rê ve dibin ku em cûrbecûr sepanên ku hem di pargîdaniyên piçûk de (bi 5 pêşdebiran re) hem jî di yên mezin de (~ 500 pêşdebiran) hatine pêşve xistin bibînin. Feydeyek zêde ev e ku em van sepanan bi salan zindî dibînin û pêşve diçin.
Çima microservices?
Pirsa li ser feydeyên mîkroservisan heye ji Martin Fowler ku berê hatî behs kirin:
- sînorên zelal ên modularîteyê;
- belavkirina serbixwe;
- azadiya hilbijartina teknolojiyê.
Min gelek bi mîmar û pêşdebirên nermalavê re peyivî û pirsî ka çima ew hewceyê mîkroxizmetan in. Û min lîsteya xwe ya hêviyên wan çêkir. Li vir çi qewimî:
Ger em hin xalên "di hestan" de diyar bikin, wê hingê:
- tixûbên zelal ên modulan: li vir me monolîtek tirsnak heye, û naha dê her tişt bi rêkûpêk di depoyên Git de were saz kirin, ku tê de her tişt "li ser refikan" e, germ û nerm tevlihev nabin;
- serxwebûna bicihkirinê: em ê karibin karûbaran serbixwe bimeşînin da ku pêşkeftin zûtir biçe (teybetmendiyên nû bi hev re biweşînin);
- serxwebûna pêşkeftinê: em dikarin vê mîkroxizmetê bidin tîmek / pêşdebiran, û yê yekê jî bidin yekî din, bi saya wê em dikarin zûtir pêşde bibin;
- боpêbaweriya mezintir: heke hilweşînek qismî çêbibe (ji 20 mîkroxizmetek têkeve), wê hingê tenê yek bişkok dê bixebite, û pergal bi tevahî dê xebata xwe bidomîne.
Mîmariya mîkroxizmetê ya tîpîk (zerardar).
Ji bo ravekirina ka çima rastî ne ya ku em li bendê ne ye, ez ê pêşkêş bikim kolektîf wêneyek mîmariya mîkroxizmetê ya li ser bingeha ezmûna ji gelek projeyên cihêreng.
Mînakek dê dikanek serhêl a abstrakt be ku dê bi Amazon an bi kêmanî OZON re pêşbaziyê bike. Mîmariya mîkroxizmeta wê wiha xuya dike:
Ji ber sedemên tevlihev, ev mîkroxizmet li ser platformên cûda têne nivîsandin:
Ji ber ku her mîkroxizmet divê xweseriyek hebe, gelek ji wan hewceyê databas û cache-ya xwe ne. Mîmariya dawîn wiha ye:
Encamên wê çi ne?
Fowler jî ev heye - di derbarê "drav" de ji bo karanîna mîkroservisan:
Û em ê bibînin ka hêviyên me pêk hatin.
Sînorên modulan zelal bikin...
di heman demê de em bi rastî çend mîkroxizmet hewce dikin ku rast bikin?ji bo guherandina roll? Ma em dikarin tewra fêhm bikin ka her tişt bêyî şopek belavkirî çawa dixebite (piştî her daxwazek ji hêla nîvê karûbaran ve tê pêvajo kirin)?
Nimûneyek heye"", û li vir derket holê ku ew gûzek qirêj a belavkirî ye. Ji bo piştrastkirina vê yekê, li vir nîgarek texmînî ye ku ka daxwaz çawa diçin:
Serxwebûna belavkirinê...
Ji hêla teknîkî ve, ew bi dest ket: em dikarin her mîkroxizmetê ji hev cuda derxînin. Lê di pratîkê de hûn hewce ne ku hesab bidin ku ew her gav derdikeve gelek microservices, û divê em hesab bikin rêza derxistina wan. Bi awayek baş, em bi gelemperî hewce ne ku di çerxek veqetandî de ceribandinê bikin ka gelo em berdanê bi rêza rast derdixin.
Azadiya hilbijartina teknolojiyê...
Ev heye. Tenê ji bîr mekin ku azadî pir caran bi bêhiqûqiyê re sînordar e. Li vir pir girîng e ku meriv teknolojiyên tenê bi wan re "lîstin" hilbijêrin.
Serxwebûna geşepêdanê...
Meriv çawa ji bo tevaya serîlêdanê (bi ewqas hêmanan) ceribandinek çêdike? Lê dîsa jî hûn hewce ne ku wê nûve bikin. Ev hemû dibe sedema wê yekê ku hejmara rastîn ya çerxên testê, ku em dikarin di prensîbê de bin, kêm dibe.
Û van hemûyan li herêmî bicîh bikin?.. Derdikeve holê ku pirê caran pêşdebir karê xwe serbixwe dike, lê "bi rasthatinî", ji ber ku ew neçar e ku li bendê bimîne heya ku çerx ji bo ceribandinê azad bibe.
Pîvana veqetandî...
Erê, lê ew di qada DBMS-ya ku tê bikar anîn de sînorkirî ye. Di mînaka mîmariya diyarkirî de, Cassandra dê pirsgirêk nebe, lê MySQL û PostgreSQL dê bibin.
Боpêbaweriya mezintir ...
Ne tenê têkçûna yek mîkroxizmetê di rastiyê de pir caran xebata rast a tevahiya pergalê dişkîne, lê di heman demê de pirsgirêkek nû jî heye: çêkirina her mîkroxizmetek xelet-tolerant pir dijwar e. Ji ber ku mîkroxizmet teknolojiyên cihêreng bikar tînin (memcache, Redis, hwd.), Ji bo her yekê hûn hewce ne ku li ser her tiştî bifikirin û wê bicîh bikin, ku, bê guman, gengaz e, lê çavkaniyên mezin hewce dike.
Pîvana barkirinê...
Ev bi rastî baş e.
"Sinahî" ya mîkroxizmetên ...
Em ne tenê mezin in serê torê (daxwazên ji bo DNS zêde dibin, hwd.), di heman demê de ji ber gelek lêpirsînên ku me dest pê kir daneyan dubare bikin (veşartgehên dikanê), ku rê li ber hejmareke girîng a hilanînê girt.
Û li vir encama pêkanîna hêviyên me ye:
Lê ev ne hemû ye!
Bo:
- Bi îhtîmaleke mezin em ê hewceyê otobusek peyamê bin.
- Meriv çawa di wextê rast de piştgiriyek domdar çêbike? Yekane rast vebijark ev e ku meriv trafîkê ji bo vê yekê qut bike. Lê meriv vê yekê di hilberînê de çawa dike?
- Heger em behsa piştgirîkirina çend herêman dikin, wê demê organîzekirina domdariyê li her yek ji wan karekî pir bi ked e.
- Pirsgirêka çêkirina guhertinên navendî derdikeve holê. Mînakî, ger hewce bike ku em guhertoya PHP-ê nûve bikin, em ê hewce bikin ku ji her depoyekê re pabend bin (û bi dehan ji wan hene).
- Mezinbûna di tevliheviya xebitandinê de, nebaş, berbiçav e.
Bi van hemûyan re çi bikin?
Bi serîlêdana monolîtîk dest pê bikin. Tecrubeya Fowler ku hema hema hemî serîlêdanên mîkroservisê yên serketî wekî monolîtek ku pir mezin bû dest pê kir û piştre hate şikandin. Di heman demê de, hema hema hemî pergalên ku ji destpêkê ve wekî mîkroxizmet hatine çêkirin zû an dereng pirsgirêkên cidî dîtin.
Ramanek din a hêja ev e ku ji bo ku projeyek bi mîmariya mîkroxizmetê serketî be, divê hûn pir baş zanibin û qada mijarê, û meriv çawa mîkroservisan çêdike. Û awayê çêtirîn ku meriv qada mijarek fêr bibe çêkirina monolîtek e.
Lê eger em berê di vê rewşê de ne?
Ji bo çareserkirina her pirsgirêkê gava yekem ew e ku em pê razî bibin û fêm bikin ku ew pirsgirêk e, ku em êdî naxwazin êşê bikişîne.
Ger, di bûyera yekdestdariyek zêde de (gava ku me ji fersendê ku em jê re çavkaniyên zêde bikirin qediya), em wê qut bikin, wê hingê di vê rewşê de çîrokek berevajî derdikeve: gava ku mîkroxizmetên zêde êdî ne arîkar in, lê dibin asteng - zêde jêkirin û mezin kirin!
Mînakî, ji bo wêneya kolektîf ku li jor hatî nîqaş kirin ...
Ji mîkroxizmetên herî gumanbar xilas bibin:
Hemî mîkroxizmetên ku ji bo hilberîna pêşîn berpirsiyar in tevbigerin:
... di yek mîkroxizmetê de, ku bi zimanek / çarçoveyek yek (modern û normal, wekî hûn bixwe difikirin) hatî nivîsandin:
Ew ê yek ORM (yek DBMS) û pêşî çend serîlêdan hebe:
... lê bi gelemperî hûn dikarin pir zêde li wir veguhezînin, encama jêrîn bistînin:
Wekî din, di Kubernetes de em van hemî di mînakên cihêreng de dimeşînin, ku tê vê wateyê ku em hîn jî dikarin barkirinê bipîvin û wan ji hev cuda bipîvin.
Bi kurtahî
Li wêneyê mezintir binêrin. Pir caran, hemî van pirsgirêkan bi mîkroxizmetan re derdikevin ji ber ku kesek peywira xwe girt, lê dixwest "bi mîkroservîsan re bilîze".
Di peyva "microservices" de beşa "micro" zêde ye.. Ew "mîkro" ne tenê ji ber ku ew ji monolîtek mezin piçûktir in. Lê wan wekî tiştek piçûk nebînin.
Û ji bo ramanek paşîn, em vegerin nexşeya bingehîn:
Têbînîyek li ser hatiye nivîsandin (rastê jorîn) bi vê rastiyê ve girêdayî ye jêhatîbûna tîmê ku projeya we çêdike her gav bingehîn in - ew ê di hilbijartina we de di navbera mîkroxizmet û monolîtek de rolek sereke bilîzin. Ger tîmê têra xwe jêhatî nebe, lê ew dest bi çêkirina mîkroservisan bike, dê çîrok bê guman kujer be.
Vîdyo û slaytên
Vîdyoya ji axaftinê (~ 50 hûrdem; mixabin, ew gelek hestên mêvanan, ku bi giranî rewşa raporê diyar dike, vedibêje, lê bi vî rengî ye):
Pêşkêşkirina raporê:
PS
Raporên din ên li ser bloga me:
- «» (Dmitry Stolyarov; 28 Gulan 2018 li RootConf);
- «» (Dmitry Stolyarov; 7 Mijdar 2017 li ser HighLoad ++);
- «» (Dmitry Stolyarov; 6 Hezîran, 2017 li RootConf);
- «» (Dmitry Stolyarov; 8 Mijdar 2016 li ser HighLoad ++);
- «» (Dmitry Stolyarov; 31 Gulan 2016 li RootConf).
Hûn dikarin bi weşanên jêrîn re jî eleqedar bibin:
- «»;
- «»;
- «".
Source: www.habr.com