🥇Microserviciile: dimensiunea contează, chiar dacă aveți Kubernetes

19 septembrie în Moscova a avut loc prima întâlnire tematică HUG (Highload++ User Group), care a fost dedicată microserviciilor. Aici a fost susținută prezentarea „Exploatarea microserviciilor: dimensiunea contează, chiar dacă aveți Kubernetes”, în care am împărtășit o experiență vastă a companiei „Flant” în exploatarea proiectelor cu arhitectură de microservicii. În primul rând, va fi utilă tuturor dezvoltatorilor care se gândesc să aplice această abordare în proiectul lor actual sau viitor.

Prezentăm un videoclip cu prezentarea (50 de minute, mult mai informativ decât un articol), precum și rezumatul principal în format text.

NB: Videoclipul și prezentarea sunt de asemenea disponibile la sfârșitul acestei publicații.

Introducere

De obicei, o poveste bună are o introducere, un plot principal și o concluzie. Această prezentare seamănă mai mult cu o introducere, de fapt una tragică. De asemenea, este important de menționat că este prezentat un punct de vedere asupra microserviciilor din perspectiva exploatării.

Voi începe cu un astfel de grafic, al cărui autor (în 2015) este Martin Fowler:

În acesta se observă cum, în cazul unei aplicații monolitice care a atins o anumită dimensiune, productivitatea începe să scadă. Microserviciile se disting prin faptul că productivitatea inițială este mai mică, dar pe măsură ce complexitatea crește, degradarea eficienței nu este atât de evidentă.

Voi completa acest grafic pentru cazul utilizării Kubernetes:

De ce a devenit mai bună aplicația cu microservicii? Deoarece o astfel de arhitectură impune cerințe serioase asupra arhitecturii, care, la rândul lor, sunt excelente pentru capacitățile Kubernetes. Pe de altă parte, o parte din această funcționalitate va fi utilă și pentru monolit, mai ales din cauza faptului că monolitul tipic de astăzi nu este chiar un monolit (detalii vor fi date ulterior în prezentare).

După cum se vede, graficul final (când atât aplicațiile monolitice, cât și cele microserviciilor sunt în infrastructura Kubernetes) nu se deosebește prea mult de cel inițial. În continuare, vom vorbi despre aplicațiile exploatate utilizând Kubernetes.

Microservicii utile și dăunătoare

Și aici, gândul principal este:

Ce este o arhitectură microserviciilor normală? Aceasta ar trebui să vă aducă beneficii reale, crescând eficiența muncii. Dacă ne întoarcem la grafic, atunci o avem:

Dacă o numim utilă, atunci pe cealaltă parte a graficului va fi dăunătoare microserviciu (îngreunează munca):

Revenind la „ideea principală”: ar trebui să am încredere în experiența mea? De la începutul acestui an, am văzut 85 de proiecte. Nu toate au fost microservicii (aproximativ o treime până la jumătate dintre ele aveau această arhitectură), dar totuși este un număr semnificativ. Noi (compania „Flant”) ca outsourceri reușim să vedem o diversitate largă de aplicații, dezvoltate atât în companii mici (cu 5 dezvoltatori), cât și în companii mari (~500 de dezvoltatori). Un alt avantaj este că vedem cum evoluează aceste aplicații de-a lungul anilor.

De ce microservicii?

La întrebarea despre beneficiile microserviciilor există un răspuns foarte concret dat de deja menționatul Martin Fowler:

granițe clare ale modularității;
implementare independentă;
libertatea de a alege tehnologiile.

Am discutat mult cu arhitecți și dezvoltatori software și i-am întrebat de ce le sunt necesare microserviciile. Și am întocmit lista așteptărilor lor. Iată ce a rezultat:

Dacă aș descrie „în percepții” câteva dintre puncte, acestea ar fi:

granițe clare între module: avem un monolit terifiant, iar acum totul va fi organizat frumos în repo-uri Git, în care totul este „pe rafturi”, fără a amesteca cele calde cu cele moi;
independența implementării: vom putea lansa servicii în mod independent, pentru a accelera dezvoltarea (publicând noi caracteristici în paralel);
independența dezvoltării: putem încredința acest microserviciu unei echipe/developer, iar celălalt va prelua altul, ceea ce ne va permite să dezvoltăm mai repede;
bmarefiabilitate mai mare: dacă se va produce o degradare parțială (se va prăbuși un microserviciu din 20), va funcționa doar un singur buton, iar sistemul, în ansamblu, va continua să funcționeze.

O arhitectură microservică tipică (dăunătoare)

Pentru a explica de ce în realitate lucrurile nu sunt așa cum ne așteptăm, voi prezenta un exemplu de arhitectură microservică, bazat pe experiențe din numeroase proiecte diferite.

Un exemplu va fi un magazin online abstract, care intenționează să concureze cu Amazon sau măcar cu OZON. Arhitectura sa microservică arată astfel:

Din diverse motive, aceste microservicii sunt scrise pe platforme diferite:

Deoarece fiecare microserviciu trebuie să aibă autonomitate, multe dintre ele au nevoie de propria bază de date și cache. Arhitectura finală devine următoarea:

Care sunt consecințele?

Fowler are un articol pe acest subiect despre "costurile" utilizării microserviciilor: Uite că ne vom verifica dacă așteptările noastre s-au îndeplinit.

Limitele clare ale modulelor...

câte microservicii ar trebui de fapt să corectăm

Dar , pentru a implementa o modificare? Putem înțelege cu adevărat cum funcționează totul fără un trasor distribuit (deoarece orice solicitare este procesată de jumătate dintre microservicii)?Există un model de "

morman de murdărie", iar aici s-a format un morman distribuit de murdărie. În sprijinul acestui fapt - iată o ilustrație aproximativă a modului în care circulă solicitările:Independența desfășurării...

Tehnic, aceasta a fost realizată: putem desfășura fiecare microserviciu separat. Dar în practică, trebuie să luăm în considerare că întotdeauna sunt desfășurate

mai multe microservicii , iar noi trebuie să luăm în considerareordonarea desfășurării lor. În mod ideal, ar trebui să testăm în mod separat dacă desfășurăm release-ul în ordinea corectă.Libertatea de a alege tehnologia...

Există. Dar trebuie să reținem că, adesea, libertatea se limitează la haos. Este foarte important să nu alegem tehnologiile doar pentru a “ne juca” cu ele.

Independența dezvoltării...

Cum să construim un mediu de testare pentru întreaga aplicație (dintr-o atât de mare varietate de componente)? Și trebuie să-l menținem mereu actualizat. Toate acestea duc la faptul că

numărul real de medii de testare , pe care le putem susține,se dovedește a fi minim. Și ce zici de desfășurarea totului local?.. Se pare că, adesea, dezvoltatorul își face treaba independent, dar "la noroc", pentru că este nevoit să aștepte să se elibereze un mediu pentru testare..

Scalarea separată...

Da, dar este limitată în ceea ce privește bazele de date utilizate. În exemplul prezentat, nu vor exista probleme cu Cassandra, dar vor fi cu MySQL și PostgreSQL.

fiabilitate mai mare...mareNu doar că, de fapt, defectarea unui microserviciu sparge de multe ori funcționarea corectă a întregului sistem, dar există și o nouă problemă:

a face fiecare microserviciu tolerant la erori este foarte complicat. Este foarte dificil să faci fiecare microserviciu rezistent la erori.. Pentru că în microservicii se folosesc tehnologii diferite (memcache, Redis etc.), pentru fiecare trebuie să ne gândim la tot și să implementăm, ceea ce, desigur, este posibil, dar necesită resurse imense.

Măsurabilitatea încărcăturii…

Cu asta, într-adevăr, totul este bine.

«Ușurința» microserviciilor…

Nu doar că ne-au apărut imense costuri de rețea (crește numărul cererilor DNS etc.), dar și din cauza multor subcereri am început să replicăm datele (să stocăm cache-uri), ceea ce a dus la un volum semnificativ de stocare.

Și iată care este rezultatul conformității cu așteptările noastre:

Dar asta nu e tot!

Pentru că:

Cel mai probabil ne va trebui un sistem de mesaje.
Cum să facem un backup consistent la momentul dorit? Singura opțiune reală este să oprim traficul pentru asta. Dar cum se poate face în producție?
Dacă este vorba despre suportul pentru mai multe regiuni, organizarea rezilienței în fiecare dintre ele este o sarcină foarte laborioasă.
Apasă pe problemă modificării centralizate. De exemplu, dacă trebuie să actualizăm versiunea PHP, va trebui să facem un commit în fiecare repository (iar acestea sunt zeci).
Creșterea complexității operative este, de la prima vedere, exponențială.

Ce să facem cu toate acestea?

Începeți cu o aplicație monolitică. Experiența lui Fowler spune indică faptul că aproape toate aplicațiile microserviciu de succes au început dintr-un monolit care a devenit prea mare și a fost apoi divizat. Între timp, aproape toate sistemele construite ca microservicii de la început, mai devreme sau mai târziu, au experimentat probleme serioase.

Încă o idee valoroasă – pentru ca un proiect cu arhitectură microserviciu să fie de succes, trebuie să cunoașteți foarte bine atât domeniul de activitate, cât și cum să realizați microservicii.. Iar cea mai bună modalitate de a cunoaște domeniul de activitate este să faceți un monolit.

Dar ce să facem dacă ne aflăm deja în această situație?

Primul pas spre rezolvarea oricărei probleme este să acceptăm că este o problemă și să înțelegem că nu mai vrem să suferim.

Dacă în cazul unui monolit crescut (când am terminat resursele pentru el), îl divizăm, în acest caz avem povestea inversă: când microserviciile excesive nu mai ajută, ci deranjează – tăiați excesul și măriți!

De exemplu, pentru imaginea de ansamblu discutată mai sus…

Scăpați de cele mai îndoielnice microservicii:

Uniți toate microserviciile responsabile pentru generarea frontend-ului:

… într-un singur microserviciu, scris într-o limbă/framework modern (așa cum considerați că este) dintr-un singur tip:

Acesta va avea un singur ORM (o bază de date) și inițial câteva aplicații:

… dar în general, se pot muta mult mai multe acolo, obținând astfel acest rezultat:

Mai mult, în Kubernetes le lansăm ca instanțe separate, ceea ce înseamnă că putem încă măsura încărcarea și să le scalăm individual.

În concluzie

Privind la imaginea de ansamblu. Foarte des, toate aceste probleme cu microserviciile apar deoarece cineva și-a asumat sarcina, dar a vrut să „se joace cu microserviciile”.

În cuvântul „microservicii”, partea „micro” este redundantă.. Ele sunt „micro” doar pentru că sunt mai mici decât un monolit imens. Dar nu trebuie să le considerați ca fiind ceva mic.

Și pentru gândul final, să ne întoarcem la graficul inițial:

Nota scrisă pentru acesta (în dreapta sus) se reduce la faptul că abilitățile echipei care lucrează la proiectul dumneavoastră sunt mereu primordiale — ele vor juca rolul principal în alegerea între microservicii și monolit. Dacă echipei îi lipsesc abilitățile, dar începe să creeze microservicii, povestea va fi cu siguranță fatală.

Videoclipuri și diapozitive

Videoclipul prezentării (~50 de minute; din păcate, nu surprinde numeroasele emoții ale vizitatorilor, care au determinat în mare parte tonul prezentării, dar așa este):