19 shtator në Moskë takimi i parë tematik HUG (Highload++ User Group), i cili iu kushtua mikroshërbimeve. Pati një prezantim "Operating Microservices: Madhësia ka rëndësi, edhe nëse keni Kubernetes", në të cilin ne ndamë përvojën e gjerë të Flantit në operimin e projekteve me arkitekturë mikroservice. Para së gjithash, do të jetë e dobishme për të gjithë zhvilluesit që po mendojnë të përdorin këtë qasje në projektin e tyre aktual ose të ardhshëm.
duke prezantuar (50 minuta, shumë më informuese se artikulli), si dhe ekstrakti kryesor prej tij në formë teksti.
NB: Video dhe prezantimi janë gjithashtu të disponueshme në fund të këtij postimi.
Paraqitje
Zakonisht një histori e mirë ka një fillim, një komplot kryesor dhe një zgjidhje. Ky raport i ngjan më shumë një preludi, dhe më shumë tragjik. Është gjithashtu e rëndësishme të theksohet se ofron një pamje të jashtme të mikroshërbimeve. shfrytëzimit.
Do të filloj me këtë grafik, autori i të cilit (në 2015) Martin Fowler:
Ajo tregon se si, në rastin e një aplikimi monolit që arrin një vlerë të caktuar, produktiviteti fillon të bjerë. Mikroshërbimet janë të ndryshme në atë që produktiviteti fillestar me to është më i ulët, por ndërsa kompleksiteti rritet, degradimi i efikasitetit nuk është aq i dukshëm për ta.
Unë do të shtoj në këtë grafik për rastin e përdorimit të Kubernetes:
Pse është më i mirë një aplikacion me mikroshërbime? Sepse një arkitekturë e tillë shtron kërkesa serioze për arkitekturën, të cilat nga ana e tyre mbulohen në mënyrë të përkryer nga aftësitë e Kubernetes. Nga ana tjetër, disa nga ky funksionalitet do të jenë të dobishëm për një monolit, veçanërisht sepse monoliti tipik sot nuk është saktësisht një monolit (detajet do të jenë më vonë në raport).
Siç mund ta shihni, grafiku përfundimtar (kur aplikacionet monolitike dhe mikroservice janë në infrastrukturë me Kubernetes) nuk është shumë i ndryshëm nga ai origjinal. Më tej do të flasim për aplikacionet e operuara duke përdorur Kubernetes.
Mikroshërbime të dobishme dhe të dëmshme
Dhe këtu është ideja kryesore:
çfarë është normal Arkitektura e mikroshërbimeve? Duhet t'ju sjellë përfitime reale, duke rritur efikasitetin tuaj të punës. Nëse kthehemi te grafiku, këtu është:
Nëse e thërrisni atë e dobishme, atëherë në anën tjetër të grafikut do të ketë të dëmshme mikroshërbime (ndërhyn në punë):
Duke iu rikthyer "idesë kryesore": a duhet t'i besoj fare përvojës sime? Që nga fillimi i këtij viti kam parë 85 projekte. Jo të gjitha ishin mikroshërbime (rreth një e treta deri gjysma e tyre kishin një arkitekturë të tillë), por ky është ende një numër i madh. Ne (kompania Flant) si kontraktorë arrijmë të shohim një shumëllojshmëri të gjerë aplikacionesh të zhvilluara si në kompanitë e vogla (me 5 zhvillues) ashtu edhe në ato të mëdha (~500 zhvillues). Një përfitim i shtuar është se ne i shohim këto aplikacione të gjalla dhe evoluojnë me kalimin e viteve.
Pse mikroshërbime?
Për pyetjen në lidhje me përfitimet e mikroshërbimeve ekziston nga Martin Fowler i përmendur tashmë:
- kufijtë e qartë të modularitetit;
- vendosje e pavarur;
- liria për të zgjedhur teknologjitë.
Kam folur shumë me arkitektë dhe zhvillues softuerësh dhe kam pyetur pse kanë nevojë për mikroshërbime. Dhe unë bëra listën time të pritjeve të tyre. Ja çfarë ndodhi:
Nëse përshkruajmë disa nga pikat "në ndjesi", atëherë:
- kufij të qartë të moduleve: këtu kemi një monolit të tmerrshëm, dhe tani gjithçka do të rregullohet mjeshtërisht në depot e Git, në të cilat gjithçka është "në rafte", e ngrohta dhe e buta nuk janë të përziera;
- pavarësia e vendosjes: ne do të jemi në gjendje të shpërndajmë shërbimet në mënyrë të pavarur në mënyrë që zhvillimi të shkojë më shpejt (publikimi i veçorive të reja paralelisht);
- Pavarësia e zhvillimit: ne mund t'ia japim këtë mikroshërbim një ekipi/zhvilluesi dhe atë njëri-tjetrit, falë të cilit ne mund të zhvillojmë më shpejt;
- боbesueshmëri më e madhe: nëse ndodh degradimi i pjesshëm (një mikroshërbim nga 20 bie), atëherë vetëm një buton do të ndalojë së punuari dhe sistemi në tërësi do të vazhdojë të funksionojë.
Arkitektura tipike (e dëmshme) e mikroshërbimit
Për të shpjeguar pse realiteti nuk është ai që presim, unë do të paraqes kolektive një imazh i një arkitekture mikroservice bazuar në përvojën nga shumë projekte të ndryshme.
Një shembull do të ishte një dyqan online abstrakt që do të konkurrojë me Amazon ose të paktën OZON. Arkitektura e tij e mikroshërbimit duket si kjo:
Për një kombinim arsyesh, këto mikroshërbime janë shkruar në platforma të ndryshme:
Meqenëse çdo mikroshërbim duhet të ketë autonomi, shumë prej tyre kanë nevojë për bazën e të dhënave dhe cache-in e tyre. Arkitektura përfundimtare është si më poshtë:
Cilat janë pasojat e saj?
Fowler e ka gjithashtu këtë - në lidhje me "pagesën" për përdorimin e mikroshërbimeve:
Dhe ne do të shohim nëse pritjet tona janë përmbushur.
Pastroni kufijtë e moduleve...
Por sa mikroshërbime duhet të rregullojmë në të vërtetë?për të nxjerrë ndryshimin? A mund të kuptojmë se si funksionon gjithçka pa një gjurmues të shpërndarë (në fund të fundit, çdo kërkesë përpunohet nga gjysma e mikroshërbimeve)?
Ka një model "", dhe këtu doli të ishte një gungë e shpërndarë papastërtie. Për ta konfirmuar këtë, këtu është një ilustrim i përafërt se si shkojnë kërkesat:
Pavarësia e dislokimit...
Teknikisht, ajo është arritur: ne mund të hapim çdo mikroshërbim veç e veç. Por në praktikë, duhet të keni parasysh që ajo shfaqet gjithmonë shumë mikroshërbime, dhe duhet ta kemi parasysh renditja e paraqitjes së tyre. Në një mënyrë të mirë, ne përgjithësisht duhet të testojmë në një qark të veçantë nëse po e nxjerrim lëshimin në rendin e duhur.
Liria për të zgjedhur teknologjinë...
Ajo është. Vetëm mos harroni se liria shpesh kufizohet me paligjshmërinë. Është shumë e rëndësishme këtu të mos zgjidhni teknologjitë vetëm për të "luajtur" me to.
Pavarësia e zhvillimit...
Si të bëni një lak testimi për të gjithë aplikacionin (me kaq shumë komponentë)? Por ju ende duhet ta mbani atë të përditësuar. E gjithë kjo çon në faktin se numri aktual i qarqeve testuese, të cilin ne në parim mund ta përmbajmë, rezulton të jetë minimale.
Po në lidhje me vendosjen e gjithë kësaj në nivel lokal?.. Rezulton se shpesh zhvilluesi e bën punën e tij në mënyrë të pavarur, por "rastësisht", sepse ai detyrohet të presë derisa qarku të jetë i lirë për testim.
Shkallëzimi i veçantë...
Po, por është i kufizuar në zonën e DBMS të përdorur. Në shembullin e dhënë të arkitekturës, Cassandra nuk do të ketë probleme, por MySQL dhe PostgreSQL do të kenë.
Боbesueshmëri më e madhe...
Jo vetëm që dështimi i një mikroshërbimi në realitet shpesh prish funksionimin korrekt të të gjithë sistemit, por ka edhe një problem të ri: është shumë e vështirë të bësh çdo mikro-service tolerant ndaj gabimeve. Për shkak se mikroshërbimet përdorin teknologji të ndryshme (memcache, Redis, etj.), Për secilën ju duhet të mendoni për gjithçka dhe ta zbatoni atë, gjë që, natyrisht, është e mundur, por kërkon burime të mëdha.
Matja e ngarkesës...
Kjo është vërtet e mirë.
"Lehtësia" e mikroshërbimeve...
Ne jo vetëm që kemi të mëdha sipërfaqja e rrjetit (kërkesat për DNS po shumëzohen, etj.), por edhe për shkak të shumë pyetjeve që kemi filluar të dhëna të përsëritura (memorie të ruajtura), të cilat çuan në një sasi të konsiderueshme të ruajtjes.
Dhe këtu është rezultati i përmbushjes së pritjeve tona:
Por kjo nuk është e gjitha!
Sepse:
- Me shumë mundësi do të na duhet një autobus mesazhesh.
- Si të bëni një kopje rezervë të qëndrueshme në momentin e duhur në kohë? I vetmi e vërtetë opsioni është të fikni trafikun për këtë. Por si ta bëjmë këtë në prodhim?
- Nëse po flasim për mbështetjen e disa rajoneve, atëherë organizimi i qëndrueshmërisë në secilin prej tyre është një detyrë shumë punë intensive.
- Problemi i bërjes së ndryshimeve të centralizuara lind. Për shembull, nëse na duhet të përditësojmë versionin PHP, do të na duhet të angazhohemi për çdo depo (dhe ka dhjetëra prej tyre).
- Rritja e kompleksitetit operacional është, e papritur, eksponenciale.
Çfarë duhet bërë me gjithë këtë?
Filloni me një aplikim monolit. Përvoja e Fowler se pothuajse të gjitha aplikacionet e suksesshme të mikroservisit filluan si një monolit që u bë shumë i madh dhe më pas u prish. Në të njëjtën kohë, pothuajse të gjitha sistemet e ndërtuara si mikroshërbime që në fillim, herët a vonë përjetuan probleme serioze.
Një mendim tjetër i vlefshëm është se që një projekt me arkitekturë mikroservice të jetë i suksesshëm, duhet ta dini shumë mirë dhe fusha lëndore, dhe si të bëhen mikroshërbime. Dhe mënyra më e mirë për të mësuar një fushë lëndore është të bëni një monolit.
Por çka nëse jemi tashmë në këtë situatë?
Hapi i parë për të zgjidhur çdo problem është të pajtohemi me të dhe të kuptojmë se është një problem, që nuk duam ta vuajmë më.
Nëse, në rastin e një monoliti të tejmbushur (kur na ka mbaruar mundësia për të blerë burime shtesë për të), e shkurtojmë atë, atëherë në këtë rast rezulton historia e kundërt: kur mikroshërbimet e tepërta nuk ndihmojnë më, por pengojnë - prerë tepricën dhe zmadhohet!
Për shembull, për imazhin kolektiv të diskutuar më sipër...
Hiqni qafe mikroshërbimet më të diskutueshme:
Kombinoni të gjitha mikroshërbimet përgjegjëse për gjenerimin e frontendit:
... në një mikroshërbim, të shkruar në një gjuhë/kornizë (moderne dhe normale, siç mendoni ju vetë):
Do të ketë një ORM (një DBMS) dhe së pari disa aplikacione:
... por në përgjithësi mund të transferoni shumë më tepër atje, duke marrë rezultatin e mëposhtëm:
Për më tepër, në Kubernetes ne i ekzekutojmë të gjitha këto në raste të veçanta, që do të thotë se ne ende mund të matim ngarkesën dhe t'i shkallëzojmë ato veç e veç.
Për të përmbledhur
Shikoni pamjen më të madhe. Shumë shpesh, të gjitha këto probleme me mikroshërbimet lindin sepse dikush mori detyrën e tij, por donte të "luante me mikroshërbimet".
Në fjalën "mikroshërbime" pjesa "mikro" është e tepërt.. Ata janë "mikro" vetëm sepse janë më të vegjël se një monolit i madh. Por mos i mendoni si diçka të vogël.
Dhe për një mendim përfundimtar, le të kthehemi në grafikun origjinal:
Një shënim i shkruar mbi të (lart djathtas) zbret në faktin se aftësitë e ekipit që bën projektin tuaj janë gjithmonë primare — ata do të luajnë një rol kyç në zgjedhjen tuaj midis mikroshërbimeve dhe një monolit. Nëse ekipi nuk ka aftësi të mjaftueshme, por fillon të bëjë mikroshërbime, historia do të jetë padyshim fatale.
Video dhe sllajde
Video nga fjalimi (~50 minuta; për fat të keq, nuk përcjell emocionet e shumta të vizitorëve, të cilat përcaktuan në masë të madhe humorin e raportit, por kështu është):
Prezantimi i raportit:
PS
Raporte të tjera në blogun tonë:
- «» (Dmitry Stolyarov; 28 maj 2018 në RootConf);
- «» (Dmitry Stolyarov; 7 nëntor 2017 në HighLoad++);
- «» (Dmitry Stolyarov; 6 qershor 2017 në RootConf);
- «» (Dmitry Stolyarov; 8 nëntor 2016 në HighLoad++);
- «» (Dmitry Stolyarov; 31 maj 2016 në RootConf).
Ju gjithashtu mund të jeni të interesuar në botimet e mëposhtme:
- «"?
- «"?
- «'.
Burimi: www.habr.com