19 septembrie la Moscova prima întâlnire tematică HUG (Highload++ User Group), care a fost dedicată microserviciilor. A existat o prezentare „Operating Microservices: Size Matters, Even If You Have Kubernetes”, în care am împărtășit experiența vastă a lui Flant în operarea proiectelor cu arhitectură de microservicii. În primul rând, va fi util tuturor dezvoltatorilor care se gândesc să folosească această abordare în proiectul lor actual sau viitor.
Introducand (50 de minute, mult mai informativ decât articolul), precum și extrasul principal din acesta sub formă de text.
NB: Videoclipul și prezentarea sunt, de asemenea, disponibile la sfârșitul acestei postări.
Introducere
De obicei, o poveste bună are un început, un complot principal și o rezoluție. Acest raport este mai degrabă un preludiu și, în același timp, unul tragic. De asemenea, este important să rețineți că oferă o viziune externă asupra microserviciilor. exploatare.
Voi începe cu acest grafic, al cărui autor (în 2015) Martin Fowler:
Arată cum, în cazul unei aplicații monolitice care atinge o anumită valoare, productivitatea începe să scadă. Microserviciile sunt diferite prin aceea că productivitatea inițială cu ele este mai mică, dar pe măsură ce complexitatea crește, degradarea eficienței nu este atât de vizibilă pentru ele.
Voi adăuga la acest grafic pentru cazul utilizării Kubernetes:
De ce este mai bună o aplicație cu microservicii? Pentru că o astfel de arhitectură prezintă cerințe serioase pentru arhitectură, care la rândul lor sunt perfect acoperite de capacitățile Kubernetes. Pe de altă parte, o parte din această funcționalitate va fi utilă pentru un monolit, mai ales că monolitul tipic de astăzi nu este tocmai un monolit (detaliile vor fi mai târziu în raport).
După cum puteți vedea, graficul final (când atât aplicațiile monolitice, cât și cele de microservicii sunt în infrastructura cu Kubernetes) nu este foarte diferit de cel inițial. În continuare vom vorbi despre aplicațiile operate folosind Kubernetes.
Microservicii utile și dăunătoare
Și iată ideea principală:
Ce este normal arhitectura microservicii? Ar trebui să vă aducă beneficii reale, sporindu-vă eficiența muncii. Dacă ne întoarcem la grafic, iată-l:
Dacă o suni util, apoi pe cealaltă parte a graficului va fi dăunătoare microservicii (interferează cu munca):
Revenind la „ideea principală”: ar trebui să am încredere în experiența mea? De la începutul acestui an m-am uitat 85 de proiecte. Nu toate erau microservicii (aproximativ o treime până la jumătate dintre ele aveau o astfel de arhitectură), dar acesta este încă un număr mare. Noi (compania Flant) ca externalizatori reușim să vedem o mare varietate de aplicații dezvoltate atât în companii mici (cu 5 dezvoltatori), cât și în cele mari (~500 de dezvoltatori). Un avantaj suplimentar este că vedem aceste aplicații vii și evoluând de-a lungul anilor.
De ce microservicii?
La întrebarea despre beneficiile microserviciilor există de la deja menționatul Martin Fowler:
- limite clare ale modularității;
- desfășurare independentă;
- libertatea de a alege tehnologiile.
Am vorbit mult cu arhitecți și dezvoltatori de software și am întrebat de ce au nevoie de microservicii. Și mi-am făcut lista cu așteptările lor. Iată ce s-a întâmplat:
Dacă descriem unele dintre punctele „în senzații”, atunci:
- limite clare ale modulelor: aici avem un monolit teribil, iar acum totul va fi aranjat frumos în depozitele Git, în care totul este „pe rafturi”, caldul și moale nu sunt amestecați;
- independență de implementare: vom putea să lansăm servicii în mod independent, astfel încât dezvoltarea să meargă mai rapid (publicați noi funcții în paralel);
- independență de dezvoltare: putem acorda acest microserviciu unei echipe/dezvoltator, iar unul altuia, datorită căruia ne putem dezvolta mai rapid;
- боfiabilitate mai mare: dacă are loc o degradare parțială (un microserviciu din 20 cade), atunci un singur buton nu va mai funcționa, iar sistemul în ansamblu va continua să funcționeze.
Arhitectură tipică (dăunătoare) de microservicii
Pentru a explica de ce realitatea nu este ceea ce ne așteptăm, voi prezenta colectiv o imagine a unei arhitecturi de microservicii bazată pe experiența din multe proiecte diferite.
Un exemplu ar fi un magazin online abstract care va concura cu Amazon sau cel puțin cu OZON. Arhitectura sa de microservicii arată astfel:
Dintr-o combinație de motive, aceste microservicii sunt scrise pe diferite platforme:
Deoarece fiecare microserviciu trebuie să aibă autonomie, multe dintre ele au nevoie de propria lor bază de date și cache. Arhitectura finală este următoarea:
Care sunt consecințele sale?
Fowler are și asta — despre „plata” pentru utilizarea microserviciilor:
Și vom vedea dacă așteptările noastre au fost îndeplinite.
Limitele clare ale modulelor...
Dar câte microservicii trebuie de fapt să reparăm?pentru a lansa schimbarea? Putem chiar să ne dăm seama cum funcționează totul fără un trasor distribuit (la urma urmei, orice solicitare este procesată de jumătate dintre microservicii)?
Există un model"„, și aici s-a dovedit a fi un bulgăre distribuit de murdărie. Pentru a confirma acest lucru, iată o ilustrare aproximativă a modului în care decurg solicitările:
Independenta de implementare...
Din punct de vedere tehnic, s-a realizat: putem lansa fiecare microserviciu separat. Dar, în practică, trebuie să țineți cont de faptul că se lansează întotdeauna multe microservicii, și trebuie să luăm în considerare ordinea lansării lor. Într-un mod bun, în general, trebuie să testăm într-un circuit separat dacă lansăm ediția în ordinea corectă.
Libertatea de a alege tehnologia...
Ea este. Nu uitați că libertatea se învecinează adesea cu nelegiuirea. Este foarte important aici să nu alegeți tehnologii doar pentru a „juca” cu ele.
Independenta de dezvoltare...
Cum să faci o buclă de testare pentru întreaga aplicație (cu atât de multe componente)? Dar tot trebuie să-l ții la zi. Toate acestea conduc la faptul că numărul real de circuite de testare, pe care în principiu o putem conține, se dovedește a fi minim.
Ce zici de implementarea tuturor acestor lucruri la nivel local?... Se dovedește că adesea dezvoltatorul își face treaba independent, dar „la întâmplare”, deoarece este forțat să aștepte până când circuitul este liber pentru testare.
Scalare separată...
Da, dar este limitat în zona SGBD-ului utilizat. În exemplul de arhitectură dat, Cassandra nu va avea probleme, dar MySQL și PostgreSQL vor avea probleme.
Боfiabilitate mai mare...
Nu numai că eșecul unui microserviciu în realitate rupe adesea funcționarea corectă a întregului sistem, dar există și o nouă problemă: a face fiecare microserviciu tolerant la erori este foarte dificil. Deoarece microservicii folosesc tehnologii diferite (memcache, Redis etc.), pentru fiecare trebuie să te gândești la toate și să le implementezi, ceea ce, desigur, este posibil, dar necesită resurse uriașe.
Masurabilitatea sarcinii...
Asta e chiar bună.
„Lejeritatea” microserviciilor...
Nu avem doar uriașe supraîncărcarea rețelei (solicitările pentru DNS se înmulțesc etc.), dar și datorită numeroaselor subinterogări pe care le-am început replicare a datelor (cache-uri de stocare), ceea ce a dus la o cantitate semnificativă de stocare.
Și iată rezultatul îndeplinirii așteptărilor noastre:
Dar asta nu este tot!
Pentru că:
- Cel mai probabil vom avea nevoie de un autobuz de mesaje.
- Cum să faci o copie de rezervă consistentă la momentul potrivit? Singurul real opțiunea este de a opri traficul pentru aceasta. Dar cum să faci asta în producție?
- Dacă vorbim de sprijinirea mai multor regiuni, atunci organizarea durabilității în fiecare dintre ele este o sarcină foarte intensivă în muncă.
- Apare problema efectuării schimbărilor centralizate. De exemplu, dacă trebuie să actualizăm versiunea PHP, va trebui să ne angajăm în fiecare depozit (și există zeci de ele).
- Creșterea complexității operaționale este, neînsemnată, exponențială.
Ce să faci cu toate astea?
Începeți cu o aplicație monolitică. Experiența lui Fowler că aproape toate aplicațiile de microservicii de succes au început ca un monolit care a devenit prea mare și apoi a fost spart. În același timp, aproape toate sistemele construite ca microservicii încă de la început au întâmpinat probleme serioase, mai devreme sau mai târziu.
Un alt gând valoros este că pentru ca un proiect cu arhitectură de microservicii să aibă succes, trebuie să știi foarte bine și domeniul și cum să faci microservicii. Și cel mai bun mod de a învăța o materie este să faci un monolit.
Dar dacă ne aflăm deja în această situație?
Primul pas pentru a rezolva orice problemă este să fim de acord cu ea și să înțelegem că este o problemă, că nu vrem să mai suferim.
Dacă, în cazul unui monolit supraîncărcat (când nu am mai rămas fără oportunitatea de a cumpăra resurse suplimentare pentru el), îl tăiem, atunci în acest caz se dovedește o poveste inversă: când microservicii excesive nu mai ajută, ci împiedică - tăiați excesul și măriți!
De exemplu, pentru imaginea colectivă discutată mai sus...
Scapa de cele mai discutabile microservicii:
Combinați toate microserviciile responsabile pentru generarea frontend:
... într-un singur microserviciu, scris într-un singur limbaj/cadru (modern și normal, după cum credeți dvs.):
Va avea un ORM (un SGBD) și mai întâi câteva aplicații:
... dar în general poți transfera mult mai mult acolo, obținând următorul rezultat:
Mai mult, în Kubernetes rulăm toate acestea în instanțe separate, ceea ce înseamnă că încă putem măsura încărcarea și le putem scala separat.
A rezuma
Uită-te la imaginea de ansamblu. Foarte des, toate aceste probleme cu microservicii apar pentru că cineva și-a luat sarcina, dar a vrut să „se joace cu microservicii”.
În cuvântul „microservicii” partea „micro” este redundantă.. Sunt „micro” doar pentru că sunt mai mici decât un monolit uriaș. Dar nu vă gândiți la ele ca la ceva mic.
Și pentru o ultimă idee, să revenim la diagrama originală:
O notă scrisă pe el (sus în dreapta) se rezumă la faptul că abilitățile echipei care vă realizează proiectul sunt întotdeauna primordiale — vor juca un rol cheie în alegerea dvs. între microservicii și un monolit. Dacă echipa nu are suficiente competențe, dar începe să facă microservicii, povestea va fi cu siguranță fatală.
Videoclipuri și diapozitive
Video din discurs (~50 de minute; din păcate, nu transmite numeroasele emoții ale vizitatorilor, care au determinat în mare măsură starea de spirit a reportajului, dar așa este):
Prezentarea raportului:
PS
Alte rapoarte pe blogul nostru:
- «» (Dmitri Stolyarov; 28 mai 2018 la RootConf);
- «» (Dmitri Stolyarov; 7 noiembrie 2017 pe HighLoad++);
- «» (Dmitri Stolyarov; 6 iunie 2017 la RootConf);
- «» (Dmitri Stolyarov; 8 noiembrie 2016 pe HighLoad++);
- «» (Dmitri Stolyarov; 31 mai 2016 la RootConf).
Ați putea fi, de asemenea, interesat de următoarele publicații:
- «»;
- «»;
- «".
Sursa: www.habr.com