Slav! Navê min Vadim Madison e, ez pêşengiya pêşveçûna Platforma Pergala Avito dikim. Ji carekê zêdetir hate gotin ku em di pargîdaniyê de çawa ji mîmariya yekparêz berbi mîkroxizmetek ve diçin. Wext e ku em parve bikin ka me çawa binesaziya xwe veguherandiye da ku herî zêde ji mîkroxizmetan sûd werbigirin û pêşî li windabûna xwe bigirin. Çawa PaaS li vir ji me re dibe alîkar, me çawa sazkirinê hêsan kir û çêkirina mîkroxizmetek bi yek klîk kêm kir - bixwînin. Ne her tiştê ku ez li jêr dinivîsim bi tevahî di Avito de tête bicîh kirin, hin ji wan ew e ku em çawa platforma xwe pêşve dibin.
(Û di dawiya vê gotarê de, ez ê li ser derfeta beşdarbûna semînerek sê-rojî ji pisporê mîmariya mîmarî Chris Richardson biaxivim).
Em çawa hatin mîkroservisan
Avito yek ji mezintirîn malperên nepenî yên cîhanê ye ku rojane zêdetirî 15 mîlyon reklamên nû li ser têne weşandin. Piştgiriya me di çirkeyê de zêdetirî 20 hezar daxwazan qebûl dike. Niha çend sed mîkroxizmetên me hene.
Ev çend sal in ku em mîmariya mîkroxizmetê ava dikin. Çawa tam - hevkarên me bi hûrgulî li beşa me ya li RIT ++ 2017. Li CodeFest 2017 (binêre. ), Sergey Orlov û Mikhail Prokopchuk bi hûrgulî rave kirin ka çima hewcedariya me bi veguheztina mîkroservisan heye û Kubernetes li vir çi rola lîst. Welê, naha em her tiştî dikin da ku lêçûnên pîvandinê yên ku di mîmariyek wusa de ne kêm bikin.
Di destpêkê de, me ekosîstemek ku bi berfirehî alîkariya me bike pêşkeftin û destpêkirina mîkroxizmetan neafirand. Wan tenê çareseriyên çavkaniya vekirî ya maqûl berhev kirin, wan li malê dan destpêkirin û pêşdebir vexwendin ku bi wan re mijûl bibe. Di encamê de, ew çû bi dehan cihan (dashboard, karûbarên navxweyî), piştî ku ew di xwesteka xwe ya qutkirina kodê bi awayê kevin, bi yekdestî, bihêztir bû. Rengê kesk di xêzên jêrîn de destnîşan dike ka pêşdebir çi bi rengekî an yekî din bi destên xwe dike, û rengê zer jî otomatîkbûnê destnîşan dike.
Naha di navgîniya PaaS CLI de, karûbarek nû bi yek fermanê ve tê afirandin, û databasek nû bi du kesên din re tê zêdekirin û li Stage-yê tê şandin.
Meriv çawa serdema "parçebûna mîkroxizmetê" derbas dike
Bi mîmariya monolîtîk, ji bo berdewamiya guhertinên di hilberê de, pêşdebir neçar bûn ku fêhm bikin ka çi bi cîranên wan re diqewime. Dema ku li ser mîmariya nû dixebitin, şertên karûbarê êdî bi hevûdu ve girêdayî ne.
Digel vê yekê, ji bo ku mîmariya mîkroxizmetek bi bandor be, pêdivî ye ku gelek pêvajo bêne damezrandin, nemaze:
• têketin;
• şopandina daxwazê (Jaeger);
• kombûna çewtiyê (Sentry);
• statû, peyam, bûyerên Kubernetes (Pêvajoya Streamê ya Bûyerê);
• Sînorê nijadê / şkesta çerxê (hûn dikarin Hystrix bikar bînin);
• kontrolkirina girêdana karûbarê (em Netramesh bikar tînin);
• çavdêrîkirin (Grafana);
• civîn (TeamCity);
• ragihandin û ragihandin (Slack, email);
• şopandina peywirê; (Jira)
• amadekirina belgeyan.
Ji bo ku pê ewle bibin ku pergal yekrêziya xwe winda neke û her ku mezin dibe bi bandor bimîne, me rêxistina mîkroxizmetên li Avito ji nû ve fikir kir.
Em çawa mîkroservisan îdare dikin
Alîkariya jêrîn ji bo pêkanîna "siyaseta partiyê" ya yekbûyî di nav gelek mîkroservisên Avito de:
- dabeşkirina binesaziyê li qatan;
- Konsepta Platforma Wek Xizmet (PaaS);
- çavdêriya her tiştê ku bi mîkroservisan diqewime.
Qatên razberkirina binesaziyê sê qatan dihewîne. Em ji serî heta binî herin.
A. Top - mesh xizmeta. Di destpêkê de me Istio ceriband, lê derket holê ku ew pir çavkaniyan bikar tîne, ku ji bo cildên me pir biha ye. Ji ber vê yekê, endezyarê payebilind di tîmê mîmariyê de Alexander Lukyanchenko çareseriya xwe pêşxist - (di Çavkaniya Vekirî de heye), ya ku em niha di hilberînê de bikar tînin û ji Istio çend caran kêmtir çavkaniyan dixwe (lê her tiştê ku Istio dikare pesnê xwe bide, nake).
B. Navîn - Kubernetes. Em mîkroxizmetên li ser wê bicîh dikin û dixebitin.
C. Bottom - metal tazî. Em ewr an tiştên mîna OpenStack bikar naynin, lê bi tevahî xwe dispêrin metala tazî.
Hemî qat ji hêla PaaS ve têne hev kirin. Û ev platform jî, ji sê beşan pêk tê.
I. Generator, bi navgîniya CLI ve tê kontrol kirin. Ew ew e ku ji pêşdebir re dibe alîkar ku bi awayek rast û bi kêmanî hewildanek mîkroxizmetek çêbike.
II. Berhevkarê hevgirtî bi kontrolkirina hemî amûran bi dashboardek hevpar.
III. Embarkirinî. Bi plansazkerên ku bixweber ji bo çalakiyên girîng vekêşan destnîşan dikin ve girêdayî ye. Bi saya pergalek wusa, tenê ji ber ku kesek ji bîr kir ku li Jira karek saz bike yek peywirek jî ji dest naçe. Em ji bo vê amûrek navxweyî ya bi navê Atlas bikar tînin.
Pêkanîna mîkroxizmetên li Avito di heman demê de li gorî nexşeyek yekane tête kirin, ku di her qonaxek pêşkeftin û berdanê de kontrola li ser wan hêsan dike.
Xeta pêşkeftina mîkroxizmeta standard çawa dixebite?
Bi gelemperî, zincîra çêkirina microservice wiha xuya dike:
CLI-push → Pêkvekirina Berdewam → Bake → Bicihkirin → Testên çêkirî → Testên Kanarya → Testkirina Squeeze → Hilberîn → Maintenance.
Ka em tam bi vê rêzê derbas bikin.
CLI-push
• Çêkirina microservice.
Me ji bo demek dirêj têkoşîn kir ku em her pêşdebiran hîn bikin ka meriv çawa mîkroservisan dike. Vê yekê di Confluence de rêwerzên berfireh nivîsandin. Lê plan hatin guhertin û hatin temamkirin. Encam ev e ku di destpêka rêwîtiyê de kêşek xuya bû: ji bo destpêkirina mîkroxizmetan pir wext girt, û hîn jî di dema afirandina wan de pir caran pirsgirêk derketin.
Di dawiyê de, me karûbarek CLI ya hêsan çêkir ku gava ku mîkroxizmetek diafirîne gavên bingehîn bixweber dike. Di rastiyê de, ew li şûna pêla git yekem digire. Va ye ku ew bi rastî çi dike.
- Li gorî şablonek karûbarek diafirîne - gav bi gav, di moda "sêrbaz". Di pişta Avito de şablonên me yên zimanên bernamesaziyê yên sereke hene: PHP, Golang û Python.
- Yek ferman di demekê de hawîrdorek ji bo pêşkeftina herêmî li ser makîneyek taybetî saz dike - Minikube tê destpêkirin, nexşeyên Helm bixweber di kubernetesên herêmî de têne çêkirin û destpêkirin.
- Databasa pêwîst girêdide. Pêşdebir ne hewce ye ku IP-yê, têketin û şîfreya xwe bizanibe da ku bigihîje databasa ku jê re hewce dike - çi herêmî be, li Stage, an di hilberînê de. Digel vê yekê, databas tavilê di mîhengek xelet-tolerans û bi hevsengiyê de tê bicîh kirin.
- Ew bi xwe kombûna zindî pêk tîne. Ka em bibêjin pêşdebirek bi IDE-ya xwe di mîkroxizmetek de tiştek rast kir. Karûbar guhertinên di pergala pelan de dibîne û, li ser bingeha wan, serîlêdanê (ji bo Golang) ji nû ve ava dike û ji nû ve dest pê dike. Ji bo PHP-ê, em tenê pelrêça di hundurê kubê de dişînin û li wir-ji nû ve barkirina zindî "xweber" tê wergirtin.
- Ototestan çêdike. Di forma valahiyan de, lê ji bo karanîna pir maqûl e.
• Bicihkirina Microservice.
Bicihkirina mîkroxizmetek berê ji bo me hinekî karek bû. Jêrîn hewce bûn:
I. Dockerfile.
II. Config.
III. Nexşeya Helm, ku bixwe giran e û tê de ye:
- nexşeyên xwe;
- şablonan;
- nirxên taybetî yên ku hawîrdorên cûda têne hesibandin.
Me êşa ji nû ve xebitandina xuyangên Kubernetes kişand, lewra ew naha bixweber têne çêkirin. Lê ya herî girîng, wan bicîkirinê heya sînor hêsan kir. Ji niha û pê ve me Dockerfile heye, û pêşdebir tevaya vesazkirinê di yek pelek kurt a app.toml de dinivîse.
Erê, û di app.toml bixwe de tiştek heye ku meriv deqeyekê bike. Em diyar dikin ku li ku derê û çend kopiyên karûbarê bilind bikin (li ser servera dev, li ser sehneyê, di hilberînê de), û girêdanên wê destnîşan dikin. Bala xwe bidin mezinahiya rêzê = "biçûk" di bloka [motorê] de. Ev sînorê ku dê bi navgîniya Kubernetes ve ji karûbarê re were veqetandin e.
Dûv re, li ser bingeha mîhengê, hemî nexşeyên Helm ên pêwîst bixweber têne çêkirin û girêdanên bi databasan re têne çêkirin.
• Rastkirina bingehîn. Kontrolên weha jî otomatîk in.
Pêdivî ye ku bişopînin:
- Dockerfile heye;
- app.toml heye;
- Belgekirin heye?
- girêdayîbûn di rê de ye?
- ka qaîdeyên hişyariyê hatine danîn.
Heya xala paşîn: xwedan karûbar bixwe diyar dike ku kîjan metrîkên hilberê çavdêrî bike.
• Amadekirina belgeyan.
Dîsa jî qada pirsgirêkê ye. Wusa dixuye ku ya herî eşkere ye, lê di heman demê de ew di heman demê de tomarek e ku "pir caran tê jibîrkirin", û ji ber vê yekê zencîreyek xedar e.
Pêdivî ye ku ji bo her microservice belgeyek hebe. Ew blokên jêrîn vedigire.
I. Danasîna kurt a xizmetê. Bi rastî çend hevokan li ser çi dike û çima hewce ye.
II. Girêdana diagrama mîmarî. Girîng e ku bi nihêrînek bilez li ser wê hêsan tê fêm kirin, mînakî, gelo hûn Redis ji bo cachkirinê bikar tînin an wekî dikana daneya sereke di moda domdar de bikar tînin. Di Avito-ê de heya niha ev girêdanek ji Confluence re ye.
III. Runbook. Rêbernameyek kurt li ser destpêkirina karûbar û tevliheviyên hilgirtina wê.
IV. FAQ, li ku derê wê baş be ku hûn pêşbîniya pirsgirêkên ku hevkarên we dema ku bi karûbarê re dixebitin re rû bi rû bimînin.
V. Danasîna xalên dawî ji bo API. Ger ji nişkê ve we mebest diyar nekiribe, hevkarên ku mîkroxizmetên wan bi yên we re têkildar in dê hema bê guman heqê wê bidin. Naha em ji bo vê yekê Swagger û çareseriya me bi kurtî bikar tînin.
VI. Labels. An jî nîşankerên ku destnîşan dikin ku karûbar ji kîjan hilber, fonksiyon, an dabeşkirina strukturel a pargîdaniyê ye. Ew ji we re dibin alîkar ku hûn zû fam bikin, mînakî, gelo hûn fonksiyona ku hevkarên we hefteyek berê ji bo heman yekîneya karsaziyê derxistine qut dikin.
VII. Xwedî an xwediyên xizmetê. Di pir rewşan de, ew - an ew - dikarin bixweber bi karanîna PaaS-ê ve bêne destnîşankirin, lê ji bo ku em li tenişta ewle bin, em ji pêşdebir re hewce dikin ku wan bi destan diyar bike.
Di dawiyê de, ew pratîkek baş e ku hûn belgeyan binirxînin, mîna vekolîna kodê.
Integrasyonê berdewam dike
- Amadekirina depoyan.
- Afirandina boriyek li TeamCity.
- Sazkirina mafên.
- Li xwediyên xizmetê bigerin. Li vir nexşeyek hîbrîd heye - nîşankirina destan û xweseriya hindiktirîn ji PaaS. Dema ku karûbar ji bo piştgiriyê ji tîmek din a pêşkeftinê re têne veguheztin an, mînakî, heke pêşdebirê karûbarê dev jê berde, nexşeyek bi tevahî otomatîk têk diçe.
- Tomarkirina karûbarek li Atlas (li jor binêre). Bi hemû xwedî û girêdayiyên xwe re.
- Kontrolkirina koçberan. Em kontrol dikin ka yek ji wan potansiyel xeternak e. Mînakî, di yek ji wan de tabloyek alter an tiştek din derdikeve ku dikare lihevhatina şemaya daneyê di navbera guhertoyên cihêreng ên karûbar de bişkîne. Dûv re koçberî nayê kirin, lê di abonetiyekê de tê danîn - PaaS divê ji xwediyê karûbar re îşaret bike dema ku karanîna wê ewle ye.
Birajtin
Qonaxa paşîn karûbarên pakkirinê berî bicîhkirinê ye.
- Avakirina sepanê. Li gorî klasîkan - di wêneyek Docker de.
- Nifşa nexşeyên Helm ji bo karûbar bixwe û çavkaniyên têkildar. Di nav de ji bo databases û cache. Ew bixweber li gorî konfigurasyona app.toml ya ku di qonaxa CLI-push de hatî çêkirin têne çêkirin.
- Afirandina bilêtan ji bo rêvebiran ji bo vekirina benderan (gava ku pêwîst be).
- Testên yekîneyê dimeşînin û vegirtina kodê hesab dikin. Ger vegirtina kodê li binê sînorê diyarkirî be, wê hingê bi îhtîmalek mezin dê karûbar bêtir neçe - berbi bicîhkirinê. Ger ew li ser sînorê pejirandinê be, wê hingê dê karûbarek hejmûnek "pesîmîzasyon" were destnîşan kirin: wê hingê, heke di nav demê de di nîşaneyê de başbûnek çênebe, pêşdebir dê agahdariyek werbigire ku di warê ceribandinan de pêşkeftinek tune ( û divê tiştek li ser wê were kirin).
- Hesabkirina bîranîn û sînorên CPU. Em bi giranî li Golang mîkroservisan dinivîsin û wan li Kubernetes dimeşînin. Ji ber vê yekê yek hûrgulî bi taybetmendiya zimanê Golang ve girêdayî ye: ji hêla xwerû, dema ku dest pê dike, hemî navikên li ser makîneyê têne bikar anîn, heke hûn bi eşkere guhêrbar GOMAXPROCS saz nekin, û gava ku çend karûbarên weha li ser heman makîneyê têne destpêkirin, ew dest pê dikin. ji bo çavkaniyan pêşbaziyê bikin, bi hev re mudaxele bikin. Grafikên li jêr destnîşan dikin ka wextê darvekirinê çawa diguhezîne ger hûn serîlêdanê bêyî nakokî û di pêşbaziya moda çavkaniyan de bimeşînin. (Çavkaniyên grafikan in ).
Dema darvekirinê, kêmtir çêtir e. Herî zêde: 643 ms, herî kêm: 42 ms. Wêne bitikîne.
Dem ji bo emeliyatê, kêmtir çêtir e. Herî zêde: 14091 ns, herî kêm: 151 ns. Wêne bitikîne.
Di qonaxa amadekirina civînê de, hûn dikarin vê guhêrbar bi eşkere saz bikin an hûn dikarin pirtûkxaneyê bikar bînin ji xortên Uber.
Bikaranîn
• Peymanan kontrol dikin. Berî ku hûn dest bi radestkirina meclîsên karûbarê li hawîrdorên xwe yên armanckirî bikin, hûn hewce ne ku jêrîn kontrol bikin:
- Xalên dawî yên API.
- Lihevhatina bersivên xalên dawiya API-ê bi şemayê re.
- Forma têketinê.
- Sazkirina sernavên ji bo daxwazên karûbarê (niha ev ji hêla netramesh ve tê kirin)
- Dema şandina peyaman ji otobusa bûyerê re nîşana xwedan destnîşan dike. Ev ji bo şopandina girêdana karûbaran li seranserê otobusê hewce ye. Hûn dikarin hem daneyên idempotent bişînin otobusê, ku pêwendiya karûbaran zêde nake (ku baş e), hem jî daneyên karsaziyê ku pêwendiya karûbaran xurt dike (ku pir xirab e!). Û di nuqteya ku ev girêdan dibe pirsgirêk, têgihîştina kî otobusê dinivîse û dixwîne dibe alîkar ku karûbar bi rêkûpêk veqetîne.
Li Avito hîn pir pir kongre nînin, lê hewza wan berfireh dibe. Her ku bêtir peymanên weha bi rengek ku tîm dikare fêm bike û fêm bike peyda bibin, ew qas hêsantir e ku meriv hevrêziya di navbera mîkroservisan de biparêze.
Testên sentetîk
• Tehlîlkirina dorpêçê ya girtî. Ji bo vê em niha çavkaniya vekirî bikar tînin . Pêşîn, ew barkirina rastîn li ser karûbarê tomar dike, dûv re - tenê di pêvekek girtî de - wê mîna hev dike.
• Stress Testing. Em hewl didin ku hemî karûbaran bigihînin performansa çêtirîn. Û hemî guhertoyên her karûbar divê bêne ceribandina barkirinê - bi vî rengî em dikarin performansa heyî ya karûbar û cûdahiya bi guhertoyên berê yên heman karûbarê fam bikin. Ger, piştî nûvekirinek karûbar, performansa wê yek û nîv carî daket, ev ji bo xwediyên wê nîşanek zelal e: hûn hewce ne ku kodê bikolin û rewşê rast bikin.
Em daneyên berhevkirî bikar tînin, mînakî, da ku bi rengek rast pîvandina otomatîkî bicîh bikin û, di dawiyê de, bi gelemperî fêm bikin ka karûbar çiqas berbelav e.
Di dema ceribandina barkirinê de, em kontrol dikin ka ka vexwarina çavkaniyê sînorên destnîşankirî pêk tîne. Û em di serî de li ser ekstreman disekinin.
a) Em li barkirina tevayî dinêrin.
- Pir piçûk - bi îhtîmalek mezin tiştek bi tevahî naxebite heke bar ji nişkê ve çend caran dakeve.
- Pir mezin - optimîzasyon hewce ye.
b) Em li qutbûnê li gorî RPS dinihêrin.
Li vir em li cûdahiya di navbera guhertoya heyî û ya berê û hêjmara giştî de dinêrin. Mînakî, heke karûbarek 100 rps hilberîne, wê hingê ew an kêm tê nivîsandin, an jî ev taybetmendiya wê ye, lê di her rewşê de, ev sedemek e ku meriv ji nêz ve li karûbarê binêre.
Ger berevajî vê yekê, pir zêde RPS hene, wê hingê dibe ku celebek xeletiyek hebe û hin xalên dawîn ji cîbicîkirina bargiraniyê rawestandiye, û yekek din jî bi hêsanî tê dest pê kirin. return true;
testên Kanarya
Piştî ku em ceribandinên sentetîk derbas dikin, em mîkroxizmetê li ser hejmarek piçûk bikarhêneran ceribandin. Em bi baldarî dest pê dikin, bi pişkek piçûk a temaşevanên armanckirî yên karûbar - ji% 0,1 kêmtir. Di vê qonaxê de, pir girîng e ku pîvanên teknîkî û hilberên rast di çavdêriyê de werin girtin da ku ew pirsgirêk di karûbarê de bi lez û bez nîşan bidin. Dema herî kêm ji bo ceribandina kanariyê 5 hûrdem e, ya sereke 2 saet e. Ji bo karûbarên tevlihev, me dem bi destan destnîşan dike.
Ka em analîz bikin:
- Metrîkên ziman-taybetî, bi taybetî, xebatkarên php-fpm;
- xeletiyên di Sentry de;
- statûyên bersivê;
- dema bersivê, rast û navîn;
- derengmayîn;
- îstîsna, pêvajokirin û bê destekirin;
- metrîkên hilberê.
Squeeze Testing
Testkirina Squeeze jî jê re ceribandina "pişkandin" tê gotin. Navê teknîkê di Netflix de hate nas kirin. Esasê wê ev e ku pêşî em yek mînakek bi seyrûsefera rastîn heya xala têkçûnê tije dikin û bi vî rengî sînorê wê destnîşan dikin. Dûv re em mînakek din lê zêde dikin û vê cotê bar dikin - dîsa herî zêde; em bi "qelp"a ewil tavan û delta wan dibînin. Û ji ber vê yekê em yek carî yek nimûne girêdidin û şêwaza guherînan hesab dikin.
Daneyên ceribandinê bi "pişkandinê" di heman demê de diherike nav databasek metrîka hevpar, ku em an encamên barkirina sûnî bi wan dewlemend dikin, an jî tewra "sentetîk" bi wan re diguhezînin.
Çêkerî
• Scaling. Dema ku em karûbarek hilberandinê derdixin, em çavdêrî dikin ka ew çawa mezin dibe. Di ezmûna me de, çavdêrîkirina tenê nîşanên CPU-ê bêbandor e. Pîvana otomatîkî ya bi pîvana RPS-ê di forma xweya paqij de dixebite, lê tenê ji bo hin karûbaran, wekî weşana serhêl. Ji ber vê yekê em pêşî li metrîkên hilberê-taybet ên serîlêdanê dinêrin.
Wekî encamek, dema pîvandinê em analîz dikin:
- Nîşaneyên CPU û RAM,
- hejmara daxwazên di dorê de,
- dema bersivê,
- pêşbîniya li ser bingeha daneyên dîrokî yên berhevkirî.
Dema ku karûbarek pîvandinê, di heman demê de girîng e ku meriv girêdanên wê bişopîne da ku em yekem karûbarê di zincîrê de pîvandinê nekin, û yên ku ew digihîje di bin barkirinê de têk diçin. Ji bo sazkirina barek pejirandî ji bo tevahiya hewza karûbaran, em li daneyên dîrokî yên karûbarê girêdayî "nêzîktirîn" dinêrin (li ser bingeha berhevdana nîşaneyên CPU û RAM-ê, bi metrîkên taybetî yên serîlêdanê re) û wan bi daneyên dîrokî re berhev dikin. ya karûbarê destpêkirinê, û hwd li seranserê "zincîra girêdayîbûnê" ", ji serî heta binî.
Xizmet
Piştî ku mîkroxizmet tê xebitandin, em dikarin pêlavan pêve bikin.
Li vir rewşên tîpîk hene ku tê de teşqele çêdibin.
- Koçberiyên potansiyel xeternak hatin dîtin.
- Nûvekirinên ewlehiyê hatin berdan.
- Karûbar bixwe ji demek dirêj ve nehatiye nûve kirin.
- Barkirina karûbarê bi rengek berbiçav kêm bûye an hin metrîkên hilberê wê li derveyî rêza normal in.
- Karûbar êdî hewcedariyên platforma nû nagire.
Hin tetikan berpirsiyariya aramiya xebatê ne, hin - wekî fonksiyonek parastina pergalê - mînakî, hin karûbar ji demek dirêj ve nehatine bicîh kirin û wêneya wê ya bingehîn ji kontrolên ewlehiyê rawestiyaye.
Dashboard
Bi kurtasî, dashboard panela kontrolê ya tevahiya PaaS-ya me ye.
- Agahiyek yekane di derbarê karûbarê de, digel daneyên li ser vegirtina ceribandina wê, hejmara wêneyên wê, hejmara kopiyên hilberînê, guhertoyên, hwd.
- Amûrek ji bo fîlterkirina daneyan ji hêla karûbar û etîketan (nîşankerên girêdayîbûna yekîneyên karsaziyê, fonksiyona hilberê, hwd.)
- Amûrek ji bo entegrasyonê bi amûrên binesaziyê yên ji bo şopandin, têketin û şopandinê.
- Yek xalek belgeya karûbarê.
- Nêrînek yekane ya hemî bûyeran li seranserê karûbaran.
Tevahî
Berî danasîna PaaS-ê, pêşdebirek nû dikare çend hefte derbas bike ku hemî amûrên ku ji bo destpêkirina mîkroxizmetek di hilberînê de hewce ne derbas bike: Kubernetes, Helm, taybetmendiyên meya TeamCity ya hundurîn, sazkirina girêdanên bi databas û kaşê re bi rengek toleransê xelet, hwd. Niha ew Ji bo xwendina destpêka bilez û afirandina karûbarê xwe çend demjimêran digire.
Min ji bo HighLoad ++ 2018 raporek li ser vê mijarê da, hûn dikarin lê temaşe bikin и .
track bonus ji bo kesên ku heta dawiyê dixwînin
Em li Avito ji bo pêşdebiran perwerdeyek navxweyî ya sê-rojî organîze dikin , pisporê mîmariya mîkro-service. Em dixwazin derfeta beşdarbûna wê bidin yek ji xwendevanên vê postê. Bernameya perwerdeyê hat weşandin.
Perwerde dê di navbera 5-7ê Tebaxê de li Moskowê pêk were. Ev rojên xebatê ne ku dê bi tevahî werin dagir kirin. Nîvro û perwerde dê li ofîsa me be, û beşdarê hilbijartî dê bixwe heqê rêwîtiyê û rûniştinê bide.
Hûn dikarin ji bo beşdarbûnê serlêdan bikin . Ji we - bersiva pirsa çima hûn hewce ne ku beşdarî perwerdehiyê bibin û agahdariya li ser meriv çawa bi we re têkilî daynin. Bi Îngilîzî bersiv bidin, ji ber ku Chris dê beşdarê ku dê bixwe beşdarî perwerdehiyê bibe hilbijêrin.
Em ê navê beşdarê perwerdehiyê di nûvekirina vê postê û li ser torên civakî Avito ji bo pêşdebiran ragihînin (AvitoTech in , , ) herî dereng heta 19ê Tîrmehê.
Source: www.habr.com