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

19 Shtatori në Moskë u organizua mitapi i parë tematik HUG (Grupi i Përdoruesve të Highload++), i cili u përkushtua mikroshërbimeve. Në të u propozuar referati “Eksplorimi i mikroshërbimeve: madhësia ka rëndësi, edhe nëse keni Kubernetes”, ku ndamë përvojën e gjerë të kompanisë “Flant” në fushën e eksplorimit të projekteve me arkitekturë mikroshërbimesh. Në radhë të parë, ai do të jetë i dobishëm për të gjithë zhvilluesit që po mendojnë për aplikimin e këtij qasje në projektin e tyre aktual ose të ardhshëm.

Paraqesim video me referatin (50 minuta, shumë më informuese se artikulli), si dhe një përmbledhje kryesore prej tij në format tekstual.

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

Hyrje

Zakonisht një histori e mirë ka një fillim, një ngjarje kryesore dhe një përfundim. Ky referat është më shumë si një fillim, madje tragjik. Gjithashtu, është e rëndësishme të theksohet se ai ofron një këndvështrim mbi mikroshërbimet nga këndvështrimi shfrytëzimin.

Do ta filloj me një grafik të tillë, i cili është bërë nga (në vitin 2015) u bë Martin Fowler:

Në të duket se, në rastin e aplikacioneve monolitike, pasi të arrijë një madhësi të caktuar, produktiviteti i punës fillon të bie. Mikroshërbimet ndryshojnë sepse produktiviteti fillestar me to është më i ulët, megjithatë, ndërsa rritet kompleksiteti, degradimi i efikasitetit për ta nuk është aq i dukshëm.

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

Pse një aplikacion me mikroshërbime ka filluar të funksionojë më mirë? Sepse një arkitekturë e tillë imponon kërkesa serioze për arkitekturën, të cilat nga ana e tyre mbyllen shkëlqyeshëm me mundësitë e Kubernetesit. Nga ana tjetër, një pjesë e kësaj funksionaliteti do të jetë e dobishme edhe për monolit, sidomos për arsyen se monoliti tipik në ditët e sotme nuk është krejtësisht monolit (detaje do të jepen më tej në referat).

Siç shihet, grafiku përfundimtar (kur edhe aplikacionet monolitike, edhe ato mikroshërbime janë në infrastrukturën me Kubernetes) nuk ndryshon shumë nga origjinali. Më vonë do të flasim për aplikacionet që janë eksploruar duke përdorur Kubernetesin.

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

Dhe këtu mendimi kryesor:

Çfarë është arkitektura normale

mikroshërbimore? Ajo duhet t'ju sjellë vlerë të vërtetë duke rritur efikasitetin e punës. Nëse kthehemi te grafiku, ja ajo: e dobishmeNëse e quajmë , atëherë në anën tjetër të grafikut do të jetë mikroshërbim i dëmshëm (pengon punën):

Duke u kthyer te "nëna kryesore": a ia vlen të besojmë përvojën time? Nga fillimi i këtij viti, kam parë 85 projekte. Jo të gjithë ishin mikrosërvise (një arkitekturë e tillë kishin rreth një të tretën deri në gjysmën e tyre), por prapë është një numër i madh. Ne (kompania "Flant") si outsourcerë arrijmë të shohim një larmi të gjerë aplikacionesh, të zhvilluara si në kompanitë e vogla (me 5 zhvillues), ashtu edhe në ato të mëdha (~500 zhvillues). Një plus tjetër është se ne shohim si këto aplikacione jetojnë dhe zhvillohen për shumë vite.

Pse mikrosërvise?

Për pyetjen në lidhje me përfitimet e mikrosërvisit, ka një përgjigje mjaft të saktë nga Martin Fowler i përmendur më parë:

kufij të qartë modulariteti;
depozim të pavarur;
liri për të zgjedhur teknologjitë.

Kam biseduar shumë me arkitektë dhe zhvillues të softuerit dhe i kam pyetur se për çfarë u duhen mikrosërvicat. Dhe kam hartuar një listë të pritshmërive të tyre. Këtu është ajo që dolëm:

Nëse përshkruajmë "në ndjenja" disa nga pikët, do të jetë:

kufij të qartë modulare: ja ku kemi një monolit të frikshëm, ndërsa tani gjithçka do të jetë e rregullt në Git-repozita, ku gjithçka është "në rafte", pa e përzier ngrohtësi me butësi;
pavarësia e depolimit: do të jemi në gjendje të nxjerrim shërbime në mënyrë të pavarur, në mënyrë që zhvillimi të shkojë më shpejt (të publikohen gjithashtu funksionalitete të reja paralelisht);
pavarësia në zhvillim: ne mund t'i japim këtë mikrosërvicë asaj skuadre/zhvilluesi, ndërsa ai tjetri një tjetër, duke na lejuar të zhvillojmë më shpejt;
bobesueshmëri më e madhe: nëse ndodh një degradim i pjesshëm (bllokohet një mikrosërvicë nga 20), atëherë do të ndalojë të funksionojë vetëm një buton, ndërsa sistemi në tërësi do të vazhdojë të funksionojë.

Arkitektura tipike (e dëmshme) e mikrosërvicave

Për të shpjeguar pse në realitet gjithçka nuk është ashtu siç presim, do të prezantoj një imagjinatën e arkitekturës së mikrosërvicave, e bazuar në përvojën nga shumë projekte të ndryshme.

Një shembull do të shërbejë si një dyqan në internet abstrakt, që ka për qëllim të konkurronte me Amazon ose të paktën me OZON. Arkitektura e tij mikrosërvicash duket kështu:

Për një seri arsyesh, këto mikrosërvica janë shkruar në platforma të ndryshme:

Duke pasur parasysh se çdo mikrosërvicë duhet të ketë autonomi, shumë prej tyre kanë nevojë për bazën e tyre të dhënash dhe cache. Arkitektura përfundimtare duket e tillë:

Cilat janë pasojat e saj?

Fowler ka një artikull në këtë lidhje — për "pagesën" për përdorimin e mikroshërbimeve: Do të shohim nëse pritshmëritë tona janë përmbushur.

Kufijtë e qartë të moduleve...

sa mikroshërbime na nevojiten në të vërtetë për të bërë një ndryshim?

Por A mund të kuptojmë si funksionon gjithçka pa një gjurmues të shpërndarë (sepse çdo kërkesë përpunojë nga gjysmën e mikroshërbimeve)?Ekziston një model "

një grumbull i madh pisllëku", dhe këtu në fakt kemi rezultuar në një grumbull të shpërndarë pisllëku. Si dëshmi për këtë — ja një ilustrim i përafërt se si kalojnë kërkesat:Pavarësia e deploy-it...

Në teori është arritur: ne mund të rikthejmë çdo mikroshërbim veçmas. Por në praktikë, duhet të kemi parasysh se gjithmonë deploy-ohen

shumë mikroshërbime , dhe na nevojitet të marrim parasyshrendin e deploy-it të tyre . Në të vërtetë, do të ishte më mirë të testonim në një kontur të veçantë, nëse po e deploy-ojmë versionin në rendin e duhur.Liria e zgjedhjes së teknologjisë...

ekziston. Por është e rëndësishme të kujtojmë se shpesh liria kufizohet me kaos. Është shumë e rëndësishme këtu të mos zgjidhni teknologji vetëm për t'u "luajtur" me to.

Pavarësia e zhvillimit...

Si të krijosh një kontur testimi për të gjithë aplikacionin (nga një numër kaq të madh komponentësh)? Por gjithashtu duhet ta mbash atë të azhurnuar. Të gjitha këto çojnë në atë që

numri i vërtetë i kontureve të testimit , që mund të mbajmë në parim,është minimal Por si të zhvillojmë gjithçka këtë lokal? Bëhet fjalë që shpesh zhvilluesi e bën punën e tij në mënyrë të pavarur, por "në errësirë", sepse është i detyruar të presë kur konturi për testim të jetë i lirë..

Shkallëzimi i ndarë...

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

Një

çmë e madhe e besueshmërisë...oJo vetëm që në të vërtetë, dështimi i një mikroshërbimi shpesh prish funksionimin e duhur të gjithë sistemit, por ka edhe një problem të ri:

të bësh çdo mikroshërbim të qëndrojë i besueshëm është shumë e vështirë. Sepse në mikroshërbime përdoren teknologji të ndryshme (memcache, Redis etj.), për secilin duhet të mendosh gjithë planin dhe të realizosh, gjë që natyrisht është e mundur, por kërkon burime të mëdha.. Sepse në mikroshërbime përdoren teknologji të ndryshme (memcache, Redis etj.), për çdo njëri duhet të mendohet dhe të realizohet gjithçka, që, sigurisht, është e mundur, por kërkon burime te mëdha.

Matja e ngarkesës…

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

Lehtësia e mikroshërbimeve…

Ne jo vetëm që kemi krijuar një sasi të madhe të shpenzimeve rrjetësore (rritja e kërkesave për DNS dhe të tjerë), por gjithashtu për shkak të shumë nënkërkesave filluam të replikojmë të dhënat (të ruajmë cache), që çoi në një sasi të konsiderueshme ruajtjeje.

Dhe ja si duket përputhja me pritjet tona:

Por kjo nuk është e gjitha!

Sepse:

Mund të na nevojitet një autobus mesazhesh.
Si të bëni një backup konsistent në momentin e duhur? E vetmja mundësi reale është të ndalosh trafikun për këtë. Por si ta bësh këtë në production?
Kur flitet për mbështetje të disa rajoneve, organizimi i qëndrueshmërisë në secilin prej tyre është një detyrë shumë e lodhshme.
Shfaqet problemi i bërjes së ndryshimeve të centralizuara. Për shembull, nëse na duhen të përditësojmë versionin e PHP, do të nevojitet të bëjmë një komit në çdo repository (dhe ata janë dhjetëra).
Rritja e kompleksitetit operativ duket se është eksponenciale.

Çfarë të bëjmë me gjithë këtë?

Filloni me një aplikacion monolit. Përvoja e Fowler-it SETUP.EXE: ekzekutues MS-DOS, NE për MS Windows 3.x tregon se pothuajse të gjitha aplikacionet e suksesshme mikroshërbimore kanë filluar si një monolit që u bë shumë i madh dhe më pas u përsërit. Në të njëjtën kohë, pothuajse të gjitha sistemet që janë ndërtuar si mikroshërbore nga fillimi, për një kohë të shkurtër hasin probleme serioze.

Një mendim tjetër i çmuar është se për të pasur sukses me një projekt me arkitekturë mikroshërbimesh, duhet të njihni shumë mirë ose fushën e subjektit, dhe si të bëni mikroshërbime. Dhe mënyra më e mirë për të mësuar fushën e subjektit ë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 zgjidhjen e çdo problemi është të pranosh atë dhe të kuptosh që është një problem, që ne nuk duam të vuajmë më.

Në rastin e një monoliti të zgjeruar (kur na kanë mbaruar mundësitë për të blerë resurse për të), ne e presim atë, por në këtë rast, historia është e kundërt: kur mikroshërbimi i tepruar nuk ndihmon më, por pengon— prishni atë të tepruar dhe bashkoni!

Për shembull, për pamjen kolektive të përmendur më sipër…

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

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

… në një mikroshërbim, i shkruar në një (moderne dhe të përshtatshme, siç mendoni vetë) gjuhë/kornizë:

Ai do të ketë një ORM (një DBMS) dhe fillimisht disa aplikacione:

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

Dhe në Kubernetes, ne i lançojmë të gjitha këto si instanca të veçanta, që do të thotë se ne ende mund të masim ngarkesën dhe t'i shkallëzojmë ato veçmas.

Përmbledhje

Shikoni fotografinë më gjerë. 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.. Ato janë "mikro" vetëm sepse janë më të vogla se një monolit i madh. Por nuk duhet t'i shikoni ato si diçka të vogël.

Dhe për mendimin përfundimtar, le të kthehemi te grafikoni origjinal:

Vërejtja e shkruar për të (në të djathtë lart) reduktuar në atë që aftësitë e ekipit që bën projektin tuaj, janë gjithmonë primare — ato do të luajnë rolin kryesor në zgjedhjen tuaj midis mikroshërbimeve dhe monolitit. Nëse ekipi nuk ka aftësi, por fillon të krijojë mikroshërbime, historia do të jetë përfundimtare.

Videot dhe slidet

Video e prezantimit (~50 minuta; fatkeqësisht, ajo nuk përcjell emocionet e shumta të vizitorëve, të cilat e formësuan shumë atmosferën e prezantimit, por ashtu si është):