PĂ«rshĂ«ndetje! UnĂ« quhem Vadim Madison, drejtoj zhvillimin e System Platform tĂ« Avito. Kemi folur shpesh pĂ«r kalimin tonĂ« nga njĂ« arkitekturĂ« monolite nĂ« mikroshĂ«rbime. ĂshtĂ« koha tĂ« ndajmĂ« se si e transformuam infrastrukturĂ«n tonĂ« pĂ«r tĂ« shfrytĂ«zuar maksimumin nga mikroshĂ«rbimet dhe pĂ«r tĂ« mos humbur nĂ« to. Si na ndihmon kĂ«tu PaaS, si e thjeshtuam procesin e shpĂ«rndarjes dhe si e reduktuam krijimin e njĂ« mikroshĂ«rbimi nĂ« njĂ« klikim â lexoni mĂ« poshtĂ«. Jo gjithçka qĂ« shkruaj mĂ« poshtĂ« Ă«shtĂ« realizuar plotĂ«sisht nĂ« Avito, njĂ« pjesĂ« Ă«shtĂ« se si ecim pĂ«rpara me platformĂ«n tonĂ«.
(Dhe gjithashtu në fund të këtij artikulli do të flas për mundësinë për të marrë pjesë në një seminar tre-ditor nga eksperti i arkitekturës së mikroshërbimeve Chris Richardson).
Si erdhëm te mikroshërbimet
Avito është një prej platformave më të mëdha të klasifikuara në botë, ku publikohen mbi 15 milion njoftime të reja çdo ditë. Backend-i ynë pranon më shumë se 20 mijë kërkesa në sekondë. Tani kemi disa qindra mikroshërbime.
Ne e ndĂ«rtuam arkitekturĂ«n mikroshĂ«rbimore pĂ«r shumĂ« vite. Si saktĂ«sisht â kolegĂ«t tanĂ« tregojnĂ« nĂ« detaje nĂ« seksionin tonĂ« nĂ« RIT++ 2017. NĂ« CodeFest 2017 (shih ), Sergey Orlov dhe Mikhail Prokoptchuk shpjeguan hollĂ«sisht se pse kishim nevojĂ« tĂ« kalonim nĂ« mikroshĂ«rbime dhe çfarĂ« rol luajti Kubernetes kĂ«tu. Tani po bĂ«jmĂ« gjithçka pĂ«r tĂ« minimalizuar kostot e shkallĂ«zimit qĂ« lidhen me kĂ«tĂ« arkitekturĂ«.
Fillimisht ne nuk krijuam një ekosistem që do të na ndihmonte gjithpërfshirësisht në zhvillimin dhe nisjen e mikroshërbimeve. Thjesht mblodhëm zgjidhje open-source të favorshme, i nisëm ato dhe u ofruam zhvilluesit të merret me to. Si pasojë, ai shkonte në dhjetë vende (dashboard-e, shërbime të brendshme) për të forcuar dëshirën për të zhvilluar kodin në mënyrën e vjetër, në monolit. Ngjyra jeshile në diagramet më poshtë tregon atë që zhvilluesi e bën gjithsesi me duar, ndërsa ngjyra e verdhë tregon automatizimin.
Tani në utilitarin CLI të PaaS, një komandë krijon një shërbim të ri, dhe me dy komanda të tjera shtohet një bazë e re të dhënash dhe shpërndahet në Stage.
Si tĂ« kapĂ«rcesh epokĂ«n e âfragmentimit tĂ« mikroshĂ«rbimeveâ
Me arkitekturat monolitike, për shkak të koherencës së ndryshimeve në produkt, zhvilluesit u detyruan të kuptojnë se çfarë ndodhte me fqinjët. Me kalimin në arkitekturën e re, kontekstet e shërbimeve nuk varen më nga njëra-tjetra.
Përveç kësaj, që arkitektura mikro-shërbimeve të jetë efektive, kërkohet të vendosen shumë procese, pra:
âą regjistrimi;
âą gjurmimi i pyetjeve (Jaeger);
âą agregimi i gabimeve (Sentry);
⹠statuset, mesazhet, ngjarjet nga Kubernetes (Procesimi i Rrymës së Ngjarjeve);
⹠kufiri i garave / ndalësi i qarkullimit (mund të përdoret Hystrix);
⹠kontrolli i lidhjes së shërbimeve (ne përdorim Netramesh);
âą monitorimi (Grafana);
⹠ndërtimi (TeamCity);
âą komunikimi dhe njoftimi (Slack, email);
âą ndjekja e detyrave; (Jira)
⹠përgatitja e dokumentacionit.
Që ndryshe nga shkallëzimi, sistemi të mos humbasë integritetin dhe të mbetet efektiv, ne ripërcaktuam organizimin e punës së mikro-shërbimeve në Avito.
Si menaxhojmë mikro-shërbimet
TĂ« zbatohet njĂ« âpolitikĂ« e unifikuarâ pĂ«rmes shumĂ« mikro-shĂ«rbimeve tĂ« Avito-s ndihmon:
- ndarja e infrastrukturës në shtresa;
- koncepti Platform as a Service (PaaS);
- monitorimi i gjithçkaje që ndodh me mikro-shërbimet.
Nivelet e abstraksionit të infrastrukturës përfshijnë tri shtresa. Do të shkojmë nga lart në poshtë.
A. Shtresa e lartĂ« â service mesh. NĂ« fillim provuam Istio, por doli qĂ« pĂ«rdor shumĂ« burime, gjĂ« qĂ« nĂ« volumet tona Ă«shtĂ« tejet e shtrenjtĂ«. Prandaj, inxhinieri i lartĂ« nĂ« ekipin e arkitekturĂ«s, AleksandĂ«r Lukjanchenko, zhvilloi njĂ« zgjidhje tĂ« tijĂ«n â (e disponueshme nĂ« Open Source), qĂ« ne tani e pĂ«rdorim nĂ« prodhim dhe konsumon disa herĂ« mĂ« pak burime se Istio (por nuk bĂ«n gjithçka pĂ«r tĂ« cilat mund tĂ« mburret Istio).
B. Shtresa e mesme â Kubernetes. NĂ« tĂ« deploy dhe eksploatojmĂ« mikro-shĂ«rbimet.
C. Shtresa e poshtme â bare metal. Ne nuk pĂ«rdorim ĐŸĐ±Đ»Đ°ĐșĐ° dhe gjĂ«ra si OpenStack, por qĂ«ndrojmĂ« 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. Gjeneratorët, të menaxhuar përmes një utilitari CLI. Ajo ndihmon zhvilluesin të krijojë mikro-shërbimin në mënyrën e duhur dhe me minimumin e mundit.
II. Koleksioni përmbledhës me kontrollin e të gjitha veglave përmes një paneli të përbashkët.
III. Depoja. Përshtatet me planifikuesit që automatikisht vendosin trigere për veprime të rëndësishme. Falë një sistemi të tillë, asnjë detyrë nuk mbetet pa u përmbushur vetëm se dikush harroi të vendosë një detyrë në Jira. Ne për këtë përdorim një mjet të brendshëm të quajtur Atlas.
Realizimi i mikroshërbimeve në Avito gjithashtu bëhet sipas një skeme të vetme, e cila e thjeshton kontrollin mbi to në çdo fazë të zhvillimit dhe lëshimit.
Si funksionon një tubacion standard për zhvillimin e mikroshërbimit
Në formën e saj të përgjithshme, zinxhiri i krijimit të një mikroshërbimi duket kështu:
CLI-push â Integrim tĂ« vazhdueshĂ«m â Bake â Deployment â Testet artificiale â Testet Canary â Squeeze Testing â Prodhim â MirĂ«mbajtje.
Do të ecim përmes saj pikërisht në këtë rend.
CLI-push
⹠Krijimi i mikroshërbimit.
Ne u munduam shumë për të mësuar çdo zhvillues të bëjë mikroshërbime. Përfshirë, ne shkruam në Confluence udhëzime të detajuara. Por skemat shfaqeshin dhe plotësoheshin. Rezultati - u krijua një ngushticë në fillim të rrugës: për të nisur mikroshërbimet nevojitej shumë më tepër kohë sesa e lejuar, dhe gjithashtu probleme shpesh shfaqeshin gjatë krijimit të tyre.
Në fund të fundit, ne krijuam një mjet të thjeshtë CLI që automatizon hapat kryesorë në krijimin e mikroshërbimeve. Në fakt, ajo zëvendëson git push-in e parë. Këtu është saktësisht ajo që bën.
â Krijon njĂ« shĂ«rbim sipas njĂ« shablloni â hap pas hapi, nĂ« modin âwizardâ. Ne kemi shabllone pĂ«r gjuhĂ«t kryesore tĂ« programimit nĂ« backend tĂ« Avito: PHP, Golang dhe Python.
â Me njĂ« komandĂ« hap ambientin pĂ«r zhvillim lokal nĂ« makinĂ«n e caktuar â Minikube ngrihet, Helm charts automatikisht krijohen dhe fillojnĂ« nĂ« Kubernetes lokal.
â Lidhen bazat e tĂ« dhĂ«nave tĂ« nevojshme. Zhvilluesi nuk ka nevojĂ« tĂ« dijĂ« IP-nĂ«, emrin dhe fjalĂ«kalimin pĂ«r tĂ« aksesuar bazĂ«n e tij tĂ« nevojshme â qofshin lokale, nĂ« Stage, apo nĂ« prodhim. MĂ« shumĂ«, baza e tĂ« dhĂ«nave ngrihet menjĂ«herĂ« nĂ« njĂ« konfigurim tĂ« qĂ«ndrueshĂ«m dhe me balancim.
â NjĂ«jtĂ« zhvillon live build. Supozoni se zhvilluesi bĂ«ri disa ndryshime nĂ« mikroshĂ«rbim pĂ«rmes IDE-sĂ« sĂ« tij. Mjeti sheh ndryshimet nĂ« sistemin e Serverit dhe nĂ« pĂ«rputhje me to rikrijon aplikacionin (pĂ«r Golang) dhe e rindiz. PĂ«r PHP ne thjesht kalojmĂ« direktorinĂ« brenda kubit dhe aty live-reload ndodh âautomatikishtâ.
â Gjeneron testet automatike. NĂ« formĂ«n e shablloneve, por tĂ« pĂ«rshtatshme pĂ«r pĂ«rdorim.
⹠Dërgimi i mikroshërbimeve.
Mundësimi i mikroshërbimeve ka qenë më herët disi i lodhshëm. Patjetër kërkoheshin:
I. Dockerfile.
II. Konfigurimi.
III. Helm-chart, i cili vetë është i ngarkuar dhe përfshin:
â vetĂ« chart-et;
â shabllonet;
â vlerat specifike duke marrĂ« parasysh mjedise tĂ« ndryshme.
Kemi eliminuar dhimbjen e rishkrimit të manifestëve të Kubernetes, dhe tani gjenerohen automatikisht. Por kryesore, e kemi thjeshtuar deri në maksimum dërgimin. Që tani kemi një Dockerfile, dhe i gjithë konfigurimi shkruhet nga zhvilluesi në një skedë të vetme të shkurtër app.toml.
Edhe në vetë app.toml tani bëhet punë për një minutë. Shkruajmë se sa kopje shërbimi duhet ngritur (në serverin e dev, në staging, në prodhim), tregojmë varësitë e tij. Vini re rreshtin size = "small" në bllokun [engine]. Ky është kufiri që do t'i dedikohet shërbimit përmes Kubernetes.
Më pas, mbi bazën e konfigurimit, gjenerohen automatikisht të gjithë chart-et e nevojshme të Helm dhe krijohen lidhjet me bazat e të dhënave.
⹠Validimi bazik. Kontrollet e tilla gjithashtu janë automatizuar.
Duhet të ndjekim:
â a ka Dockerfile;
â a ka app.toml;
â a ka dokumentacion;
â a janĂ« nĂ« rregull varĂ«sitĂ«;
â a janĂ« vendosur rregullat e alarmeve.
Për pikën e fundit: pronari i shërbimit vetë tregon se cilat metrika produkti duhet të monitorohen.
âą PĂ«rgatitja e dokumentacionit.
Akoma një vend problematik. Duke qenë disi e dukshme, por po ashtu një pikë e "haruar" me rekord, dhe pra një lidhje e dobët e zinxhirit.
ĂshtĂ« e domosdoshme 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. Dosido vetëm disa proza për atë që bën dhe për çfarë i nevojitet.
II. Lidhja me diagramin e arkitekturĂ«s. ĂshtĂ« e rĂ«ndĂ«sishme qĂ«, me njĂ« shikim tĂ« shpejtĂ«, tĂ« kuptohet lehtĂ«, pĂ«r shembull, a po pĂ«rdorni Redis pĂ«r ruajtje tĂ« pĂ«rkohshme apo si njĂ« ruajtje kryesore tĂ« tĂ« dhĂ«nave nĂ« modin e qĂ«ndrueshĂ«m. NĂ« Avito, aktualisht kjo Ă«shtĂ« njĂ« lidhje me Confluence.
III. Runbook. Një udhëzues i shkurtër për fillimin e shërbimit dhe hollësitë mbi përdorimin e tij.
IV. FAQ, ku do ishte mirë të parashikoheshin problemet që mund të hasin kolegët tuaj gjatë punës me shërbimin.
V. Përshkrimi i endpoints për API. Nëse nuk keni specifikuar pikë të caktuar, kolegët tuaj, të cilët mikrosistemet e tyre e lidhin me të tuajin, do të paguajnë për këtë në mënyrë shumë të mundshme. Tani për këtë ne përdorim Swagger dhe zgjidhjen tonë të quajtur brief.
VI. Etiketat. Ose tregues që tregojnë se cilit produkt, funksionaliteti, ose një entitet struktural brenda kompanisë i përket shërbimi. Ndihmojnë të kuptoni shpejt, për shembull, nëse po zhvilloni funksionalitetin që kolegët tuaj e kanë lëshuar një javë më parë për të njëjtin njësi biznesi.
VII. Pronari ose pronarët e shërbimit. Në shumicën e rasteve, ai - ose ata - mund të identifikohen automatikisht përmes PaaS, por për siguri kërkojmë nga zhvilluesi që t'i tregojë ato manualisht.
Së fundi, një praktikë e mirë është që të realizohet një rishikim i dokumentacionit, në përputhje me rishikimin e kodit.
Continuous Integration
- PĂ«rgatitja e repozitoreve.
- Krijimi i një pipeline në TeamCity.
- Caktimi i të drejtave.
- Kërkimi i pronarëve të shërbimit. Këtu është një skemë hibride - etiketimi manual dhe automatizmi minimal nga PaaS. Një skemë plotësisht automatike dështone gjatë kalimit të shërbimeve në mbështetje tek një ekip tjetër zhvillimi ose, për shembull, nëse një zhvillues i shërbimit është larguar.
- Regjistrimi i shërbimit në Atlas (shih më lart). Me të gjithë pronarët e tij dhe varësitë.
- Kontrolli i migrimeve. Kontrollojmë nëse ndonjëra nga to është potencialisht e rrezikshme. Për shembull, në një prej tyre del në pah alter table ose diçka tjetër që mund të dëmtojë përputhshmërinë e skemës së të dhënave midis versioneve të ndryshme të shërbimit. Atëherë migrimi nuk kryhet, por vihet në abone - PaaS duhet të sinjalizojë pronarin e shërbimit kur të jetë e sigurt për ta aplikuar.
Bake
Faza tjetër - paketimi i shërbimeve përpara shpërndarjes.
- Ndërtimi i aplikacionit. Sipas klasikës - në një imazh Docker.
- Gjenerimi i Helm-chart për vetë shërbimin dhe burimet e lidhura me të. Përfshirë edhe për bazat e të dhënave dhe memorjen cache. Ato krijohen automatikisht në përputhje me konfigurimin app.toml që është formuar në fazën e CLI-push.
- Krijimi i bileta për administratorët për hapjen e porteve (kur është e nevojshme).
- Ekzekutimi i testeve tĂ« njĂ«sive dhe llogaritja e mbulimit tĂ« kodit. NĂ«se mbulimi i kodit Ă«shtĂ« nĂ«n vlerĂ«n e caktuar, atĂ«herĂ«, me siguri, shĂ«rbimi nuk do tĂ« kalojĂ« mĂ« tutje â nĂ« deploy. NĂ«se Ă«shtĂ« nĂ« kufirin e pranueshĂ«m, shĂ«rbimit do tâi caktohet njĂ« koeficient "pesimizues": atĂ«herĂ«, nĂ« mungesĂ« tĂ« pĂ«rmirĂ«simeve tĂ« treguesve me kalimin e kohĂ«s, zhvilluesi do tĂ« marrĂ« njĂ« njoftim pĂ«r mungesĂ«n e pĂ«rparimeve nĂ« lidhje me testet (dhe duhet tĂ« bĂ«jĂ« diçka lidhur me kĂ«tĂ«).
- Konsideratat për kufizimet e memories dhe CPU. Kryesisht, mikroshërbimet i shkruajmë në Golang dhe i ekzekutojmë ato në Kubernetes. Prej këtu, një nuancë, e lidhur me karakteristikën e gjuhës Golang: me default, në fillim aktivizohen të gjithë bërthamat në makinë, nëse nuk ndryshohet hapur variabla GOMAXPROCS, dhe kur në një makinë aktivizohen disa shërbime të tilla, ato fillojnë të konkurrojnë për burimet, duke penguar njëra-tjetrën. Në grafikët më poshtë tregohet se si ndryshon koha e ekzekutimit, nëse aplikohet aplikacioni pa konkurrencë dhe në mënyrën e garës për burime. (Burimet e grafikëve janë ruajtur) ).
Koha e ekzekutimit, mĂ« e vogĂ«l â mĂ« e mirĂ«. Maksimumi: 643ms, minimumi: 42ms. Fotografia Ă«shtĂ« klikueshme.
Koha pĂ«r operacion, mĂ« e vogĂ«l â mĂ« e mirĂ«. Maksimumi: 14091 ns, minimumi: 151 ns. Fotografia Ă«shtĂ« klikueshme.
Në fazën e përgatitjes së ndërtimit mund të caktohet kjo variablë shprehimisht ose mund të përdoret biblioteka nga çunat e Uber.
Deploy
⹠Kontrolli i konventave. Para se të filloni të dërgoni ndërtimet e shërbimit në ambientet e caktuara, duhet të kontrolloni këtë:
â API endpoints.
â PĂ«rputhshmĂ«ria e pĂ«rgjigjeve tĂ« API endpoints me skemĂ«n.
â Formati i logĂ«ve.
â Caktimi i titujve gjatĂ« kĂ«rkesave pĂ«r shĂ«rbimin (aktualisht kĂ«tĂ« e bĂ«n netramesh)
â Caktimi i markĂ«s sĂ« pronarit gjatĂ« dĂ«rgimit tĂ« mesazheve nĂ« autobus (event bus). Kjo Ă«shtĂ« e nevojshme pĂ«r tĂ« monitoruar lidhshmĂ«rinĂ« e shĂ«rbimeve nĂ«pĂ«rmjet autobusit. NĂ« autobus mund tĂ« dĂ«rgohen si tĂ« dhĂ«na idempotente, qĂ« nuk rrisin lidhshmĂ«rinĂ« e shĂ«rbimeve (çka Ă«shtĂ« mirĂ«), ashtu edhe tĂ« dhĂ«na biznesi, tĂ« cilat rrisin lidhshmĂ«rinĂ« e shĂ«rbimeve (çka Ă«shtĂ« shumĂ« keq!). Dhe nĂ« atĂ« moment, kur kjo lidhshmĂ«ri bĂ«het problem, kuptimi se kush shkruan dhe lexon autobusĂ«t, ndihmon nĂ« ndarjen e duhur tĂ« shĂ«rbimeve.
Derisa konventat në Avito nuk janë shumë, por grupi i tyre është në zgjerim. 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 konsistenca midis mikroshërbimeve.
Testet sintetike
âą Testimi nĂ« njĂ« kontur tĂ« mbyllur. PĂ«r kĂ«tĂ«, tani pĂ«rdorim open-source . SĂ« pari ai regjistron ngarkesĂ«n aktuale nĂ« shĂ«rbim, pastaj â duke e emuluar atĂ« nĂ« njĂ« cikĂ«l tĂ« mbyllur.
âą Testimi i ngarkesĂ«s. TĂ« gjithĂ« shĂ«rbimet pĂ«rpiqemi t'i çojmĂ« nĂ« performancĂ«n optimale. TĂ« gjitha versionet e çdo shĂ«rbimi duhet tĂ« kalojnĂ« nĂ« testimin e ngarkesĂ«s â kĂ«shtu mund tĂ« kuptojmĂ« performancĂ«n aktuale tĂ« shĂ«rbimit dhe ndryshimin nga versionet e mĂ«parshme tĂ« tĂ« njĂ«jtit shĂ«rbim. NĂ«se pas pĂ«rmirĂ«simit tĂ« shĂ«rbimit performanca e tij bie nĂ« mĂ«nyrĂ« drastike, Ă«shtĂ« njĂ« sinjal i qartĂ« pĂ«r pronarĂ«t: duhet tĂ« shqyrtojnĂ« kodin dhe tĂ« rregullojnĂ« situatĂ«n.
Të dhënat e mbledhura ne i përdorim, për shembull, për të realizuar saktë auto scaling dhe, në fund të fundit, për të kuptuar se sa mirë e lejon shërbimi përmasimin.
Gjatë testimit të ngarkesës kontrollojmë nëse konsumimi i burimeve përputhet me kufizimet e vendosura. Dhe fokusohemi kryesisht në ekstremet.
a) Shikojmë ngarkesën totale.
â NĂ«se Ă«shtĂ« shumĂ« e vogĂ«l â ndoshta diçka nuk funksionon fare, nĂ«se ngarkesa bie papritmas disa herĂ«.
â NĂ«se Ă«shtĂ« shumĂ« e madhe â kĂ«rkohet optimizim.
b) Shikojmë pezullimin sipas RPS.
KĂ«tu shikojmĂ« edhe ndryshimin midis versionit aktual dhe atij tĂ« mĂ«parshĂ«m, si dhe numrin e pĂ«rgjithshĂ«m. PĂ«r shembull, nĂ«se shĂ«rbimi jep 100 rps â atĂ«herĂ« ose Ă«shtĂ« shkruar dobĂ«t, ose Ă«shtĂ« specifik pĂ«r tĂ«, por nĂ« çdo rast Ă«shtĂ« njĂ« arsye pĂ«r tĂ« vĂ«zhguar me kujdes shĂ«rbimin.
Nëse RPS është shumë i lartë, ndoshta ndodhi ndonjë defekt dhe ndonjë nga endpoint-et ka ndaluar të kryejë ngarkesën e dobishme, por thjesht aktivizohet ndonjë kthe true;
Canary-teste
Pasi tĂ« kalohen testet sintetike, ne testojmĂ« funksionimin e mikro-shĂ«rbimit me njĂ« numĂ«r tĂ« vogĂ«l pĂ«rdoruesish. FillojmĂ« me kujdes, me njĂ« pjesĂ« tĂ« vogĂ«l tĂ« audiencĂ«s sĂ« parashikuar tĂ« shĂ«rbimit â mĂ« pak se 0,1%. NĂ« kĂ«tĂ« fazĂ« Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme qĂ« nĂ« monitorim tĂ« vendosen metrika teknike dhe produktive tĂ« sakta, pĂ«r t'i treguar sa mĂ« shpejt problemin nĂ« shĂ«rbim. Koha minimale e testit canary Ă«shtĂ« 5 minuta, ajo kryesore â 2 orĂ«. PĂ«r shĂ«rbimet e komplikuara e vendosim kohĂ«n nĂ« mĂ«nyrĂ« manuale.
Analizojmë:
â metrikat specifike pĂ«r gjuhĂ«n, nĂ« veçanti, punĂ«torĂ«t php-fpm;
â gabimet nĂ« Sentry;
â statuset e pĂ«rgjigjeve;
â koha e pĂ«rgjigjeve (response time), e saktĂ« dhe mesatare;
â latenca;
â pĂ«rjashtime, tĂ« trajtuara dhe tĂ« pa trajtuara;
â metrikat produktive.
Testimi i Squeeze
Testimi i Squeeze quhet gjithashtu testim pĂ«rmes «shtypjes». Emri i metodologjisĂ« u prezantua nga Netflix. Thelbi i saj Ă«shtĂ« qĂ« fillimisht ne mbushim njĂ« instancĂ« me trafik real deri nĂ« njĂ« pikĂ« dĂ«shtimi dhe nĂ« kĂ«tĂ« mĂ«nyrĂ« vendosim kufirin e saj. Pastaj shtojmĂ« njĂ« instancĂ« tĂ« tjetĂ«r dhe ngarkojmĂ« kĂ«tĂ« çift â pĂ«rsĂ«ri deri nĂ« maksimum; ne shohim tavanin e tyre dhe diferencĂ«n me «squeeze» e parĂ«. Dhe kĂ«shtu lidhim njĂ« instancĂ« pas tjetrĂ«s dhe llogarisim rregullat nĂ« ndryshime.
Të dhënat nga testet përmes «shtypjes» gjithashtu grumbullohen në një bazë të përgjithshme metrikash, ku ne ose pasurojmë rezultatet e ngarkesës artificiale, ose në përgjithësi i zëvendësojmë ato me «sintetikën».
Prodhimi
⹠Shkallëzimi. Gjatë nxjerrjes së shërbimit në prodhim, ne ndjekim se si shkallëzohet ai. Duke monitoruar vetëm treguesit e CPU, sipas përvojës sonë, nuk është efikase. Auto scaling me benchmark RPS funksionon në mënyrë të pastër, por vetëm për shërbime të veçanta, për shembull transmetimin online. Prandaj, ne shikojmë në radhë të parë në metrikat produktore specifike për aplikacionin.
Si rezultat, gjatë shkallëzimit analizojmë:
â treguesit e CPU dhe RAM,
â numrin e kĂ«rkesave nĂ« radhĂ«,
â kohĂ«n e pĂ«rgjigjes,
â parashikimin bazuar nĂ« tĂ« dhĂ«nat historike tĂ« akumuluara.
Gjatë shkallëzimit të shërbimit është gjithashtu e rëndësishme të monitorojmë 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 qaset bien nën ngarkesë. Për t'u vendosur një ngarkesë e pranueshme për të gjithë grupin e shërbimeve, ne shikojmë në të dhënat historike të shërbimit «më të afërt» të varur (në përputhje me kombinimin e treguesve të CPU dhe RAM së bashku me metrike specifike për aplikacionin) dhe i krahasojmë ato me të dhënat historike të shërbimit iniciues, dhe kështu me radhë në të gjithë «zinxhirin e varësive», nga lart poshtë.
Mirëmbajtja
Pasi mikrosherbimi është vënë në funksion, ne mund të vendosim triggera mbi të.
Ja situatat tipike në të cilat aktivizohen triggerat.
â JanĂ« zbuluar migrime potencialisht tĂ« rrezikshme.
â JanĂ« lĂ«shuar pĂ«rditĂ«sime tĂ« sigurimit.
â ShĂ«rbimi nuk Ă«shtĂ« pĂ«rditĂ«suar prej njĂ« kohe tĂ« gjatĂ«.
â Ka patur njĂ« rĂ«nie tĂ« konsiderueshme nĂ« ngarkesĂ«n mbi shĂ«rbimin ose ndonjĂ« prej treguesve tĂ« tij produktorĂ« del jashtĂ« normĂ«s.
â ShĂ«rbimi ka ndaluar pĂ«rputhshmĂ«rinĂ« me kĂ«rkesat e reja tĂ« platformĂ«s.
Disa pjesĂ« tĂ« triggereve janĂ« pĂ«rgjegjĂ«se pĂ«r stabilitetin e funksionimit, disa veprojnĂ« si funksion tĂ« mirĂ«mbajtjes sĂ« sistemit â pĂ«r shembull, ndonjĂ« shĂ«rbim qĂ« nuk Ă«shtĂ« deploy-uar prej kohĂ«sh dhe imazhi i tij bazĂ« ka ndaluar sĂ« kaluarit provimin e sigurisĂ«.
Dashboard
Nëse e themi shkurt, dashboard-i është paneli i kontrollit të gjithë PaaS tonë.
- Pika e vetme e informacionit për shërbimin, me të dhëna për mbulimin e tij me teste, numrin e imazheve të tij, numrin e kopjeve në prodhim, versione etj.
- Mjet filtrimi të dhënash sipas shërbimeve dhe labels (etiketave të përkatësisë në biznes, funksionalitetit të produktit etj.)
- Mjet integrimi me mjetet infrastrukturore për gjurmimin, regjistrimin, monitorimin.
- Pika e vetme e dokumentacionit për shërbimet.
- Pika e vetme e përmbledhjes së të gjitha ngjarjeve për shërbimet.
Përveç kësaj
Para implementimit tĂ« PaaS, njĂ« zhvillues i ri mund tĂ« kalonte disa javĂ« pĂ«r tĂ« kuptuar tĂ« gjitha mjetet e nevojshme pĂ«r tĂ« nisur njĂ« mikroshĂ«rbim nĂ« prodhim: Kubernetes, Helm, â nĂ« veçoritĂ« tona tĂ« brendshme TeamCity, konfigurimin e lidhjes me bazat e tĂ« dhĂ«nave dhe cache nĂ« njĂ« formĂ« tĂ« qĂ«ndrueshme etj. Tani kjo zgjat disa orĂ« â tĂ« lexosh quickstart dhe tĂ« krijosh vetĂ« shĂ«rbimin.
Kam mbajtur një prezantim mbi këtë temë për HighLoad++ 2018, mund ta shihni. dhe .
Boni-trek për ata që e lexuan deri në fund.
Ne në Avito organizojmë një trajnim të brendshëm tre ditor për zhvilluesit nga , ekspert i arkitekturës mikrosherbim. Duam ti japim mundësinë e pjesëmarrjes në të për kënd nga lexuesit e këtij posts. Programi i trajnimtit është publikuar.
Trajnimi do të zhvillohet nga 5 deri më 7 gusht në Moskë. Këto janë ditë të punës, të cilat do të jenë plotësisht të angazhuara. Dreka dhe mësimi do të zhvillohet në zyrën tonë, ndërsa rrugën dhe akomodimin e zgjedhur do ta paguajë vetë pjesëmarrësi.
Mund tĂ« aplikoni pĂ«r pjesĂ«marrje . Prej jush â njĂ« pĂ«rgjigje pĂ«r pytjen, pse pikĂ«risht ju duhet tĂ« vizitoni trajnimin dhe informacione se si tĂ« kontaktoni. PĂ«rgjigjuni nĂ« anglisht, sepse pjesĂ«marrĂ«si qĂ« do tĂ« marrĂ« pjesĂ« nĂ« trajnim, Chris do ta zgjedhĂ« vetĂ«.
Ne do të shpallim emrin e pjesëmarrësit në trajnim si një përditësim të këtij postimi dhe në rrjetet sociale të Avito për zhvilluesit (AvitoTech në , , ) jo më vonë se 19 korrik.
Burimi: habr.com
