Tere! Minu nimi on Vadim Madison, ma juhin Avito System Platformi arendamist. Rohkem kui korra on räägitud, kuidas me ettevõttes liigume monoliitsest arhitektuurist mikroteenuste arhitektuurile. On aeg jagada, kuidas oleme oma infrastruktuuri muutnud, et saada mikroteenustest maksimumi ja vältida nendesse eksimist. Kuidas PaaS meid siin aitab, kuidas juurutamist lihtsustasime ja mikroteenuse loomist ühe klõpsuga vähendasime – loe edasi. Kõik, millest allpool kirjutan, pole Avitos täielikult rakendatud, osa sellest on see, kuidas me oma platvormi arendame.

(Ja selle artikli lõpus räägin võimalusest osaleda mikroteenuste arhitektuurieksperdi Chris Richardsoni kolmepäevasel seminaril).

Kuidas me mikroteenusteni jõudsime

Avito on üks suurimaid salastatud saite maailmas, sellel avaldatakse päevas üle 15 miljoni uue kuulutuse. Meie taustaprogramm võtab sekundis vastu üle 20 tuhande päringu. Meil on praegu mitusada mikroteenust.

Oleme mikroteenuste arhitektuuri ehitanud juba mitu aastat. Kuidas täpselt - meie kolleegid üksikasjalikult rääkinud meie rubriigis RIT++ 2017. CodeFestil 2017 (vt. video), selgitasid Sergey Orlov ja Mihhail Prokopchuk üksikasjalikult, miks vajasime mikroteenustele üleminekut ja millist rolli mängis siin Kubernetes. Noh, nüüd teeme kõik, et minimeerida sellisele arhitektuurile omaseid skaleerimiskulusid.

Esialgu me ei loonud ökosüsteemi, mis aitaks meil igakülgselt mikroteenuseid arendada ja käivitada. Nad lihtsalt kogusid mõistlikud avatud lähtekoodiga lahendused, käivitasid need kodus ja kutsusid arendaja nendega tegelema. Selle tulemusena läks ta kümnesse kohta (armatuurlauad, siseteenused), misjärel sai ta tugevamaks soovis koodi vanaviisi, monoliidis kärpida. Roheline värv allolevatel diagrammidel näitab, mida arendaja ühel või teisel viisil oma kätega teeb, ja kollane värv näitab automatiseerimist.

Nüüd luuakse PaaS CLI utiliidis uus teenus ühe käsuga ja uus andmebaas lisatakse veel kahe käsuga ja juurutatakse Stage'i.

Kuidas ületada "mikroteenuste killustatuse" ajastu

Monoliitse arhitektuuriga olid arendajad sunnitud toote muudatuste järjepidevuse huvides välja mõtlema, mis nende naabritega toimub. Uue arhitektuuri kallal töötades ei sõltu teenusekontekstid enam üksteisest.

Lisaks tuleb mikroteenuse arhitektuuri tõhusaks toimimiseks luua palju protsesse, nimelt:

• metsaraie;
• taotleda jälgimist (Jaeger);
• vigade koondamine (Sentry);
• olekud, sõnumid, sündmused Kubernetesist (sündmusvoo töötlemine);
• võistluspiirang / kaitselüliti (võite kasutada Hystrixit);
• teenuse ühenduvuse kontroll (kasutame Netrameshi);
• monitooring (Grafana);
• komplekteerimine (TeamCity);
• suhtlemine ja teavitamine (Slack, email);
• ülesannete jälgimine; (Jira)
• dokumentatsiooni koostamine.

Tagamaks, et süsteem ei kaotaks oma terviklikkust ja jääks skaleerimisel tõhusaks, mõtlesime Avito mikroteenuste korralduse ümber.

Kuidas me mikroteenuseid haldame

Järgnev aitab rakendada ühtset “parteipoliitikat” paljude Avito mikroteenuste hulgas:

• infrastruktuuri jagamine kihtideks;
• Platvormi kui teenuse (PaaS) kontseptsioon;
• jälgib kõike, mis mikroteenustega juhtub.

Infrastruktuuri abstraktsioonikihid hõlmavad kolme kihti. Lähme ülevalt alla.

A. Top – teenindusvõrk. Algul proovisime Istiot, kuid selgus, et see kasutab liiga palju ressursse, mis on meie mahtude jaoks liiga kallis. Seetõttu töötas arhitektuurimeeskonna vaneminsener Aleksander Lukjantšenko välja oma lahenduse - Netramesh (saadaval avatud lähtekoodiga), mida praegu tootmises kasutame ja mis kulutab kordades vähem ressursse kui Istio (aga ei tee kõike, millega Istio kiidelda saab).
B. Keskmine – Kubernetes. Me juurutame ja kasutame sellel mikroteenuseid.
C. Põhi – paljas metall. Me ei kasuta pilvi ega selliseid asju nagu OpenStack, vaid tugineme täielikult metallile.

Kõik kihid ühendab PaaS. Ja see platvorm koosneb omakorda kolmest osast.

I. Generaatorid, mida juhitakse CLI utiliidi kaudu. Just tema aitab arendajal luua mikroteenust õigel viisil ja minimaalse vaevaga.

II. Konsolideeritud koguja kõigi tööriistade juhtimine ühise armatuurlaua kaudu.

III. Säilitamine. Loob ühenduse ajakavadega, mis määravad automaatselt oluliste toimingute päästikud. Tänu sellisele süsteemile ei jää ükski ülesanne tegemata lihtsalt sellepärast, et keegi unustas Jiras ülesande seadistada. Kasutame selleks sisemist tööriista nimega Atlas.

Mikroteenuste juurutamine Avitos toimub ka ühe skeemi järgi, mis lihtsustab nende üle kontrolli igas arenduse ja väljalaske etapis.

Kuidas standardne mikroteenuste arendustoru töötab?

Üldiselt näeb mikroteenuste loomise ahel välja selline:

CLI-tõuke → Pidev integreerimine → Küpsetamine → Juurutamine → Kunstlikud testid → Kanaari testid → Pigistamise testimine → Tootmine → Hooldus.

Teeme selle täpselt selles järjekorras läbi.

CLI-tõuge

• Mikroteenuse loomine.
Nägime pikka aega vaeva, et õpetada igale arendajale mikroteenuseid tegema. See hõlmas üksikasjalike juhiste kirjutamist Confluence'is. Kuid skeemid muutusid ja neid täiendati. Tulemuseks on see, et teekonna alguses tekkis kitsaskoht: mikroteenuste käivitamine võttis palju rohkem aega ja sellegipoolest tekkis nende loomisel sageli probleeme.

Lõppkokkuvõttes koostasime lihtsa CLI utiliidi, mis automatiseerib mikroteenuse loomise põhitoimingud. Tegelikult asendab see esimest git-tõuget. Siin on, mida ta täpselt teeb.

— Loob teenuse malli järgi — samm-sammult, viisardi režiimis. Meil on Avito taustaprogrammi peamiste programmeerimiskeelte mallid: PHP, Golang ja Python.

- Üks käsk korraga juurutab konkreetses masinas kohaliku arenduskeskkonna - Minikube käivitatakse, Helmi diagrammid genereeritakse ja käivitatakse automaatselt kohalikes kubernetes.

— Ühendab vajaliku andmebaasi. Arendaja ei pea teadma IP-d, sisselogimist ega parooli, et pääseda juurde vajalikule andmebaasile – olgu see siis kohapeal, Stage'is või tootmises. Peale selle juurutatakse andmebaas koheselt tõrketaluvusega konfiguratsioonis ja tasakaalustatult.

— See teeb ise live-montaaži. Oletame, et arendaja parandas midagi mikroteenuses oma IDE kaudu. Utiliit näeb failisüsteemis muudatusi ja nende põhjal ehitab rakenduse uuesti (Golangi jaoks) ja taaskäivitab. PHP puhul saadame lihtsalt kuubis oleva kataloogi edasi ja seal saadakse "automaatselt" live-reload.

— genereerib automaatteste. Toorikute kujul, kuid kasutamiseks üsna sobiv.

• Mikroteenuste juurutamine.

Varem oli mikroteenuse juurutamine meie jaoks pisut vaevaline. Nõuti järgmist:

I. Dockerfile.

II. Konfig.
III. Helmi diagramm, mis ise on tülikas ja sisaldab:

— graafikud ise;
— mallid;
— konkreetsed väärtused, võttes arvesse erinevaid keskkondi.

Oleme Kubernetese manifestide ümbertöötamisega vaeva näinud, nii et need genereeritakse nüüd automaatselt. Kuid mis kõige tähtsam, nad lihtsustasid juurutamist kuni piirini. Nüüdsest on meil Dockerfile ja arendaja kirjutab kogu konfiguratsiooni ühte lühikesse app.toml faili.

Jah, ja rakenduses app.toml pole hetkekski midagi teha. Täpsustame, kus ja mitu teenuse eksemplari luua (arendusserveris, lavastuses, tootmises) ning näitame selle sõltuvused. Pange tähele, et [mootori] plokis on rea suurus = "väike". See on limiit, mis Kubernetese kaudu teenusele eraldatakse.

Seejärel genereeritakse konfiguratsioonist lähtuvalt automaatselt kõik vajalikud Helmi diagrammid ja luuakse ühendused andmebaasidega.

• Põhiline valideerimine. Sellised kontrollid on samuti automatiseeritud.
Vaja jälgida:
— kas on olemas Dockerfile;
— kas on olemas app.toml;
— kas dokumentatsioon on olemas?
— kas sõltuvus on korras?
— kas hoiatusreeglid on kehtestatud.
Viimase punktini: teenuse omanik määrab ise, milliseid tootemõõdikuid jälgida.

• Dokumentatsiooni koostamine.
Ikka probleemne valdkond. See tundub olevat kõige ilmsem, kuid samas on see ka “tihti unustatud” rekord ja seega ka haavatav lüli ahelas.
Iga mikroteenuse kohta on vajalik dokumentatsioon. See sisaldab järgmisi plokke.

I. Teenuse lühikirjeldus. Sõna otseses mõttes paar lauset selle kohta, mida see teeb ja miks seda vaja on.

II. Arhitektuuriskeemi link. Oluline on, et kiire pilguga oleks lihtne aru saada näiteks sellest, kas kasutate Redist vahemällu salvestamiseks või püsirežiimis peamise andmehoidlana. Praegu on Avitos see link Confluence'ile.

III. Runbook. Lühike juhend teenuse käivitamise ja selle haldamise keerukuse kohta.

IV. KKK, kus oleks hea ennetada probleeme, millega kolleegid võivad teenusega töötades kokku puutuda.

V. API lõpp-punktide kirjeldus. Kui te järsku sihtkohti ei täpsustanud, maksavad selle eest peaaegu kindlasti kolleegid, kelle mikroteenused on teie omaga seotud. Nüüd kasutame selleks Swaggerit ja meie lahendust nimega short.

VI. Sildid. Või markerid, mis näitavad, millisele tootele, funktsionaalsusele või ettevõtte struktuuriüksusele teenus kuulub. Need aitavad teil näiteks kiiresti aru saada, kas vähendate funktsioone, mille teie kolleegid nädal tagasi sama äriüksuse jaoks kasutusele võtsid.

VII. Teenuse omanik või omanikud. Enamikul juhtudel saab selle või need PaaS-i abil automaatselt kindlaks määrata, kuid ohutuse tagamiseks nõuame, et arendaja määraks need käsitsi.

Lõpuks on hea tava sarnaselt koodiülevaatusega dokumentatsiooni üle vaadata.

Pidev integreerimine

• Hoidlate ettevalmistamine.
• Konveieri loomine TeamCitys.
• Õiguste seadmine.
• Otsige teenuse omanikke. Siin on hübriidskeem - käsitsi märgistamine ja minimaalne automatiseerimine PaaS-ist. Täisautomaatne skeem ebaõnnestub, kui teenused suunatakse toe saamiseks teisele arendusmeeskonnale või näiteks kui teenusearendaja lahkub.
• Teenuse registreerimine Atlases (vt eespool). Kõigi oma omanike ja sõltuvustega.
• Migratsioonide kontrollimine. Kontrollime, kas mõni neist on potentsiaalselt ohtlik. Näiteks ühes neist avaneb muudatuste tabel või midagi muud, mis võib rikkuda andmeskeemi ühilduvuse teenuse erinevate versioonide vahel. Siis migreerimist ei teostata, vaid pannakse liitumisse – PaaS peab teenuse omanikule märku andma, kui selle kasutamine on ohutu.

Küpseta

Järgmine etapp on pakendamisteenused enne kasutuselevõttu.

• Rakenduse ehitamine. Klassika järgi - Dockeri pildil.
• Teenuse enda ja sellega seotud ressursside jaoks Helmi diagrammide loomine. Sealhulgas andmebaaside ja vahemälu jaoks. Need luuakse automaatselt vastavalt app.toml konfiguratsioonile, mis loodi CLI-tõukeetapil.
• Piletite loomine administraatoritele portide avamiseks (vajadusel).
• Üksuste testide käitamine ja koodi katvuse arvutamine. Kui koodi katvus on alla määratud läve, siis tõenäoliselt teenus kaugemale ei lähe - juurutamiseni. Kui see on vastuvõetava piiril, määratakse teenusele pessimismi koefitsient: kui indikaator aja jooksul ei parane, saab arendaja teate, et testide osas pole edusamme ( ja sellega tuleb midagi ette võtta).
• Mälu ja protsessori piirangute arvestamine. Peamiselt kirjutame mikroteenuseid Golangis ja käitame neid Kubernetes. Siit ka üks peensus, mis on seotud Golangi keele eripäraga: vaikimisi kasutatakse käivitamisel kõiki masina tuumasid, kui te ei määra selgelt muutujat GOMAXPROCS ja kui samas masinas käivitatakse mitu sellist teenust, siis need käivituvad. konkureerida ressursside pärast, segades üksteist. Allolevad graafikud näitavad, kuidas täitmisaeg muutub, kui käivitate rakendust vaidlusteta ja ressursside võidujooksu režiimis. (Graafikute allikad on siin).

Täitmisaeg, vähem on parem. Maksimaalne: 643 ms, minimaalne: 42 ms. Foto on klikitav.

Aeg operatsiooniks, vähem on parem. Maksimaalne: 14091 ns, minimaalne: 151 ns. Foto on klikitav.

Koostamise ettevalmistamise etapis saate selle muutuja selgesõnaliselt määrata või kasutada teeki automaxprocs Uberi meestelt.

Kasutusele võtta

• Konventsioonide kontrollimine. Enne hoolduskoostude tarnimist ettenähtud keskkonda peate kontrollima järgmist.
- API lõpp-punktid.
— API lõpp-punktide vastuste vastavus skeemile.
— logi formaat.
— teenuse päringute päiste seadistamine (praegu teeb seda netramesh)
— omaniku märgi määramine sündmuste siinile sõnumite saatmisel. See on vajalik teenuste ühenduvuse jälgimiseks kogu bussis. Siini saab saata nii idempotentseid andmeid, mis ei suurenda teenuste ühenduvust (mis on hea), kui ka äriandmeid, mis tugevdavad teenuste ühenduvust (mis on väga halb!). Ja hetkel, kui see ühenduvus muutub probleemiks, aitab mõista, kes bussi kirjutab ja loeb, teenuseid õigesti eraldada.

Avitos pole veel väga palju konventsioone, kuid nende bassein laieneb. Mida rohkem selliseid lepinguid on meeskonnale arusaadavas ja arusaadavas vormis saadaval, seda lihtsam on mikroteenuste vahelist järjepidevust säilitada.

Sünteetilised testid

• Suletud ahela testimine. Selleks kasutame nüüd avatud lähtekoodi Hoverfly.io. Esiteks salvestab see teenuse tegeliku koormuse, seejärel - lihtsalt suletud ahelas - emuleerib seda.

• stressitestid. Püüame viia kõik teenused optimaalselt toimima. Ja iga teenuse kõik versioonid peavad läbima koormustesti – nii saame aru teenuse praegusest toimivusest ja erinevusest sama teenuse eelmiste versioonidega. Kui pärast teenuse värskendust langes selle jõudlus poolteist korda, on see omanikele selge signaal: peate koodi süvenema ja olukorda parandama.
Kasutame kogutud andmeid näiteks automaatse skaleerimise korrektseks juurutamiseks ja kokkuvõttes üldiselt teenuse skaleeritavuse mõistmiseks.

Koormustestimise käigus kontrollime, kas ressursikulu vastab seatud piiridele. Ja keskendume eelkõige äärmustele.

a) Vaatame kogukoormust.
- Liiga väike - tõenäoliselt ei tööta midagi üldse, kui koormus langeb ootamatult mitu korda.
- Liiga suur – vajalik optimeerimine.

b) Vaatame piirväärtust RPS-i järgi.
Siin vaatleme praeguse ja eelmise versiooni erinevust ning kogukogust. Näiteks kui teenus toodab 100 rps, siis on see kas halvasti kirjutatud või on see selle eripära, kuid igal juhul on see põhjus teenust väga lähedalt vaadata.
Kui vastupidi, RPS-e on liiga palju, siis võib-olla on tegemist mingi veaga ja mõned lõpp-punktid on peatanud kasuliku koormuse täitmise ja mõni muu on lihtsalt käivitatud return true;

Kanaari testid

Pärast sünteetiliste testide läbimist testime mikroteenust väikese arvu kasutajate peal. Alustame ettevaatlikult, väikese osaga teenuse sihtrühmast – vähem kui 0,1%. Praeguses etapis on väga oluline, et monitooringus oleksid kaasatud õiged tehnilised ja tootemõõdikud, et need näitaksid probleemi võimalikult kiiresti teenuses. Kanaari testi minimaalne aeg on 5 minutit, põhiaeg 2 tundi. Keerukate teenuste puhul määrame aja käsitsi.
Analüüsime:
— keelepõhised mõõdikud, eelkõige php-fpm töötajad;
— vead Sentrys;
— vastuse staatused;
— täpne ja keskmine reageerimisaeg;
— latentsusaeg;
— töödeldud ja käsitlemata erandid;
— tootemõõdikud.

Pigistustestimine

Pigistamistestimist nimetatakse ka pigistamise testimiseks. Tehnika nimi tutvustati Netflixis. Selle olemus seisneb selles, et esmalt täidame ühe eksemplari reaalse liiklusega kuni tõrkepunktini ja seame sellega selle piiri. Seejärel lisame veel ühe eksemplari ja laadime selle paari - uuesti maksimaalselt; me näeme nende lage ja deltat esimese “pigistusega”. Ja nii ühendame ühe eksemplari korraga ja arvutame muutuste mustri.
Katseandmed liiguvad läbi “pigistamise” ka ühisesse mõõdikute andmebaasi, kus me kas rikastame nendega tehiskoormuse tulemusi või isegi asendame “sünteetika” nendega.

Tootmine

• Skaleerimine. Teenuse tootmisse viimisel jälgime selle skaleerimist. Meie kogemuse kohaselt on ainult protsessori indikaatorite jälgimine ebaefektiivne. Automaatne skaleerimine koos RPS-i võrdlusuuringuga puhtal kujul toimib, kuid ainult teatud teenuste puhul, näiteks võrgus voogesitus. Seega vaatame esmalt rakendusepõhiseid tootemõõdikuid.

Selle tulemusena analüüsime skaleerimisel:
- CPU ja RAM indikaatorid,
— järjekorras olevate taotluste arv,
- reaktsiooniaeg,
— kogutud ajaloolistel andmetel põhinev prognoos.

Teenuse skaleerimisel on oluline jälgida ka selle sõltuvusi, et me ei skaleeriks ahela esimest teenust ja need, millele see juurde pääseb, ebaõnnestuvad koormuse all. Kogu teenustekogumi jaoks vastuvõetava koormuse määramiseks vaatame „lähima” sõltuva teenuse ajaloolisi andmeid (põhineb protsessori ja RAM-i indikaatorite kombinatsioonil koos rakendusespetsiifiliste mõõdikutega) ja võrdleme neid ajalooliste andmetega. lähtestamisteenuse ja nii edasi kogu „sõltuvusahela” ulatuses, ülalt alla.

Teenindus

Pärast mikroteenuse kasutuselevõttu saame sellele kinnitada päästikud.

Siin on tüüpilised olukorrad, kus vallandajad ilmnevad.
— Tuvastati potentsiaalselt ohtlikud migratsioonid.
— Turvavärskendused on välja antud.
— Teenust ennast pole pikka aega uuendatud.
— Teenuse koormus on märgatavalt vähenenud või mõni selle tootemõõdik jääb tavapärasest väljapoole.
— Teenus ei vasta enam uutele platvorminõuetele.

Mõned päästikud vastutavad töö stabiilsuse eest, mõned - süsteemi hoolduse funktsioonina - näiteks pole mõnda teenust pikka aega juurutatud ja selle põhipilt ei läbinud enam turvakontrolli.

Armatuurlaud

Lühidalt öeldes on armatuurlaud kogu meie PaaS-i juhtpaneel.

• Üksainus teabepunkt teenuse kohta koos andmetega selle testi ulatuse, piltide arvu, tootmiskoopiate arvu, versioonide jne kohta.
• Tööriist andmete filtreerimiseks teenuste ja siltide järgi (äriüksustesse kuulumise markerid, toote funktsionaalsus jne)
• Tööriist jälgimise, logimise ja jälgimise infrastruktuuri tööriistadega integreerimiseks.
• Üks teeninduspunkti dokumentatsioon.
• Üks vaade kõikidele sündmustele teenuste lõikes.

Kogusummas

Enne PaaS-i kasutuselevõttu võiks uus arendaja kulutada mitu nädalat, et mõista kõiki tööriistu, mis on vajalikud mikroteenuse tootmises käivitamiseks: Kubernetes, Helm, meie sisemised TeamCity funktsioonid, andmebaaside ja vahemäludega tõrketaluvusega ühenduste loomine jne. Kiirjuhendi lugemiseks ja teenuse loomiseks kulub paar tundi.

Andsin sellel teemal aruande HighLoad++ 2018 jaoks, saate seda vaadata video и esitlus.

Boonuslugu neile, kes loevad lõpuni

Alates aastast korraldame meie Avitos arendajatele kolmepäevase sisekoolituse Chris Richardson, mikroteenuste arhitektuuri ekspert. Soovime anda võimaluse selles osaleda ühele selle postituse lugejatest. see on Koolitusprogramm on postitatud.

Koolitus toimub 5. – 7. augustini Moskvas. Need on tööpäevad, mis on täielikult hõivatud. Lõunasöök ja koolitus toimub meie kontoris ning valitud osaleja tasub reisi ja majutuse ise.

Osalemist saab taotleda sellel google vormil. Sinult – vastus küsimusele, miks on vaja koolitusel osaleda ja info kuidas Sinuga ühendust võtta. Vastake inglise keeles, sest Chris valib ise koolitusele mineva osaleja.
Koolitusel osaleja nime avaldame selle postituse värskenduses ja sotsiaalvõrgustikes Avito arendajatele (AvitoTech in Фейсбуке, Vkontakte, Twitter) hiljemalt 19. juuliks.

Allikas: www.habr.com