PĂ«rshĂ«ndetje! UnĂ« quhem Vadim Madison, dhe udhĂ«heq zhvillimin e System Platform nĂ« Avito. Ka pasur shumĂ« biseda nĂ« kompani mbi kalimin nga njĂ« arkitekturĂ« monolite nĂ« mikrosisteme. ĂshtĂ« koha tĂ« ndajem se si e kemi transformuar infrastrukturĂ«n tonĂ« pĂ«r tĂ« nxjerrĂ« sa mĂ« shumĂ« pĂ«rfitime nga mikrosistemet dhe pĂ«r tĂ« mos humbur nĂ« to. Si na ndihmon PaaS, si e kemi thjeshtuar deployment-in dhe si e kemi reduktuar krijimin e mikrosistemit nĂ« njĂ« klikim â lexoni mĂ« tej. Jo çdo gjĂ« qĂ« do tĂ« shkruaj mĂ« poshtĂ« Ă«shtĂ« zbatuar plotĂ«sisht nĂ« Avito, disa janĂ« aspekte tĂ« zhvillimit tĂ« platformĂ«s sonĂ«.
(Po ashtu, në fund të këtij artikulli do t'ju flas për mundësinë për t'u regjistruar në një seminar tre ditor nga eksperti për arkitekturën e mikrosistemeve Chris Richardson).
Si arritëm te mikrosistemet
Avito është një nga platformën më të mëdha të shpalljeve në botë, me më shumë se 15 milion shpallje të reja çdo ditë. Backend-i ynë pranon më shumë se 20,000 kërkesa në sekondë. Aktualisht kemi disa qindra mikrosistema.
ArkitekturĂ«n mikrosistemore ne e kemi ndĂ«rtuar pĂ«r disa vite. Si e kemi bĂ«rĂ« kĂ«tĂ« â kolegĂ«t tanĂ« flasin nĂ« detaje nĂ« seksionin tonĂ« nĂ« RIT++ 2017. NĂ« CodeFest 2017 (shih. ), Sergey Orlov dhe Mikhail Prokopchuk sqaruan nĂ« detaje pse kemi pasur nevojĂ« pĂ«r kalimin nĂ« mikrosisteme dhe rolin e Kubernetes nĂ« kĂ«tĂ« drejtim. Tani po bĂ«jmĂ« gjithçka pĂ«r tĂ« minimizuar kostot e shkallĂ«zimit qĂ« lidhen me kĂ«tĂ« arkitekturĂ«.
NĂ« fillim, ne nuk krijuam njĂ« ekosistem qĂ« do tĂ« na ndihmonte nĂ« mĂ«nyrĂ« gjithĂ«pĂ«rfshirĂ«se nĂ« zhvillimin dhe lansimin e mikrosistemeve. Thjesht grumbulluam zgjidhje tĂ« mira open source, i lançuam ato dhe i ofruam zhvilluesit tĂ« merret me to. NĂ« fund, zhvilluesi shkon nĂ« shumĂ« vende (dashboard, shĂ«rbime tĂ« brendshme), duke forcuar kĂ«shtu dĂ«shirat pĂ«r tĂ« shkruar kodin nĂ« mĂ«nyrĂ« tradicionale, nĂ« monolit. Ngjyrat e gjelbra nĂ« diagramet mĂ« poshtĂ« tregojnĂ« atĂ« qĂ« zhvilluesi e bĂ«n ndryshe me duar, ndĂ«rsa ngjyra e verdhĂ« â automatizimin.
Tani në utilitarin CLI PaaS, një komandë krijon një shërbim të ri, ndërsa dy të tjera shtojnë një bazë të re të dhënash dhe e deployojnë në Stage.
Si ta kalojmë epokën e "shkëputjes mikrosistemore"
Me arkitekturën monolite, për të siguruar konsistencën e ndryshimeve në produkt, zhvilluesit ishin të detyruar të kuptonin se çfarë ndodhte tek fqinjët e tyre. Tani, me arkitekturën e re, kontekstet e shërbimeve nuk varen më nga njëra-tjetra.
Përveç kësaj, për të qenë efektive, arkitektura mikrosistemore kërkon vendosjen e shumë proceseve, siç janë:
âą logimi;
⹠gjurmimi i kërkesave (Jaeger);
âą agregimi i gabimeve (Sentry);
âą statuset, mesazhet, ngjarjet nga Kubernetes (Event Stream Processing);
⹠race limit / circuit breaker (mund të përdorim Hystrix);
⹠kontrolli i lidhjes midis shërbimeve (ne përdorim Netramesh);
âą monitorimi (Grafana);
⹠ndërtimi (TeamCity);
âą komunikimi dhe njoftimi (Slack, email);
âą ndjekja e detyrave (Jira);
⹠përgatitja e dokumentacionit.
Për të siguruar që sistemi të mos humbasë integritetin e tij dhe të mbetet efektiv gjatë shkallëzimit, ne e kemi ripërkufizuar organizimin e punës së mikrosistemeve në Avito.
Si e menaxhojmë mikrosistemin
Të ushtrojmë një "politikë të përbashkët" midis shumë mikrosistemeve të Avito ndihmojnë:
- ndarja e infrastrukturës në nivele;
- koncepti i Platformës si Shërbim (PaaS);
- monitorimi i gjithçkaje që ndodh me mikrosistemet.
Nivelet e abstraksionit të infrastrukturës përfshijnë tri shtresa. Do të shkojmë nga lartë në poshtë.
A. E para â service mesh. Fillimisht provuam Istio, por rezultoi se pĂ«rdor shumĂ« burime, qĂ« nĂ« volumet tona del shumĂ« shtrenjtĂ«. Prandaj, inxhinieri i lartĂ« nĂ« ekipin e arkitekturĂ«s, Alexander Luk'yanshenko, zhvilloi njĂ« zgjidhje tĂ« vetme â (e disponueshme nĂ« Open Source), e cila tani e pĂ«rdorim nĂ« prodhim dhe konsumon disa herĂ« mĂ« pak resurse sesa Istio (por nuk bĂ«jnĂ« gjithçka pĂ«r tĂ« cilat mund tĂ« krenohet Istio).
B. E mesme â Kubernetes. AtĂ« e pĂ«rdorim pĂ«r tĂ« implementuar dhe operuar mikrosistemet.
C. E poshtme â bare metal. Ne nuk pĂ«rdorim cloud dhe gjĂ«ra si OpenStack, por jemi plotĂ«sisht nĂ« bare metal.
Të gjitha shtresat bashkohen në PaaS. Dhe kjo platformë, nga ana e saj, përbëhet nga tre pjesë.
I. Generatorët, të menaxhuar përmes utilitarit CLI. Kjo ndihmon zhvilluesin të krijojë mikrosistemin në mënyrë të duhur dhe me minimum përpjekjeje.
II. Koleksioni përmbledhës me kontrollin e të gjithë mjeteve përmes një paneli të përbashkët.
III. Depositi. Lidhet me planifikuesit, të cilët automatikisht vendosin triggers për veprime të rëndësishme. Falë këtij sistemi, asnjë detyrë nuk shpërbëhet thjesht sepse dikush harroi të vendosë një detyrë në Jira. Ne përdorim një mjet të brendshëm të quajtur Atlas për këtë.
Implementimi i mikroshërbimeve në Avito gjithashtu zhvillohet sipas një skeme uniforme, e cila lehtëson kontrollin mbi ta në çdo fazë të zhvillimit dhe lansimit.
Si funksionon lampadja standarde e zhvillimit të mikroshërbimeve
Në një formë të përgjithshme, zinxhiri i krijimit të mikroshërbimit duket si më poshtë:
CLI-push â Integrimi i vazhdueshĂ«m â Bake â Deploy â Testet artificiale â Testet Canary â Squeeze Testing â Prodhim â Mirmbajtje.
Le të shkojmë përmes saj pikërisht në këtë rend.
CLI-push
⹠Krijimi i mikroshërbimit.
Ne punuam shumĂ« pĂ«r tĂ« mĂ«suar çdo zhvillues si tĂ« bĂ«jĂ« mikroshĂ«rbime. Kemi shkruar udhĂ«zime tĂ« detajuara nĂ« Confluence. Por skemat ndryshonin dhe plotĂ«soheshin. Rezultati â ndodhi njĂ« ngushticĂ« nĂ« fillim tĂ« procesit: lançimi i mikroshĂ«rbimeve merrte shumĂ« mĂ« tepĂ«r kohĂ« se sa ishte e pranueshme, dhe gjithsesi gjatĂ« krijimit tĂ« tyre shpesh lindnin probleme.
Në fund, ne ndërtuam një utilitet të thjeshtë CLI që automatizon hapat kryesorë gjatë krijimit të mikroshërbimit. Në mënyrë efektive, ai zëvendëson git push-in e parë. Ky është saktësisht ajo që bën.
â Krijon shĂ«rbimin sipas njĂ« modeli â hap pas hapi, nĂ« modin "wizard". Ne kemi modele pĂ«r gjuhĂ«t kryesore tĂ« programimit nĂ« backendin e Avito: PHP, Golang dhe Python.
â Me njĂ« komandĂ« vendos ambientin pĂ«r zhvillim lokal nĂ« makinĂ«n pĂ«rkatĂ«se â Minikube ngrihet, helm-chartet generehen dhe nisin automatikisht nĂ« kubernetes-in lokal.
â Lidhet me bazĂ«n e tĂ« dhĂ«nave tĂ« kĂ«rkuar. Zhvilluesi nuk ka nevojĂ« tĂ« dijĂ« IP-nĂ«, emrin dhe fjalĂ«kalimin pĂ«r tĂ« aksesuar BDB-nĂ« e nevojshme â qoftĂ« lokal, qoftĂ« nĂ« Stage, qoftĂ« nĂ« prodhim. Gjithashtu, baza e tĂ« dhĂ«nave vendoset menjĂ«herĂ« nĂ« njĂ« konfigurim tĂ« qĂ«ndrueshĂ«m dhe me balancimin e ngarkesĂ«s.
â VetĂ« bĂ«n ndĂ«rtimin live. Le tĂ« themi, zhvilluesi ndryshon diçka nĂ« mikroshĂ«rbim pĂ«rmes IDE-sĂ« sĂ« tij. Utiliteti sheh ndryshimet nĂ« sistemin e skedarĂ«ve dhe pĂ«r kĂ«tĂ« arsye rifillon aplikacionin (pĂ«r Golang) dhe e rinis. PĂ«r PHP, ne thjesht e kalojmĂ« direktoren brenda kubit dhe aty live-reload funksionon "automatikisht".
â Gjeneron teste automatikisht. NĂ« formĂ«n e shablloneve, por krejt tĂ« pĂ«rdorshme.
⹠Deployimi i mikroshërbimit.
Derisa më parë dispersemi mikroshërbimin paksa të lodhshme. Ishte e nevojshme:
I. Dockerfile.
II. Konfig.
III. Helm-chart, i cili vetvetiu është voluminoz dhe përfshin:
â vetĂ« chartet;
â shabllonet;
â vlerat specifike qĂ« kanĂ« parasysh ambientet e ndryshme.
Ne e kemi eliminuar dhimbjen e rregullimit të manifestëve Kubernetes, dhe tani ato krijohen automatikisht. Por më e rëndësishmja, ne e kemi thjeshtuar deri në maksimum deploy-in. Tani kemi një Dockerfile, dhe të gjithë konfigurimin e zhvilluesi e shkruan në një skedë të vetme të shkurtër app.toml.
Po ashtu, në vetë app.toml tani bëhen punë për një minutë. Shkruajmë se sa kopje të shërbimit të ngrihen (në serverin dev, në staging, në prodhim), dhe tregojmë varësitë e tij. Vini re rreshtin size = "small" në bllokun [engine]. Ky është kufiri që do të ndahen shërbimit përmes Kubernetes.
Pastaj, mbi bazën e konfigurimit, krijohen automatikisht të gjitha chartet Helm të nevojshme dhe krijohen lidhjet me bazat e të dhënave.
⹠Validimi i bazës. Këto kontrole janë gjithashtu të automatizuara.
Duhet të monitorohet:
â a ka Dockerfile;
â a ka app.toml;
â a ka dokumentacion;
â a janĂ« varĂ«sitĂ« nĂ« rregull;
â a janĂ« vendosur rregullat e alerteve.
Për pikën e fundit: pronari i shërbimit vetë përcakton se cilat metrika produkti duhet të monitorohen.
âą PĂ«rgatitja e dokumentacionit.
Akoma një vend problematik. Duket si gjëja më evidente, por përveç kësaj është gjithashtu një nyje rekordisht "e harruar shpesh", dhe për pasojë edhe një pikë e dobët e zinxhirit.
ĂshtĂ« e nevojshme qĂ« dokumentacioni tĂ« jetĂ« pĂ«r çdo mikroshĂ«rbim. Ai pĂ«rfshin blloqet e mĂ«poshtme.
I. Përshkrimi i shkurtër i shërbimit.. Në mënyrë të vërtetë disa fraza për atë që bën dhe për çfarë përdoret.
II. Lidhja nĂ« diagramin e arkitekturĂ«s.. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« me njĂ« shikim tĂ« shpejtĂ« mbi tĂ«, tĂ« jetĂ« e lehtĂ« tĂ« kuptosh, pĂ«r shembull, nĂ«se po pĂ«rdorni Redis pĂ«r tĂ« ruajtur nĂ« memorie ose si krye depo nĂ« mĂ«nyrĂ« tĂ« qĂ«ndrueshme. NĂ« Avito, deri mĂ« tani kjo Ă«shtĂ« njĂ« lidhje nĂ« Confluence.
III. Runbook.. Një udhëzues i shkurtër për lancimin e shërbimit dhe hollësitë e trajtimit të tij.
IV. FAQ., ku do të ishte mirë të parashikohej problemet me të cilat mund të përballen kolegët tuaj gjatë punës me shërbimin.
V. Përshkrimi i endpoints për API.. Nëse përndryshe nuk e keni caktuar për destinacionet, fare sigurisht do të keni probleme me kolegët, të cilët mikroshërbimet e tyre lidhen me tuajin. Tani për tani, ne përdorim Swagger për këtë dhe zgjidhjen tonë të quajtur brief.
VI. Etiketat. Ose janë tregues që tregojnë se cila produkti, funksionaliteti, ose njësi organizative i kompanisë i përket shërbimit. Ato ndihmojnë për të kuptuar shpejt, për shembull, nëse po punoni mbi funksionalitetin që javën e kaluar e lansuan për të njëjtin biznes njësi kolegët tuaj.
VII. Pronari ose pronarët e shërbimit. Në shumicën e rasteve, ai - ose ata - përcaktohen automatikisht nga PaaS, por për siguri kërkojmë që zhvilluesi t'i tregojë ata manualisht.
Më në fund, një praktikë e mirë është të kryeni rishikimin e dokumentacionit, ashtu si me rishikimin e kodit.
Continuous Integration
- PĂ«rgatitja e depot.
- Krijimi i një pipeline në TeamCity.
- Vendosja e të drejtave.
- Gjetja e pronarëve të shërbimit. Këtu është një skemë hibrid, me etiketim manual dhe automatik minimal nga PaaS. Një skemë krejtësisht automatike shfaq probleme kur shërbimet transferohen në mbështetje në një ekip tjetër zhvillimi ose, për shembull, në rast se zhvilluesi i shërbimit largohet.
- Regjistrimi i shërbimit në Atlas (shih lart). Me të gjithë pronarët dhe varësitë e tij.
- Kontrolli i migrimeve. Kontrollojmë nëse mes tyre ka ndonjë që potencialisht mund të jetë e rrezikshme. Për shembull, në një prej tyre del një alter table ose ndonjë gjë tjetër që mund të dëmtojë përputhshmërinë e skemës së të dhënave mes versioneve të ndryshme të shërbimit. Atëherë migrimi nuk kryhet, por vihet në abonnement - PaaS duhet të sinjalizojë pronarin e shërbimit kur të bëhet e sigurt ta aplikojë.
Bake
Faza tjetër është paketimi i shërbimeve përpara se të depozitohen.
- Ndërtimi i aplikacionit. Sipas klasiken - në një imazh Docker.
- Generimi i Helm-chart për shërbimin dhe burimet e lidhura me të. Përfshirë për bazat e të dhënave dhe cache. Ato krijohen automatikisht në përputhje me konfigurimin app.toml, i cili u formua në fazën e CLI-push.
- Krijimi i tiketave për adminët për hapjen e porteve (kur kërkohet).
- Ekzekutimi i testeve njĂ«sore dhe llogaritja e mbulimit tĂ« kodit. NĂ«se mbulimi i kodit Ă«shtĂ« poshtĂ« vlerĂ«s sĂ« caktuar, atĂ«herĂ«, shumĂ« gjasa, mĂ« pas - nĂ« depozitimin - shĂ«rbimi nuk do tĂ« kalojĂ«. NĂ«se Ă«shtĂ« afĂ«r tĂ« pranueshmes, atij do tâi jepet njĂ« koeficient "pessimizues": kĂ«shtu qĂ« nĂ«se nuk ka pĂ«rmirĂ«sime tĂ« treguesit me kalimin e kohĂ«s, zhvilluesi do tĂ« marrĂ« njĂ« njoftim se nuk ka progres nĂ« çështjen e testeve (dhe diçka duhet tĂ« bĂ«jĂ« pĂ«r kĂ«tĂ«).
- Kalkulimi i kufizimeve për kujtesën dhe CPU. Kryesisht, mikroshërbimet i shkruajmë në Golang dhe i ekzekutojmë ato në Kubernetes. Prej këtu lidhet një nuancë, e cila është veçori e gjuhës Golang: në mënyrë të paracaktuar, kur ekzekutohet, angazhohen të gjitha bërthamat në makinë, përveç nëse nuk caktohet ndonjëherë variabla GOMAXPROCS dhe kur në një makinë ekzekutohen disa shërbime të tilla, ato fillojnë të garojnë për burimet, duke penguar njëra-tjetrën. Në grafiket e mëposhtme është treguar si ndryshon koha e ekzekutimit, nëse startoni aplikacionin pa konkurrencë dhe në modin e garës për burime. (Burimet e grafikëve janë ).
Koha e ekzekutimit, më e vogël - më e mirë. Maximum: 643ms, minimum: 42ms. Foto klike.
Koha për operacion, më e vogël - më e mirë. Maximum: 14091 ns, minimum: 151 ns. Foto klike.
Në fazën e përgatitjes së ndërtimit, mund të caktoni këtë variabël shprehimisht ose mund të përdorni bibliotekën nga ekipi i Uber.
DĂ«rgo
⹠Kontrollimi i konventave. Para se të filloni të dorëzoni ndërtimet e shërbimit në ambientet e paracaktuara, është e nevojshme të kontrolloni sa vijon:
â API endpoints.
â PĂ«rputhshmĂ«ria e pĂ«rgjigjeve tĂ« API endpoints me skemĂ«n.
â Formati i logeve.
â Caktimi i titujve gjatĂ« kĂ«rkesave nĂ« shĂ«rbim (aktualisht kĂ«tĂ« e bĂ«n netramesh)
â Vendosja e treguesit tĂ« pronarit gjatĂ« dĂ«rgimit tĂ« mesazheve nĂ« busin e ngjarjeve (event bus). Kjo Ă«shtĂ« e nevojshme pĂ«r ndjekjen e lidhshmĂ«risĂ« sĂ« shĂ«rbimeve nĂ«pĂ«rmjet busit. NĂ« bus mund tĂ« dĂ«rgoni tĂ« dhĂ«na idempotente, tĂ« cilat nuk rrisin lidhshmĂ«rinĂ« e shĂ«rbimeve (çka Ă«shtĂ« mirĂ«), ashtu si tĂ« dhĂ«na biznesi, tĂ« cilat e forcojnĂ« lidhshmĂ«rinĂ« e shĂ«rbimeve (çka Ă«shtĂ« shumĂ« keq!). Dhe nĂ« momentin kur kjo lidhshmĂ«ri bĂ«het problem, kuptimi i kush shkruan dhe lexon busin ndihmon pĂ«r tĂ« ndarĂ« saktĂ«sisht shĂ«rbimet.
Për momentin, konventat në Avito nuk janë shumë të shumta, por po zgjerohet grupi i tyre. Sa më shumë marrëveshje të tilla në një format të kuptueshëm dhe të përshtatshëm për ekipin, aq më e lehtë është të ruhet koherenca mes mikroshërbimeve.
Testet sintetike
⹠Testimi në një kontur të mbyllur. Për këtë tani përdorim open-source . Fillimisht, ai regjistron ngarkesën reale në shërbim, pastaj - pikërisht në konturin e mbyllur - e emulon atë.
⹠Testimi i ngarkesës. Të gjithë shërbimet përpiqemi t'i çojmë në performancën optimale. Dhe të gjitha versionet e secilit shërbim duhet të kalojnë testimin e ngarkesës - kështu ne mund të kuptojmë performancën aktuale të shërbimit dhe ndryshimin me versionet e mëparshme të këtij shërbimi. Nëse pas përditësimit të shërbimit performanca e tij ra në një dhe e gjysmë herë, kjo është një shenjë e qartë për pronarët e tij: duhet të thellohen në kod dhe të rregullojnë situatën.
Ne bazohemi të dhënave që kemi mbledhur, për shembull, për të implementuar saktësisht auto scaling dhe, në fund, për të kuptuar se sa mirë shërbimi mund të shkallëzohet.
Në testimin e ngarkesës, ne kontrollojmë nëse konsumimi i burimeve i përmbush kufizimet e vendosura. Dhe përqendrohemi kryesisht në ekstremet.
a) Shikojmë ngarkesën totale.
â ShumĂ« e ulĂ«t â ndoshta ndodhi ndonjĂ« problem, nĂ«se ngarkesa ka rĂ«nĂ« ndjeshĂ«m.
â ShumĂ« e lartĂ« â kĂ«rkohet optimizim.
b) Shikojmë në kufirin në RPS.
KĂ«tu shikojmĂ« edhe diferencĂ«n midis versionit aktual dhe atij tĂ« mĂ«parshĂ«m dhe numrin total. PĂ«r shembull, nĂ«se shĂ«rbimi ofron 100 rps â mund tĂ« jetĂ« ose i shkruar keq, ose kjo Ă«shtĂ« specifikĂ« e tij, por megjithatĂ«, kjo Ă«shtĂ« njĂ« mundĂ«si pĂ«r tĂ« shqyrtuar me vĂ«mendje shĂ«rbimin.
Nëse RPS është përkundrazi shumë i lartë, ndoshta ka ndodhur ndonjë problem dhe ndonjë nga endpoint-të ka ndaluar të kryejë ngarkesë të dobishme, por thjesht aktivizohet ndonjë return true;
Canary-teste
Pas kalimit tĂ« testeve sintetike, ne testojmĂ« funksionimin e mikrosherbimit me njĂ« numĂ«r tĂ« vogĂ«l pĂ«rdoruesish. FillojmĂ« ngadalĂ«, me njĂ« pjesĂ« minimale tĂ« publikut tĂ« supozuar tĂ« shĂ«rbimit â mĂ« pak se 0.1%. NĂ« kĂ«tĂ« fazĂ«, Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme qĂ« nĂ« monitorim tĂ« jenĂ« vendosur metrikat e duhura teknike dhe produktore, nĂ« mĂ«nyrĂ« qĂ« ato tĂ« tregojnĂ« sa mĂ« shpejt problemin nĂ« shĂ«rbim. Koha minimale e testit canary Ă«shtĂ« 5 minuta, ndĂ«rsa ajo kryesore â 2 orĂ«. PĂ«r shĂ«rbimet komplekse vendosim kohĂ«n manualisht.
Analizojmë:
â metrikat specifike pĂ«r gjuhĂ«n, veçanĂ«risht punĂ«toret php-fpm;
â gabimet nĂ« Sentry;
â statuset e pĂ«rgjigjeve;
â koha e pĂ«rgjigjeve (response time), e saktĂ« dhe mesatare;
â latency;
â pĂ«rjashtimet, tĂ« trajtuara dhe tĂ« pa trajtuara;
â metrikat produktore.
Squeeze Testing
Squeeze Testing gjithashtu quhet testim pĂ«rmes "shkĂ«mbimit". Emri i metodĂ«s Ă«shtĂ« futur nga Netflix. Thelbi i saj Ă«shtĂ« qĂ« fillimisht ne mbushim njĂ« instancĂ« me trafik real deri nĂ« pikĂ«n e dĂ«shtimit dhe kĂ«shtu vendosim kufirin e saj. MĂ« pas, shtojmĂ« njĂ« innstancĂ« tjetĂ«r dhe e ngarkojmĂ« atĂ« çift â pĂ«rsĂ«ri deri nĂ« maksimum; ne shikojmĂ« plafonin e tyre dhe ndryshimin me "shkĂ«mbimin" e parĂ«. Dhe kĂ«shtu vazhdojmĂ« tĂ« lidhim njĂ« instancĂ« pĂ«r njĂ« hap dhe llogarisim rregullsinĂ« nĂ« ndryshime.
Të dhënat nga testet përmes "shkëmbimit" gjithashtu grumbullohen në bazën e përgjithshme të metrikave, ku ne ose i pasurojmë me rezultatet e ngarkesës artificiale, ose i zëvendësojmë ato me "sintetik".
Prodaksheni
⹠Shkallëzimi. Duke nxjerrë shërbimin në prodhimin, ne ndjekim se si shkallëzohet. Të monitorosh vetëm treguesit e CPU, nga përvoja jonë, nuk është efektiv. Auto scaling me benchmarking-un RPS në mënyrë të pastër funksionon, por vetëm për shërbime të caktuara, për shembull, transmetim online. Pra, ne shikojmë në radhë të parë në metrikat produktore që janë specifike për aplikacionin.
Në fund, gjatë shkallëzimit, analizojmë:
â treguesit e CPU dhe RAM,
â numri i kĂ«rkesave nĂ« radhĂ«,
â koha e pĂ«rgjigjes,
â parashikimi nĂ« bazĂ« tĂ« tĂ« dhĂ«nave historike tĂ« grumbulluara.
Gjatë shkallëzimit të shërbimit është gjithashtu e rëndësishme të ndjekim varësitë e tij, në mënyrë që të mos ndodhë që ne të shkallëzojmë shërbimin e parë në zinxhir, ndërsa ata që ai i drejtohet bjerë nën ngarkesë. Për të vendosur një ngarkesë të pranueshme për të gjithë grupin e shërbimeve, shikojmë të dhënat historike të shërbimit "më të afërt" të varur (në përputhje me kombinimin e treguesve CPU dhe RAM së bashku me metrikat specifike për aplikacionin) dhe i krahasojmë ato me të dhënat historike të shërbimit fillestar, dhe kështu me radhë në të gjithë "zinxhirin e varësive", nga lart poshtë.
Ruinimi
Pasi mikrosherbimi është vendosur në funksion, ne mund të vendosim trigger-a mbi të.
Ja situatat tipike, në të cilat aktivizohen trigger-at.
â Migrations tĂ« mundshme tĂ« rrezikshme janĂ« zbuluar.
â JanĂ« bĂ«rĂ« pĂ«rditĂ«sime tĂ« sigurisĂ«.
â ShĂ«rbimi vetĂ« nuk Ă«shtĂ« pĂ«rditĂ«suar pĂ«r njĂ« kohĂ« tĂ« gjatĂ«.
â Ka pasur njĂ« rĂ«nie tĂ« ndjeshme nĂ« ngarkesĂ«n e shĂ«rbimit ose ndonjĂ« nga metrikat e tij produktore kalon jashtĂ« normĂ«s.
â ShĂ«rbimi ka ndaluar sĂ« pĂ«rmbushuri kĂ«rkesat e reja tĂ« platformĂ«s.
Disa nga trigger-at janĂ« pĂ«r stabilitetin e funksionimit, disa si njĂ« funksion i shĂ«rbimit tĂ« sistemit â pĂ«r shembull, ndonjĂ« shĂ«rbim qĂ« nuk Ă«shtĂ« depozitohar pĂ«r njĂ« kohĂ« tĂ« gjatĂ« dhe bazamenti i tij ka ndaluar sĂ« kaluar kontrollet e sigurisĂ«.
Dashboard
Nëse e përmbledhim, paneli i kontrollit është qendra e monitorimit të gjithë PaaS tonë.
- Një pikë e vetme informacioni mbi shërbimin, me të dhëna për mbulimin e testeve, numrin e imazheve të tij, numrin e kopjeve në prodhim, versione etj.
- Një mjet filtrimi të dhënash sipas shërbimeve dhe labels (etiketave të përkatësisë për njësitë e biznesit, funksionalitetin produktor etj.)
- Një mjet integrimi me instrumentet infrastrukturore për ruajtjen e gjurmëve, logimin, monitorimin.
- Një pikë e vetme dokumentacioni mbi shërbimet.
- Një pikë e vetme e shqyrtimit për të gjitha ngjarjet në shërbime.
Në përfundim
Para adoptimit tĂ« PaaS, njĂ« zhvillues i ri mund tĂ« harxhojĂ« disa javĂ« pĂ«r t'u njohur me tĂ« gjitha mjetet e nevojshme pĂ«r tĂ« lancuar njĂ« mikroshĂ«rbim nĂ« prodhim: Kubernetes, Helm, â nĂ« veçoritĂ« tona tĂ« brendshme TeamCity, konfigurimin e lidhjes me bazat e tĂ« dhĂ«nave dhe ĐșĐ”Ńlarning nĂ« njĂ« mĂ«nyrĂ« tĂ« qĂ«ndrueshme etj. Tani kjo merr disa orĂ« â pĂ«r tĂ« lexuar quickstart dhe pĂ«r tĂ« ndĂ«rtuar vetĂ« shĂ«rbimin.
Kam bërë një prezantim mbi këtë temë për HighLoad++ 2018, mund ta shikoni dhe .
Një bonus për ata që lexuan deri në fund
Ne në Avito po organizojmë një trajnim të brendshëm për tre ditë për zhvillues nga , një ekspert në arkitekturën e mikroshërbimeve. Dëshirojmë të ofrojmë mundësinë e pjesëmarrjes në të për ndonjë nga lexuesit e këtij postimi. është publikuar programi i trajnimit.
Trajnimi do të zhvillohet nga 5 deri më 7 gusht në Moskë. Këto janë ditë pune, të cilat do të jenë plotësisht të angazhuara. Drekë dhe mësimi do të jenë në zyrën tonë, ndërsa rruga dhe akomodimi do të paguhen nga pjesëmarrësi i zgjedhur.
Aplikimi për pjesëmarrje mund të bëhet . Nga ju kërkohet një përgjigje në pyetjen se pse pikërisht ju duhet të vizitoni trajnimin dhe informacion se si mund të kontaktoheni. Përgjigjuni në anglisht, sepse Chris do të zgjedhë vetë pjesëmarrësin që do të marrë pjesë në trajnim.
Ne do të shpallim emrin e pjesëmarrësit të trajnimit si një përditësim të këtij postimi dhe në mediat sociale të Avito për zhvilluesit (AvitoTech në , , ) jo më vonë se 19 korrik.
Burimi: habr.com
