🥇Mikroshërbimet: madhësia ka rëndësi, edhe nëse keni Kubernetes

19 Shtatori në Moskë u mbajt takimi i parë tematik HUG (Highload++ User Group), i dedikuar mikroshërbimeve. Gjatë tij u mbajt një diskutim mbi "Exploatimi i mikroshërbimeve: madhësia ka rëndësi, edhe nëse keni Kubernetes", ku ne ndamë përvojën e gjerë të kompanisë "Flant" në fushën e menaxhimit të projekteve me arkitekturë mikroshërbimesh. Në radhë të parë, do të jetë e dobishme për të gjithë zhvilluesit që mendojnë për aplikimin e këtij qasjeje në projektin e tyre aktual ose të ardhshëm.

Prezantimi video me referatin (50 minuta, shumë më informative se një artikull), si dhe një përmbledhje të tij në formë tekstuale.

NB: Videoja dhe prezantimi janë gjithashtu në fund të kësaj publikimi.

Hyrje

Normalisht, një histori e mirë ka një fillim, një mes dhe një fund. Ky diskutim më shumë ngjan me një fillim, dhe madje me një tragjedi. Gjithashtu, është e rëndësishme të theksohet se në të paraqitet një këndvështrim për mikroshërbimet nga ana eksploatimi.

Do të filloj me një grafik të tillë, autori i të cilit është (në vitin 2015) u bë Martin Fowler:

Në këtë grafik, shikohet se në rastin e një aplikacioni monolit, pasi arrin një madhësi të caktuar, fillon të bie produktiviteti. Mikroshërbimet karakterizohen nga prodhimi fillestar më i ulët, por me rritjen e komplikeve, degradimi i efikasitetit për to nuk është aq i dukshëm.

Do ta plotësoj këtë grafik për rastin e përdorimit të Kubernetes:

Pse një aplikacion me mikroshërbime bëhet më i mirë? Sepse një arkitekturë e tillë imponon kërkesa të forta për arkitekturën, të cilat nga ana e tyre sigurohen mirë nga mundësitë e Kubernetes. Nga ana tjetër, disa nga këto funksionalitete do të jenë të dobishme edhe për monolit, veçanërisht për shkak se monoliti tipik sot nuk është krejtësisht monolit (detajet do të sillen më vonë në diskutim).

Siç shihet, grafiku përfundimtar (kur si aplikacionet monolitike dhe ato mikroshërbime ndodhen në infrastrukturën me Kubernetes) nuk ndryshon shumë nga origjinali. Më pas do të flasim për aplikacionet që operohen duke përdorur Kubernetes.

Mikroshërbimi i dobishëm dhe i dëmshëm

Dhe këtu mendimi kryesor:

Çfarë është arkitektura normale

mikroshërbimore? Ajo duhet t'ju sjellë përfitime reale, duke rritur efikasitetin. Nëse kthehemi në grafik, ja ajo: e dobishmeNëse e quajmë tjetra mikroshërbim i dëmshëm (pengon punën):

Duke u rikthyer në "mendimin kryesor": a duhet të besoni përvojën time? Që nga fillimi i vitit, kam parë 85 projekte. Jo të gjithë ishin mikroshërbime (kjo arkitekturë kishin rreth një të tretë deri në gjysmën e tyre), por gjithsesi është një numër i madh. Ne (kompania "Flant") si outsourcerë arrijmë të shikojmë një larmi të gjerë aplikacionesh, që zhvillohen si në kompani të vogla (me 5 zhvillues), ashtu edhe në të mëdha (~500 zhvillues). Një plus tjetër është se ne shohim si këto aplikacione jetojnë dhe evolucionojnë për një periudhë të gjatë kohe.

Pse mikroshërbimet?

Në pyetjen për dobinë e mikroshërbimeve ka një përgjigje të qartë nga Martin Fowler:

kufij të qartë modulariteti;
depo të pavarura;
liri për zgjedhjen e teknologjive.

Kam biseduar shumë me arkitektë dhe zhvillues softuerësh dhe kam pyetur se përse u duhen mikroshërbimet. Dhe kam hartuar një listë të pritshmërive të tyre. Ja çfarë rezultoi:

Nëse përshkruaj mendimet për disa nga pikat, atëherë:

kufij të qartë për modulet: ja ku kemi një monolit të frikshëm, dhe tani gjithçka do të rregullohet në Git-repozita, ku gjithçka është "në rafte", pa i përzier gjërat e ngrohta me ato të buta;
pavarësi e depozitimit: ne mund të publikojmë shërbimet në mënyrë të pavarur, në mënyrë që zhvillimi të shkojë më shpejt (të publikojmë paralel karakteristika të reja);
pavarësi në zhvillim: ne mund t'ia japim këtë mikroshërbim një ekipi/zhvilluesi, dhe atë tjetër të dikujt tjetër, duke na lejuar të zhvillojmë më shpejt;
bobesueshmëri më e lartë: nëse ndodh një degradim i pjesshëm (dofësh një mikroshërbim nga 20), atëherë do të ndaloni të punoni vetëm një buton, ndërsa sistemi në tërësi do të vazhdojë të funksionojë.

Arkitektura tipike (dëmshme) e mikroshërbimeve

Për të shpjeguar pse në realitet gjithçka nuk është ashtu siç e presim, do të paraqes një pamje kolektive të arkitekturës mikroshërbimore, duke u bazuar në përvojën nga shumë projekte të ndryshme.

Për shembull, do të shërbejë një dyqan të abstarcizuar në internet, që dëshiron të konkurrojë me Amazon ose të paktën me OZON. Arkitektura e tij mikroshërbimore duket kështu:

Për një sërë arsye, këto mikroshërbime janë shkruar në platforma të ndryshme:

Pasi çdo mikroshërbim duhet të ketë autonominë e tij, shumë prej tyre kanë nevojë për bazën e tyre të të dhënave dhe për një cache. Arkitektura përfundimtare rezulton të jetë si më poshtë:

Cilat janë pasojat e saj?

Për këtë Martin Fowler ka një mendim ka një artikull — mbi "pagesën" për përdorimin e mikroshërbimeve:

Dhe ne do të shohim nëse pritshmëritë tona janë realizuar.

Kufij të qartë të moduleve...

Por sa mikroshërbime duhet të rregullojmë në të vërtetë, në mënyrë që të nxjerrim ndryshimin? A mund të kuptojmë në të vërtetë se si funksionon gjithçka, pa një ndjekës të shpërndarë (sepse çdo kërkesë përpunohen nga gjysma e mikroshërbimeve)?

Ekziston një model "topi i madh i papastërtive", dhe këtu madje kemi ndarjen e një topi të shpërndarë të papastërtive. Si një dëshmi — ja një ilustrim i përafërt se si kalojnë kërkesat:

Pavarësia e shpërndarjes...

Në aspektin teknologjik, ajo është arritur: ne mund të nxjerrim çdo mikroshërbim veçmas. Por në praktikë, është e nevojshme të merret parasysh se gjithmonë nxirren një numër të madh mikroshërbimesh, dhe na nevojitet të marrim parasysh rendin e shpërndarjes. Në mënyrë të duhur, ne duhet në të vërtetë të testojmë në një rreth të veçantë nëse ne po nxjerrim lëshimin në rendin e duhur.

Liria e zgjedhjes së teknologjisë...

Ekziston. Thjesht duhet të mbani mend se shpesh liria kufizohet me kaos. Është shumë e rëndësishme të mos zgjidhni teknologji vetëm për të "luajtur" me to.

Pavarësia e zhvillimit...

Si të krijoni një rreth testimi për të gjithë aplikacionin (nga një sasi kaq e madhe komponentësh)? Dhe megjithatë, duhet ta mbani atë në formë aktuale. E gjithë kjo çon në faktin se numri real i ritheve testuese, që ne në parim mund të mbajmë, ka rezultuar minimal.

Por a mund ta zhvillosh të gjithë këtë lokal? Del se shpesh zhvilluesi bën punën e tij në mënyrë të pavarur, por "në errësirë", sepse është i detyruar të presë kur të lirohet rrethi për testim.

Zgjerimi i ndarë...

Po, por është i kufizuar në fushën e DBMS-ve të përdorura. Në shembullin e dhënë, arkitektura nuk do të ketë probleme me Cassandra, por do të ketë me MySQL dhe PostgreSQL.

Mobesnikë më të mëdhenj...

Jo vetëm që në të vërtetë prishja e një mikroshërbimi shpesh dëmton funksionimin normal të gjithë sistemit, ka edhe një problem të ri: bërja e çdo mikroshërbimi të qëndrueshëm është shumë e vështirë. Sepse në mikroshërbime përdoren teknologji të ndryshme (memcache, Redis, etj.), për çdo njëra duhet të mendohet dhe të realizohet gjithçka, që natyrisht është e mundur, por kërkon burime të gjera.

Madhësia e ngarkesës...

Me këtë, gjithçka vërtet është mirë.

"Lehtësia" e mikroshërbimeve...

Ne jo vetëm që kemi pasur një rritje të madhe të kostove të rrjetit (kërkesat për DNS etj.), por për shkak të shumë nënkërkesave, ne filluam të replicojmë të dhënat (të ruajmë cache), që çoi në një volum të konsiderueshëm ruajtjeje.

Dhe ja cilat janë përputhjet me pritshmëritë tona:

Por edhe kjo nuk është e gjitha!

Sepse:

Me siguri do të na duhej një autobus mesazhesh.
Si të bëni një kopje të qëndrueshme në momentin e duhur? Opsioni i vetëm real është të ndaloni trafikun për këtë. Por si ta bëni këtë në production?
Nëse flasim për mbështetje në disa rajone, organizimi i qëndrueshmërisë në secilin nga ato është një detyrë shumë e ngarkuar.
Shfaqet problemi i bërjes së ndryshimeve qendrore. Për shembull, nëse na nevojitet të azhurnojmë versionin e PHP, do të kërkohet të bëjmë një commit në çdo repozitor (dhe ata janë dhjetëra).
Rritja e kompleksitetit operativ duket se është eksponenciale.

Çfarë të bëjmë me të gjitha këto?

Filloni me një aplikacion monolitik. Eksperienca e Fowler-it thotë se pothuajse të gjitha aplikacionet e suksesshme të mikroshërbimeve kanë filluar si monolite, të cilat janë bërë shumë të mëdha dhe pastaj janë copëtuar. Në të njëjtën kohë, pothuajse të gjitha sistemet e ndërtuara si mikroshërbime nga fillimi kanë përjetuar probleme serioze herët a vonë.

Një mendim tjetër i vlefshëm është që për të pasur sukses në një projekt me arkitekturë mikroshërbimesh, duhet të dini shumë mirë si fushën e subjekteve ashtu edhe si të bëni mikroshërbime. Një nga mënyrat më të mira për të mësuar fushën e subjekteve është të bëni një monolit.

Por çfarë të bëjmë nëse tashmë jemi në një situatë të tillë?

Hapi i parë për të zgjidhur çdo problem është të pranojmë atë dhe të kuptojmë se është një problem, se nuk duam të vuajmë më.

Nëse në rastin e një monoliti të zgjeruar (kur na është mbaruar mundësia për të blerë burime për të), ne e presim atë, në këtë rast ka një histori të kundërt: kur mikroshërbimi i tepruar tashmë nuk ndihmon, por pengon — priteni të tepërta dhe bashkoni!

Për shembull, për imazhin e përmendur më sipër...

Shkëputni mikroshërbimet më të dyshuara:

Bashkoni të gjitha mikroshërbimet që janë përgjegjëse për gjenerimin e frontend-it:

... në një mikroshërbim, të shkruar në një (moderne dhe normale, siç e mendoni ju) gjuhë/framë.

Ai do të ketë një ORM (një DBMS) dhe fillimisht një çift aplikacionesh:

… por në të vërtetë, mund të transferoni shumë më tepër, duke arritur një rezultat të tillë:

Në Kubernetes, ne i nisnim gjithçka si instanca të veçanta, çka nënkupton se ne ende mund të matim ngarkesën dhe t’i shkallëzojmë ato ndarazi.

Përmbledhur

Shikoni peizazhin më gjerë. Shumë shpesh, të gjitha këto probleme me mikroshërbimet ndodhin për shkak se dikush ka marrë detyrën e tij, por ka dashur "të luajë me mikroshërbimet".

Pjesa "mikro" në fjalën "mikroshërbime" është e panevojshme. Ata janë "mikro" vetëm sepse janë më të vogla se një monolit i madh. Por nuk duhet të mendoni për ta si diçka të vogël.

Dhe për mendimin përfundimtar, le të kthehemi në grafikën fillestare:

Shënimi i shkruar për të (në të djathtë sipër) redukohet në atë që aftësitë e ekipit që bën projektin tuaj, gjithmonë janë primare — ato do të luajnë një rol kyç në zgjedhjen tuaj midis mikroshërbimeve dhe monolitit. Nëse ekipit i mungojnë aftësitë, por fillon të krijojë mikroshërbime, historia do të jetë përfundimtare.

Video dhe prezentime

Video nga ligjërata (~50 minuta; fatkeqësisht, ajo nuk kap shumë emocionet e vizitorëve, të cilat kryesisht përcaktuan humorin e ligjëratës, por ashtu siç është):