Tere! Mina olen Vadim Madison, ma juhin Avito System Platform arendust. Meie üleminek monoliitsest arhitektuurist mikroteenuseni on olnud tihti jutuks. On aeg jagada, kuidas me oma infrastruktuuri ümber kujundasime, et mikroteenustest maksimaalset kasu saada ja samas end neis ei kaotada. Kuidas PaaS meile siin abiks on, kuidas me lihtsustasime deploy'st ja vähendasime mikroteenuse loomise ühe kliki peale — loe edasi. Mitte kõik, millest ma allpool räägin, ei ole Avitos täielikult rakendatud, osa on see, kuidas me oma platvormi arendame.

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

Kuidas me mikroteenustele jõudsime

Avito on üks suurimaid klassifitseeritud kuulutuste saite maailmas, kus iga päev avaldatakse üle 15 miljoni uue kuulutuse. Meie tagaplaan käsitleb üle 20 000 päringu sekundis. Praegu on meil mitusada mikroteenust.

Mikroteenuste arhitektuuri oleme loonud juba mitu aastat. Kuidas täpselt — meie kolleegid räägivad detailidest reported meie osas RIT++ 2017. CodeFest 2017-l (vt. video), Sergei Orlov ja Mihhail Prokoptšuk selgitasid üksikasjalikult, miks me üldse vajame üleminekut mikroteenustele ja millist rolli siinkohal mängis Kubernetes. Nüüd teeme kõik endast oleneva, et minimeerida neid skalaarimise kulusid, mis on sellise arhitektuuri puhul iseloomulikud.

Alguses ei loonud me ökosüsteemi, mis aitaks meid laialdaselt mikroteenuste arendamisel ja käivitamisel. Kogusime lihtsalt kokku mõistlikud avatud lahendused, käivitasime need ja pakkusime arendajale võimalust nendega tutvuda. Tulemuseks oli see, et arendaja käis kümnes kohas (juhtpaneelid, siseteenused), mille tulemusena muutus tema soov vanamoodi, monoliidi põhjal koodi kirjutada, kindlamaks. Allolevates skeemides on rohelisega märgitud, mida arendaja igal juhul enda kätega teeb, kollasega – automatiseerimine.

Praegu käivitatakse PaaS CLI-utiliidil uue teenuse loomine ühe käsuga ja kaht käsuga lisatakse uus andmebaas ning paigaldatakse etappi.

Kuidas ületada «mikroteenuste killustatuse» ajastu

Monoliitse arhitektuuri puhul pidid arendajad tagama toodete muutuste järjepidevuse ning tegelema sellega, mis toimub naabrite juures. Uue arhitektuuri rakendamisel on teenuste kontekstid üksteisest enam sõltumatud.

Lisaks, et mikroteenuste arhitektuur oleks tõhus, tuleb luua mitmeid protsesse, nimelt:

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

Kuna süsteem peab skaleerimise käigus säilitama terviklikkuse ja jääma tõhusaks, oleme ümber mõelnud mikroteenuste korralduse Avitos.

Kuidas me mikroteenustega hakkama saame

Ühtse 'parteipoliitika' rakendamine Avito mitmete mikroteenuste vahel toimub:

• infrastruktuuri jagamine taseteks;
• Platform as a Service (PaaS) kontseptsioon;
• kõik, mis mikroteenustega juhtub, jälgimine.

Infrastruktuuri abstraktsiooni tasemed hõlmavad kolme kihti. Alustame ülespoole liikumisest.

A. Ülemine — service mesh. Alguses proovisime Istio, kuid selgus, et see kasutab liiga palju ressursse, mis muutub meie suuruste juures liialt kulukaks. Seetõttu töötas arhitektuuri meeskonna vaneminsener Aleksandr Lukjančenko välja oma lahenduse — Netramesh (avatud allikaga), mida me praegu tootmises kasutame ja mis tarbib mitu korda vähem ressursse kui Istio (kuigi ei tee kõike, millega Istio uhkustab).
B. Keskmine — Kubernetes. Sellel põhineb meie mikroteenuste juurutamine ja haldamine.
C. Alumine — bare metal. Me ei kasuta pilvi ega selliseid asju nagu OpenStack, vaid oleme täielikult bare metal'i peal.

Kõik kihid ühendatakse PaaS-iga. Ja see platvorm koosneb omakorda kolmest osast.

I. Generaatorid, mida juhitakse CLI-tööriista kaudu. Just see aitab arendajal luua mikroteenuse õigesti ja minimaalse vaevaga.

II. Kokkuvõtte koguja kõikide tööriistade juhtimisega läbi ühise armatuurlaua.

III. Andmehoidla. Ühendub planeerijatega, mis auto­maatiliselt käivitavad triggereid oluliste tegevuste jaoks. Sellise süsteemi tõttu ei jää ükski ülesanne täitmata lihtsalt seetõttu, et keegi unustas endale Jira's ülesande määrata. Selleks kasutame sisemist tööriista nimega Atlas.

Mikroteenuste rakendamine Avitos toimub samuti ühtse skeemi alusel, mis lihtsustab nende kontrollimist igas arendus- ja väljalaskestaadiumis.

Kuidas on üles ehitatud mikroteenuse arenduse standardne konveier

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

CLI-push → Jätkuv integreerimine → Küpsetamine → Paigaldamine → Kunstlikud testid → Canary-testid → Squeeze katsetamine → Tootmine → Hooldus.

Käime selle läbi just sellises järjestuses.

CLI-push

• Mikroteenuse loomine.
Oleme pikka aega vaeva näinud, et õpetada igat arendajat mikroteenuseid tegema. Sealhulgas oleme kirjutanud Confluence'i põhjalikke juhiseid. Kuid skeemid muutusid ja täienesid. Tulemuseks oli pudelikael teekonna alguses: mikroteenuste käivitamiseks kulus aega palju rohkem, kui oli lubatud, ja selle loomise käigus tekkis sageli probleeme.

Lõpuks lõime lihtsa CLI-tööriista, mis automatiseerib mikroteenuse loomise põhietapid. Tegelikult asendab see esimest git push'i. Siin on, mida täpselt see teeb.

— Loob teenuse mallide põhjal — samm-sammult, 'wizard' režiimis. Meil on mallid peamiste tagapoolsete programmeerimiskeelte jaoks, nagu PHP, Golang ja Python.

— Ühe käsuga seadistab kohaliku arenduskeskkonna konkreetsel masinal — tõuseb Minikube, Helm'i graafikud genereeritakse ja käivitatakse automaatselt kohalikus kubernetes'e keskkonnas.

— Ühendab vajaliku andmebaasi. Arendajal pole vaja teada IP-aadressi, kasutajanime ega parooli, et pääseda vajaliku andmebaasi juurde — olgu see siis kohalik, etapis või tootmises. Andmebaas seadistatakse kohe ka kõrge töökindlusega konfiguratsioonis ja koormuse tasakaalustamisega.

— Teeb live-kogumise iseseisvalt. Oletame, et arendaja on oma IDE kaudu mikroteenuses midagi muutnud. Tööriist tuvastab failisüsteemis muudatused ja nende põhjal koondab rakenduse (Golang'i jaoks) ja käivitab selle uuesti. PHP puhul edastame lihtsalt katalooge kubusse ja seal live-reload toimub 'automaatiliselt'.

— Generoib automatiseeritud teste. Need on kujundusmaterjalid, kuid täiesti kasutatavad.

• Mikroteenuse juurutamine.

Mikroteenuse juurutamine oli varem üsna vaevarikas. Kohustuslikud nõuded olid:

I. Dockerfile.

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

— chart'id;
— mallid;
— spetsiifilised väärtused, arvestades erinevaid keskkondi.

Oleme vabanenud Kubernetes'i manifestide muutmise vaevast, nüüd genereeritakse need automaatselt. Kuid kõige olulisem on see, et oleme juurutamise äärmiselt lihtsaks teinud. Nüüd on meil Dockerfile, ja kogu konfigureerimise põhikirjeldust kirjutab arendaja ühte ainsasse lühikesse faili app.toml.

Jah, ja isegi app.toml-is on nüüd asjad hetkega korda tehtud. Määrame, kui palju teenuse koopiad tõsta (dev-serveris, staging'is, tootmises) ja näitame selle sõltuvusi. Pange tähele rida size = "small" plokis [engine]. See on piirang, mis eraldatakse teenusele läbi Kubernetes'e.

Edasi genereeritakse selle konfiguratsiooni põhjal automaatselt kõik vajalikud Helm-chart'id ja luuakse ühendused andmebaasidega.

• Põhivaatlus. Sellised kontrollid on samuti automatiseeritud.
Oluline on jälgida:
— kas Dockerfile on olemas;
— kas app.toml on olemas;
— kas on dokumentatsioon;
— kas sõltuvused on korras;
— kas on määratud häirereeglid.
Viimase punkti kohta: teenuse omanik määrab ise, milliseid tootmisnäitajaid jälgida.

• Dokumentatsiooni ettevalmistamine.
Siiani on see probleemne koht. Tundub nagu kõige ilmsem, kuid samas ka rekordiliselt „unustatud”, seega on see haavatav lüli ahelas.
On vajalik, et iga mikroteenuse kohta oleks dokumentatsioon. See sisaldab järgmisi osi.

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

II. Lingid arhitektuuri diagrammile. Oluline, et kiirel pilgul oleks lihtne mõista, kas kasutate Redis’i vahemäluna või peamise andmete salvestamise viisina püsirežiimis. Avitos on see praegu link Confluence’ile.

III. Runbook. Lühike juhend teenuse käivitamiseks ja selle kasutamise nüansside kohta.

IV. KKK, kus oleks hea ette näha probleemid, millega teie kolleegid teenuse kasutamisel silmitsi võivad seista.

V. API lõpp-punktide kirjeldus. Kui te ei ole sihtkohti määranud, siis peavad tõenäoliselt teie kolleegid, kelle mikroteenused on teie omadega seotud, selle eest tasuma. Praegu kasutame selle jaoks Swaggerit ja meie lahendust nimega brief.

VI. Silte. Või markerid, mis näitavad, millise toote, funktsionaalsuse või ettevõtte struktuuriüksusega teenus seotud on. Aitavad kiiresti mõista, näiteks, kas te ei arenda funktsionaalsust, mille kolleegid nädal tagasi samale ärigrupile välja tõid.

VII. Teenuse omanik või omanikud. Enamasti saab selle — või nende — PaaS abil automaatselt määrata, kuid igaks juhuks nõuame arendajalt, et nad need käsitsi ka märkida.

Lõpuks on hea viis dokumentatsiooni ülevaatamine, sarnaselt code review’le.

Jätkuv integreerimine

• Repozitoriumide ettevalmistamine.
• Pipeliini loomine TeamCitys.
• Õiguste määramine.
• Teenuse omanike otsimine. Siin on hübriidskeem — käsitsi märgistamine ja minimaalne automatiseerimine PaaS-i poolt. Täiesti automatiseeritud skeem kaob teenuste ülekandmisel teise arendusteami toetuseks või näiteks, kui teenuse arendaja lahkub ettevõttest.
• Teenuse registreerimine Atlas (vt. ülal). Kõikide selle omanike ja sõltuvustega.
• Migratsioonide kontrollimine. Kontrollime, kas nende seas on potentsiaalselt ohtlikke. Näiteks, kui üks neist sisaldab 'alter table' või midagi muud, mis võib andmeskeemi erinevate teenuseversioonide vahel kokku leppida. Sel juhul migratsioon ei toimu ja see pannakse tellimisse — PaaS peab omanikule signaalima, kui see on ohutu rakendada.

Bake

Järgmine etapp - teenuste pakkimine enne juurutamist.

• Rakenduse komplekteerimine. Klassikaliselt - Docker-pildiks.
• Helm-chartide genereerimine teenuse ja sellele seotud ressursside jaoks. Sealhulgas andmebaasid ja vahemälu. Need genereeritakse automaatselt vastavalt app.toml konfiguratsioonile, mis moodustati CLI-pushi etapis.
• Piletite loomine administraatoritele portide avamiseks (kui see on vajalik).
• Ühiktestide läbiviimine ja koodi katvuse arvutamine. Kui koodi katte tase jääb alla nõutud tõkkeväärtuse, siis tõenäoliselt ei pruugi teenus edasi minna — deploy’ile. Kui tase on piiril, siis antakse teenusele „pessimiseeriv“ koefitsiend, mis tähendab, et kui näitaja ajaga ei parane, saab arendaja teate, et testide osas pole edusamme (ja tuleks sellega midagi ette võtta).
• Mälu ja CPU piirangute arvestamine. Peamiselt kirjutame mikroteenuseid Golangis ja käitame neid Kuberneteses. Seetõttu on üks nüanss, mis on seotud Golangi omadustega: vaikimisi käivituvad masinal kõik tuumad, välja arvatud juhul, kui muutuja GOMAXPROCS on selgelt määratud, ja kui mitmed sellised teenused on ühel masinal käimas, hakkavad nad omavahel ressursse konkureerima ja segama üksteist. Allolevatel graafikutel on näidatud, kuidas täitmise aeg muutub, kui rakendust käitada ilma konkurentsita või ressursiheitluses. (Graafikute lähtekood on olemas. siit).

Täitmise aeg, mida vähem, seda parem. Maksimum: 643ms, minimum: 42ms. Foto on klikkitav.

Operatsiooni aeg, mida vähem, seda parem. Maksimum: 14091 ns, minimum: 151 ns. Foto on klikkitav.

Kogumise ettevalmistamise etapis saab seda muutujat määrata üheselt või kasutada raamatukogu. automaxprocs Uberi meeskonnast.

Juhtimistöö

• Konventsioonide kontrollimine. Enne teenuse kogude tarnimise alustamist planeeritud keskkondadesse tuleb kontrollida järgmist:
— API lõpp-punktid.
— API lõpp-punktide vastuste vastavus skeemile.
— Logifailide formaat.
— Pealkirjade määramine teenuse päringute tegemisel (hetkel teeb seda netramesh).
— Omaniku märgi määramine sõnumite saatmisel bussile (event bus). See on vajalik teenuste seose jälgimiseks läbi bussi. Bussi saab saata nii idempotentseid andmeid, mis ei suurenda teenuste seoseid (mis on hea), kui ka ärilisi andmeid, mis seoseid suurendavad (mis on väga halb!). Ja hetkel, mil see seos muutub probleemiks, aitab arusaam, kes kirjutab ja loeb bussi, teenuseid õigesti lahutada.

Praegu ei ole Avitos palju konventsioone, kuid nende hulk laieneb. Mida rohkem selliseid kokkuleppeid on meeskonnale arusaadavas ja mugavas vormis, seda lihtsam on mikroteenuste vahel konsistentsi säilitada.

Süntetaalsed testid

• Testimine suletud silindris. Selleks kasutame hetkel avatud lähtekoodiga Hoverfly.io. Esiteks registreerib see teenuse reaalset koormust ja seejärel simuleerib seda suletud kontuuris.

• Koormustestimine. Püüame kõiki teenuseid viia optimaalsele tootlikkusele. Ja kõikide teenuste versioonid peavad läbima koormustestimise — nii saame aru teenuse praegusest tootlikkusest ja erinevusest eelmiste versioonidega. Kui teenuse uuendamise järel selle võimekus väheneb poolteist korda, on see omanikele selge signaal: on aeg koodi süveneda ja olukord parandada.
Kogutud andmetest lähtume näiteks selleks, et õigesti rakendada auto skaala, ja lõpuks isegi mõista, kui palju teenus suudab skaleeruda.

Koormustestimise käigus kontrollime, kas ressursikasutuse piirangud peavad vastu. Ja pöörame tähelepanu eelkõige äärmustele.

a) Vaatame, mis on üldine koormus.
— Kui see on liiga madal, tähendab see tõenäoliselt, et midagi ei tööta, kui koormus on järsku mitu korda vähenenud.
— Kui see on liiga kõrge, on vajalik optimeerimine.

b) Vaatame RPS piiri.
Siin vaatame nii praeguse versiooni ja eelneva erinevust kui ka üldist arvu. Näiteks, kui teenus annab 100 rps, siis on see kas halvasti kirjutatud või see on tema spetsiifika, kuid igal juhul on see põhjus teenusele väga lähedalt pilku heita.
Kui RPS on aga liiga suur, siis võib olla mingi viga ja mõni endpoint ei teosta enam kasulikku koormust, vaid aktiveerib lihtsalt mingi. return true;

Canary-testid

Pärast sünteetiliste testide läbimist katsetame mikroteenuse toimimist väikese kasutajate arvu peal. Alustame ettevaatlikult, vähem kui 0,1% eeldatavast teenuse sihtrühmast. Sel hetkel on äärmiselt oluline, et jälgimises oleksid seadistatud õiged tehnilised ja toote metoodikad, et nad suudaksid võimalikult kiiresti näidata probleemi teenuses. Minimaalne canary-testi aeg on 5 minutit, peamine 2 tundi. Kompleksetes teenustes määrame aja käsitsi.
Analüüsime:
— keelespetsiifilisi metrikaid, sealhulgas php-fpm töötajad;
— vead Sentry-s;
— vastuste staatused;
— vastamisaeg (response time), täpne ja keskmine;
— latency;
— käideldud ja käideldamatud erandid;
— toote mõõdikud.

Squeeze Testing

Squeeze Testingut tuntakse ka kui „väljade testimist“. Meetodi nimi tuli Netflixilt. Selle põhimõte on see, et esmalt täidame ühe instantsi reaalse liiklusega kuni selle rikki minekuni, seeläbi seame selle piiri. Seejärel lisame veel ühe instantsi ja koormame neid kahte — jälle maksimaalselt; näeme nende piirangut ja erinevust esimesest „squeeze'ist“. Ja nii ühendame sammhaaval ühe instantsi ja arvutame muutuste mustri.
Andmed „väljade testimise“ kohta kogutakse ka üldises mõõdikate andmebaasis, kus me kas rikastame nendega kunstlikkoormuse tulemusi või asendame need „sünteetika“ täielikult.

Tootmine

• Skaalautuvus. Teenuse käivitamisel tootmises jälgime, kuidas see skaleerub. Ainult CPU näitajate jälgimine ei ole meie kogemuse põhjal efektiivne. Auto skaleerimine puhta RPS testimisega töötab, kuid ainult teatud teenuste jaoks, näiteks online-voogedastuses. Seega vaatame esmalt rakendusele spetsiifilisi toote mõõdikuid.

Lõppkokkuvõttes analüüsime skaleerimise käigus:
— CPU ja RAM näitajad,
— järjekorras olevate päringute arv,
— vastuse aeg,
— prognoos kogutud ajalooliste andmete põhjal.

Teenuse skaleerimisel on samuti oluline jälgida selle sõltuvusi, et vältida olukorda, kus skaleerime esmase teenuse, kuid sõltuvatest teenustest, millega see suhtleb, saab koormuse all kokkuvarisemine. Et määrata kogu teenuste grupi vastuvõetav koormus, vaatame ajaloolisi andmeid 'lähedasest' sõltuvusest (CPU ja RAM kombinatsiooni ning rakendustele spetsiifiliste mõõdikute põhjal) ja seome need algse teenuse ajalooliste andmetega, ja edasi kõikide 'sõltuvuste ahela' kaudu, ülalpoolt allapoole.

Hooldus

Pärast seda, kui mikroteenus on tööle pandud, saame sellele lisada käivitajad.

Siin on tüüpilised olukorrad, kus käivitajad aktiveeruvad.
— Potentsiaalselt ohtlike migratsioonide avastamine.
— Turvauuendused on välja antud.
— Teenust ei ole pikka aega uuendatud.
— Teenuse koormus on märkimisväärselt vähenenud või mõned toote mõõdikud ületavad normi.
— Teenus ei vasta enam platvormi uutele nõuetele.

Mõned käivitajad vastutavad töö stabiilsuse eest, mõned täidavad süsteemi hoolduskohustusi — näiteks, mõni teenus pole ammu déployitud ning selle baasimage ei läbinud enam turvaproove.

Armatuurlaud

Lühidalt öeldes on armatuurlaud meie PaaSi kogu juhtimiskeskus.

• Üksne infoallikas teenuse kohta, sealhulgas andmed selle testkatete, image'ide arvu, tootmiskoopiate arvu, versioonide jne kohta.
• Andmete filtreerimise tööriist teenuste ja labelite (äriklasside kuuluvuse, toote funktsionaalsuse jne) põhjal.
• Integreerimise tööriist riistvaratööriistadega jälgimise, logimise ja monitoorimise jaoks.
• Ühtne dokumentatsiooni allikas teenuste kohta.
• Ühtne ülevaade kõigist teenuste sündmustest.

Kokku

Enne PaaSi juurutamist võis uue arendaja kuluda mitu nädalat, et igasuguste tööriistadega, mis on vajalikud mikroteenuse tootmisse viimiseks, nagu Kubernetes, Helm ning meie sisese TeamCity eripäradega, andmebaaside ja vahemälude kättesaamise seadistamine, tutvuda. Praegu kulub selleks paar tundi — piisab, et lugeda kiiret juhendit ja teha teenus ise.

Ma tegin sellel teemal ettekande HighLoad++ 2018 konverentsil, seda saab vaadata video ja esitluse.

Boonusraja neile, kes jõudsid lõpuni

Meie Avitos korraldame arendajatele kolmepäevase siseõppe Kris Richardsonilt Kris Richardsonilt, mikroteenuste arhitektuuri eksperdilt. Soovime anda võimaluse osaleda kellegile selle postituse lugejatest. Siit Treeningu programm on avaldatud.

Treening toimub 5.–7. augustil Moskvas. Need on tööpäevad, mis on täielikult hõivatud. Lõuna ja õpe toimuvad meie kontoris, kuid valitud osaleja katab ise tee ja majutuse kulud.

Osalemiseks saab registreeruda selles Google'i vormis. Teilt oodatakse vastust küsimusele, miks just teile on vaja treeningule tulla, ja teavet, kuidas teiega ühendust võtta. Vastake inglise keeles, sest osalejat, kes pääseb treeningule, valib Kris isiklikult.
Teavitame treeningu osaleja nime selle postituse uuenduses ja Avito arendajate sotsiaalmeedias (AvitoTech Facebookis, VKontakte, Twitteris) hiljemalt 19. juulil.

Allikas: habr.com