Tere! Minu nimi on Vadim Madison, juhin Avito System Platformi arendust. Oleme korduvalt rääkinud, kuidas meie ettevõte liigub monoliitsest arhitektuurist mikroteenuste arhitektuuri. On aeg jagada, kuidas me oma infrastruktuuri ümber olen muutnud, et mikroteenustest maksimaalset kasu saada ja end neisse ära ei kaotada. Kuidas aitab meil siin PaaS, kuidas me oleme juurutamise lihtsamaks muutnud ja vähendanud mikroteenuse loomise ühe klikiga — loe edasi. Mitte kõik, millest ma allpool kirjutan, ei ole Avitos täies mahus teostatud; osa on see, kuidas me oma platvormi arendame.

(Ja veel, artikli lõpus räägin ma võimalusest osaleda kolme päeva seminaril mikroteenuste arhitektuuri eksperdi Chris Richardsona poolt).

Kuidas me mikroteenustele jõudsime

Avito on üks maailma suurimaid klassifitseeritud kuulutuste portaale, kus avaldatakse üle 15 miljoni uue kuulutuse päevas. Meie taga on rohkem kui 20 000 päringut sekundis. Praegu on meil mitusada mikroteenust.

Mikroteenuste arhitektuuri oleme välja arendanud juba mitu aastat. Kuidas täpselt — meie kolleegid räägivad detailselt rääkinud meie sessioonil RIT++ 2017. CodeFest 2017-l (vt. video), selgitasid Sergei Orlov ja Mihhail Prokopchuk põhjalikult, miks me üldse vajame üleminekut mikroteenustele ja millist rolli siin mängis Kubernetes. Nüüd teeme kõik, et minimeerida neid skaleerimise kulusid, mis sellisele arhitektuurile on iseloomulikud.

Alguses ei loonud me ökosüsteemi, mis aitaks meid laiapindsetes mikroteenuste arenduses ja juurutamises. Kogusime lihtsalt kokku head avatud lähtekoodiga lahendused, käivitasime need ja pakkusime arendajatele, et nad nendega tutvuksid. Lõppkokkuvõttes käis arendaja kümnes kohas (juhtpaneelid, siseteenused) ja kindlustas end sooviga kirjutada koodi vanamoodsalt, monoliidis. Allpool olevatel skeemidel on rohelise värviga tähistatud see, mida arendaja mingil viisil oma kätega teeb, kollase värviga — automatiseerimise.

Praegu PaaSi CLI-utilitys piisab ühe käsu kirjutamisest, et luua uus teenus, ja kahe käsuga lisatakse uus andmebaas ja juurutatakse Stage'isse.

Kuidas ületada "mikroteenuste killustatuse" ajastu

Monoliitsetehnikas, tootmisprotsessi muutuste ühtsuse nimel olid arendajad sunnitud aru saama, mis naabrite juures toimub. Uue arhitektuuri kasutamisel ei sõltu teenuste kontekstid enam üksteisest.

Lisaks on mikroteenuste arhitektuuri tõhusaks toimimiseks vajalik luua palju protsesse, nimelt:

• logimine;
• päringute jälgimine (Jaeger);
• vigade agregaator (Sentry);
• olekud, sõnumid, sündmused Kubernetesest (Event Stream Processing);
• race limit / circuit breaker (saab kasutada Hystrix);
• teenuste seotuse kontroll (kasutame Netramesh'i);
• monitooring (Grafana);
• kogumine (TeamCity);
• suhtlemine ja teavitamine (Slack, e-post);
• ülesannete jälgimine (Jira);
• dokumentatsiooni koostamine.

Kuna skaleerimise käigus ei tohi süsteem kaotada oma terviklikkust ega lakkata olemast tõhus, oleme ümber mõelnud mikroteenuste korralduse Avitos.

Kuidas me mikroteenustega toime tuleme

Ühtset „parteipoliitikat“ mitmete Avito mikroteenuste vahel hoiavad:

• infrastruktuuri kihistamine;
• Platform as a Service (PaaS) kontseptsioon;
• kogu, mis mikroteenustega juhtub, jälgimine.

Infrastruktuuri abstraktsioonitasemed hõlmavad kolme kihti. Liigume ülespoole madalamale.

A. Ülemine — service mesh. Alguses üritasime Istio't, kuid see kasutas liiga palju ressursse, mis meie mastaabiga osutus liiga kalliks. Seetõttu töötas arhitektuuri meeskonna vaneminsener Aleksandr Lukjančenko välja oma lahenduse — Netramesh (saadaval avatud koodina), mida me praegu tootmises kasutame ja mis tarbib mitmeid kordi vähem ressursse kui Istio (aga ei tee kõike, millega Istio uhkeldada saab).
B. Keskmine — Kubernetes. Sel korraldame ja kasutame mikroteenuseid.
C. Alumine — bare metal. Me ei kasuta pilvi ega OpenStacki, vaid toimime täielikult bare metal'il.

Kõiki kihte ühendab PaaS. Ja see platvorm koosneb omakorda kolmest osast.

I. Generaatorid,mida hallatakse CLI-utility kaudu. Just see aitab arendajal luua mikroteenuse õigesti ja minimaalse vaevaga.

II. Kogumiskollektor, mille kaudu kontrollitakse kõiki tööriistu ühiselt juhtpaneelist.

III. Ladustamine.. Integratsioon on võimalik planeerijatega, mis automaatselt seadistavad käivitajaid oluliste tegevuste jaoks. Selle süsteemi abil ei jää ükski ülesanne tähelepanuta lihtsalt seetõttu, et keegi unustas endale Jira'sse ülesande seada. Selleks kasutame sisemist tööriista nimega Atlas.

Mikroteenuste rakendamine Avitos toimub samuti ühtse skeemi järgi, mis lihtsustab nende üle kontrolli teostamist igas arenduse ja väljalaske etapis.

Kuidas on struktureeritud mikroteenuse arenduse tavaline voog.

Üldiselt näeb mikroteenuse loomise ahel välja järgmiselt:

CLI-push → Jätkuv Integratsioon → Küpsetamine → Rakendamine → Kunstlikud testid → Canary-testid → Squeeze Testimine → Tootmine → Üksikasjalik hooldus.

Liigume selle läbi täpselt sellises järjestuses.

CLI-push

• Mikroteenuse loomine.
Me oleme kaua vaeva näinud selle nimel, et õpetada iga arendajat mikroteenuseid looma. Sealhulgas oleme kirjutanud Confluence'is üksikasjalikke juhiseid. Kuid skeemid muutusid ja täiendusid. Tulemuseks – pudelikael tekkis teekonna alguses: mikroteenuste käivitamiseks kulus oluliselt rohkem aega, kui oleks tohtinud, ja nende loomisel tekkis sageli probleeme.

Lõpuks ehitasime välja lihtsa CLI-utility, mis automatiseerib peamised sammud mikroteenuse loomisel. Tegelikult asendab see esimest git push'i. Siin on, mida see täpselt teeb.

— Loob teenuse mallide alusel – samm-sammult, 'võluri' režiimis. Meil on mallid peamiste programmeerimiskeelte jaoks Avito tagaplaanis: PHP, Golang ja Python.

— Ühe käsuga seadistab kohaliku arenduse keskkonna konkreetsel masinal – Minikube tõuseb, Helm-graafikud genereeritakse ja käivitatakse automaatselt kohalikus k8s.

— Ühendab vajaliku andmebaasi. Arendajatel ei ole vaja teada IP-aadressi, kasutajanime ja parooli, et pääseda vajalikku andmebaasi – sõltumata sellest, kas see on kohalik, lavaline või tootmises. Lisaks seotakse andmebaas kohe talitlushäirete kindel ja koormuse jaotamisega.

— Täidab ise live-kogumise. Oletame, et arendaja korrigeeris midagi mikroteenuses oma IDE's. Tööriist tuvastab muudatused failisüsteemis ja nende alusel koostab rakenduse uuesti (Golang jaoks) ja käivitab selle. PHP puhul edastame lihtsalt kausta kubisse ja seal toimub live-reload ‘automaatselt’.

— Genereerib automaatse testimise. Kuigi need on vaid mallid, on need siiski kasutamiseks täiesti sobivad.

• Mikroteenuse juurutamine.

Mikroteenuse juurutamine oli varem veidi piinav. Selleks, et see toimiks, nõudis see kohustuslikult:

I. Dockerfile.

II. Konfiguratsioon.
III. Helm-chart, mis on iseenesest mahukas ja sisaldab:

— chart'id;
— mallid;
— spetsiifilised väärtused erinevate keskkondade jaoks.

Oleme vabanenud Kubernetes'e manifesteerimise vaevast ja need genereeritakse nüüd automaatselt. Kuid kõige tähtsam on, et oleme juurutamist oluliselt lihtsustanud. Nüüd on meil Dockerfile ja kogu konfiguratsioon, mida arendaja peab kirjutama, on ühes lühikeses failis app.toml.

Ja isegi app.toml-is on nüüd tegemist minutiga. Kirjutame, kui palju teenuse koopiaid tõsta (dev-serveris, stagingus, tootmises) ja määrame selle sõltuvused. Pange tähele rida size = "small" plokis [engine]. See on piirang, mis antakse teenusele Kubernetes'e kaudu.

Seejärel, lähtudes konfiguratsioonist, genereeritakse automaatselt kõik vajalikud Helm-charti ja luuakse ühendused andmebaasidega.

• Põhi valideerimine. Sellised kontrollimised on samuti automatiseeritud.
On vaja jälgida:
— kas Dockerfile on olemas;
— kas app.toml on olemas;
— kas dokumentatsioon on olemas;
— kas sõltuvused on korras;
— kas alert-reeglid on seatud.
Viimase punkti kohta: teenuse omanik määrab, milliseid toote mõõdikuid jälgida.

• Dokumentatsiooni ettevalmistamine.
See on endiselt probleemne koht. Tundub, et see on kõige ilmsem, kuid samas ka rekordiliselt 'tihti unustatav', mis tähendab, et see on nõrk link ahelas.
Oluline on, et dokumentatsioon oleks iga mikroteenuse jaoks. See sisaldab järgmisi osasid.

I. Teenuse lühikirjeldus. Üksnes paar lauset selle kohta, mida see teeb ja milleks see vajalik on.

II. Link arhitektuuri diagrammile. Oluline on, et pilgu heites oleks lihtne mõista, kas kasutate Redis't vahetuks või peamiseks andmehoidmiseks püsivas režiimis. Avitos on see endiselt link Confluence'i.

III. Runbook. Lühike juhend teenuse käivitamise ja selle käsitsemise nüansside kohta.

IV. KKK, kus on hea ennetada probleeme, millega teie kolleegid teenusega töötades silmitsi võivad seista.

V. API lõpp-punktide kirjeldus. Kui te ei ole sihtkohti määranud, peavad selle eest peaaegu kindlasti maksma kolleegid, kelle mikroteenused on teie omadega seotud. Praegu kasutame selleks Swaggerit ja meie lahendust nimega brief.

VI. Silte. Või märgid, mis näitavad, millise toote, funktsionaalsuse või ettevõtte struktuuriüksusega teenus on seotud. Need aitavad kiiresti aru saada, näiteks, kas te ei tööta välja funktsionaalsust, mille teie kolleegid nädal tagasi samale äriüksusele toimetasid.

VII. Teenuse omanik või omanikud. Enamikul juhtudel on PaaS-i abil seda võimalik automaatselt määrata, kuid igaks juhuks nõuame arendajalt nende käsitsi määramist.

Lõpuks on hea praktika läbi viia dokumentatsiooni ülevaatus, sarnaselt koodi ülevaatusele.

Continuous Integration

• Repo valmistamine.
• Pipeline'i loomine TeamCity-s.
• Õiguste määramine.
• Teenuse omanike leidmine. Siin on hübriidskeem - käsitsi märgistamine ja minimaalne automatiseerimine PaaS-ilt. Täiesti automaatne skeem ebaõnnestub teenuste ülemisel toe andmisele teisele arendustiimile või kui näiteks teenuse arendaja lahkub.
• Teenuse registreerimine Atlas'is (vt eespool). Kõigi selle omanike ja sõltuvustega.
• Migratsioonide kontrollimine. Kontrollime, kas nende seas on potentsiaalselt ohtlikke. Näiteks, kui ühes neist ilmneb alter table või midagi muud, mis võib rikkuda andmeskeemide ühilduvust eri teenuse versioonide vahel. Sel juhul migratsiooni ei tehta, vaid see pannakse tellimisse - PaaS peab signaalima teenuse omanikule, kui on ohutu see rakendada.

Bake

Järgmine etapp on teenuste pakkimine enne juurutamist.

• Rakenduse koostamine. Klassikaliselt - Docker-imagiks.
• Helm-chartide genereerimine teenuse ja sellega seotud ressursside jaoks. Sealhulgas andmebaaside ja vahemälu jaoks. Need genereeritakse automaatselt vastavalt sellele konfigureerimisele app.toml, mis moodustati CLI-push'i etapis.
• Pileti loomineadministraatoritele portide avamiseks (kui see on vajalik).
• Üksustestide läbiviimine ja koodi katvuse arvestamine. Kui koodi katvus jääb alla määratud läveväärtuse, ei pruugi teenus tõenäoliselt edaspidi deploy'i läbida. Kui see on lubatud piiril, antakse teenusele «pessimistlik» koefitsiend, mis tähendab, et aja jooksul, kui näitaja ei parane, saab arendaja teate, et testimise osas pole edusamme (ja midagi tuleks sellega teha).
• Mälu ja CPU piirangute arvestamine. Peamiselt kirjutame mikroteenuseid Golangi keeles ja käivitame neid Kuberneteses. Sealt tuleneb üks nüanss, mis on seotud Golangi keele omadustega: vaikimisi kasutatakse masina kõik tuumad, kui muutujat GOMAXPROCS selgelt ei seadistata, ja kui ühel masinal käivitatakse mitu sellist teenust, hakkavad nad omavahel ressursse konkureerima, takistades üksteist. Allolevates graafikutes on näidatud, kuidas täitmisaja muutumine sõltub rakenduse käivitamisest ilma konkurentsita ja ressursside võistlusrežiimis. (Graafikute allikakoodid asuvad siin).

Täitmisaeg, vähem on parem. Maksimum: 643ms, miinimum: 42ms. Foto on klikitav.

Tegevuse aeg, vähem on parem. Maksimum: 14091 ns, miinimum: 151 ns. Foto on klikitav.

Kogumise ettevalmistamise etapis saab seda muutujat selgelt seada või kasutada raamatukogu automaxprocs Uberi meeskonnalt.

Käivitamine

• Konventsioonide kontrollimine. Enne, kui alustame teenuse koguste kohaletoimetamist planeeritud keskkondadesse, tuleb kontrollida järgmist:
— API lõpp-punktid.
— API lõpp-punktide vastuste vastavus skeemile.
— Logide formaat.
— Pealkirjade seadmine teenusele esitatavates päringutes (hetkel teostab seda netramesh)
— Omaniku märgi seadmine sõnumite saatmisel bussile (event bus). See on vajalik teenuste seotuse jälgimiseks bussi kaudu. Bussile saab saata nii idempotentseid andmeid, mis ei suurenda teenuste seotust (mis on hea), kui ka ärilisi andmeid, mis seotust suurendavad (mis on väga halb!). Ja hetkel, kui see seotus muutub probleemiks, aitab arusaam sellest, kes kirjutab ja loeb bussi, teenuseid õigesti jagada.

Praegu ei ole Avitos konventsioone eriti palju, kuid nende hulk suureneb. Mida rohkem selliseid kokkuleppeid on tiimi arusaadavas ja mugavas vormis, seda lihtsam on säilitada laste teenuste vahel.

Sünteetilised testid

• Testimine suletud kontuuris. Selle jaoks kasutame praegu avatud lähtekoodiga Hoverfly.ioEsiteks salvestab ta teenuse reaalse koormuse, seejärel simulatsioonib seda suletud ringis.

• Koormustestimine. Püüame kõik teenused viia optimaalsele jõudlusele. Ja kõikide teenuse versioonide peavad läbima koormustestimise — nii saame aru teenuse hetkejõudlusest ja erinevusest selle eelnevate versioonidega. Kui teenuse jõudlus pärast uuendust kukub poole võrra, on see selge signaal selle omanikele: tuleb süveneda koodi ja olukorraga tegeleda.
Kogutud andmete põhjal näiteks lähtume, et korralikult ellu viia auto skaleerimine ja lõpuks üldiselt mõista, kui hästi teenus skaleerub.

Koormustestimise käigus kontrollime, kas ressursikasutuse tase vastab seatud piirangutele. Keskendume eelkõige äärmuslikele olukordadele.

a) Vaatame üldist koormust.
— Kui koormus on liiga madal, ei toimi tõenäoliselt miski, kui koormus ühtäkki langeb mitu korda.
— Kui koormus on liiga suur, on vajalik optimeerimine.

b) Vaatame RPSi piiri.
Siin vaatame nii praeguse versiooni ja eelneva vahet ning üldist arvu. Näiteks, kui teenus annab 100 rps — siis on see kas halvasti kirjutatud või on see tema eripära, aga igal juhul on see põhjus, miks teenusele väga tähelepanelikult läheneda.
Kui RPS on aga liiga kõrge, siis võib-olla on mingi viga ja mõni lõpp-punkt on lõpetanud kasuliku koormuse täitmise ja käivitub lihtsalt mingil kujul. return true;

Canary-testid

Pärast sünteetiliste testide läbimist katsetame mikroteenuse tööd väikese kasutajate arvuga. Alustame ettevaatlikult, väga väikese osaga teenuse eeldatavast publikust — vähem kui 0,1%. Sel etapil on väga oluline, et jälgimises oleksid õiged tehnilised ja toote-mõõdikud, et need võimalikult kiiresti näitaksid teenuse probleemi. Minimene canary-testi aeg on 5 minutit, peamine — 2 tundi. Tasakaalustatud teenuste puhul seame aja käsitsi.
Analüütime:
— keeletehnilised mõõdikud, eelkõige php-fpm töötajad;
— vead Sentrys;
— vastuste olekud;
— vastuste aeg (response time), täpne ja keskmine;
— latentsus;
— töödeldud ja töötlemata erandid;
— tootemõõdikud.

Squeeze Testing

Squeeze-teste nimetatakse ka "väljatõuketestimiseks". Meetodi nimetus ilmus Netflixis. Selle olemus on see, et esmalt täidame reaalse liiklusega ühe instantsi kuni rikkeolukorrani ja sel viisil kindlaks määrame selle piiri. Seejärel lisame veel ühe instantsi ja koormame neid koos - uuesti maksimaalselt; näeme nende lae ja erinevust esimese "squeeze'i" vahel. Nii liidame ühe instantsi korraga ja arvutame muutuste seaduspärasuse.
Andmed "väljatõuketestimise" kohta kogunevad samuti üldisesse meetrikate baasi, kus me rikastame nendega neid kunstlikke koormusi, või asendame nendega "sünteetika" täielikult.

Tootmine

• Skaalautumine. Teenuse tootmisse viies jälgime, kuidas see skaleerub. Ainult CPU näitajaid jälgida ei ole meie kogemuste põhjal efektiivne. Auto scaling koos RPS benchmark'iga puhtal kujul töötab, kuid ainult eriteenuste jaoks, näiteks veebivoo teenuse jaoks. Seetõttu vaatame esmalt rakendusele iseloomulikke tootenäitajaid.

Kokkuvõttes analüüsime skaleerimise käigus:
— CPU ja RAM näitajaid,
— järjekorras olevate päringute arvu,
— reageerimisaega,
— prognoosi, mis põhineb akumuleeritud ajaloolistel andmetel.

Teenuse skaleerimise ajal on samuti oluline jälgida selle sõltuvusi, et mitte juhtuda nii, et skaleerime esimest teenust ahelas, samal ajal kui need, millele see tugineb, kukuvad koormuse all. Vastuvõetava koormuse määramiseks kogu teenuste grupile vaatame ajaloolisi andmeid "lähedasest" sõltuvast teenusest (kombineeritud CPU ja RAM näitajate ning rakenduse spetsiifiliste näitajate järgi) ja seome need algse teenuse ajalooliste andmete, ja nii edasi kogu "sõltuvuste ahelas", ülevalt alla.

Hooldus

Pärast mikroteenuse kasutusele võtmist saame sellele siduda käivitajaid.

Siin on tüüpilised olukorrad, kus käivitajad aktiveeruvad.
— Tuletati potentsiaalselt ohtlikud migratsioonid.
— Turvauuendusi on välja lastud.
— Teenust pole pikka aega uuendatud.
— Teenuse koormus on oluliselt vähenenud või mõni tema tootenäitajatest ületab normi.
— Teenus ei vasta enam platvormi uutele nõuetele.

Mõned trigerid vastutavad süsteemi stabiilsuse eest, teised - nagu süsteemi hooldusfunktsioon - näiteks kui mõni teenus pole pikka aega välja lastud ja selle baaspilt enam turvaskanke ei läbi.

Armatuurlaud

Lühidalt öeldes on juhtpaneel meie PaaSi juhtimiskeskus.

• Üksnes teave teenuse kohta, sealhulgas testimise katvuse, selle piltide arvu, tootmiseksemplaride arvu, versioonide jne andmed.
• Andmete filtreerimise tööriist teenuste ja labels (äriküsimuste, toote funktsionaalsuse jne) järgi.
• Integreerimise tööriist infrastruktuuri tööriistadega jälgimise, logimise ja monitooringu jaoks.
• Üksnes teenuste dokumentatsiooni koht.
• Üksnes teenuste sündmuste ülevaate koht.

Kokkuvõttes

Pärast PaaSi rakendamist võis uus arendaja kulutada mitu nädalat, et mõista kõiki tööriistu, mis olid vajalikud mikroteenuse tootmisse toomiseks: Kubernetes, Helm - meie sisemiste omaduste, TeamCity, andmebaaside ja vahemälude usaldusväärse ühenduse konfigureerimine jne. Nüüd kulub selleks paar tundi - lugeda kiire alguse juhend ja luua ise teenus.

Ma tegin sellest teemast ettekande HighLoad++ 2018, seda saab vaadata. video ja esitlust.

Boonusloend neile, kes on lõpuni lugenud.

Meie Avitos korraldame arendajatele kolme päeva jooksul toimuva sisekoolituse. Kris Richardsonilt, mikroteenuste arhitektuuri eksperdilt. Soovime pakkuda kellegile sellest postitusest osalemisvõimalust. Siin Koolituse programmi on välja pandud.

Koolitus toimub 5.-7. august Moskvas. Need on tööpäevad, mis on täielikult hõivatud. Lõuna ja koolitus toimuvad meie kontoris, kuid valitud osaleja maksab enda transpordi ja majutuse ise.

Osalemiseks saate taotluse esitada selles Google'i vormis.. Teilt oodatakse vastust küsimusele, miks just teile on vaja koolitusele tulla, ja teavet, kuidas teiega ühendust võtta. Vastake inglise keeles, sest valitud osalejat valib Kris ise.
Teatame koolituse osaleja nime selle postituse uuendusega ja Avito arendajatele mõeldud sotsiaalmeedias (AvitoTech Facebookis Facebookis, Vkontakte, Twitteris) hiljemalt 19. juuliks.

Allikas: habr.com