🥇A mikroszolgáltatások: a méret számít, még ha Kubernetes-ed is van

Szeptember 19-én Moszkvában megtörtént az első HUG (Highload++ User Group) tematikus meet-up, amely a mikroszolgáltatásokra összpontosított. Ezen bemutattuk a "Mikroszolgáltatások üzemeltetése: a méret számít, még ha Kubernetes-ed is van" című előadást, amelyben megosztottuk a "Flant" cég széleskörű tapasztalatait a mikroszolgáltatás-architektúrával rendelkező projektek üzemeltetésében. Elsősorban a jelenlegi vagy jövőbeli projektjükben e megközelítést alkalmazó fejlesztők számára lesz hasznos.

Bemutatjuk videót az előadásról, (50 perc, sokkal információdúsabb, mint egy cikk), valamint annak fő összefoglalója szöveges formában.

NB: A videó és a prezentáció szintén elérhetők e publikáció végén.

Bevezetés

Általában egy jó történetnek van egy bevezetése, egy fő cselekménye és egy lezárása. Ez az előadás inkább a bevezetéshez hasonlít, és ráadásul tragikus. Fontos azt is megjegyezni, hogy a mikroszolgáltatásokra vonatkozó nézőpontot mutat be. kihasználás.

Egy ilyen grafikonnal kezdem, amelynek szerzője (2015-ben) lett Martin Fowler:

Ezen az ábrán látható, hogy egy monolitikus alkalmazás esetében, amikor elér egy bizonyos méretet, elkezd csökkenni a termelékenység. A mikroszolgáltatások esetében az eredeti termelékenység alacsonyabb, azonban a bonyolultság növekedésével az effektivitás csökkenése nem annyira észlelhető.

Kiegészítem ezt a grafikont a Kubernetes alkalmazásának esetére:

Miért lett jobb a mikroszolgáltatásokkal rendelkező alkalmazás? Mert ez az architektúra komoly követelményeket támaszt az architektúrával szemben, amelyeket a Kubernetes lehetőségei jól kielégítenek. Másrészt ennek a funkcionalitásnak egy része a monolit számára is hasznos lesz, különösen azért, mert a mai tipikus monolit nem teljesen monolitikus (részletek az előadás későbbi szakaszában).

Ahogy látható, a végső grafikon (amikor a monolitikus és a mikroszolgáltatásos alkalmazások egy Kubernetes infrastruktúrában vannak) nem igazán különbözik az eredetitől. A következő részben a Kubernetes használatával üzemeltetett alkalmazásokról lesz szó.

Jó és káros mikroszolgáltatás

A fő gondolat itt:

Mi is az normális mikroszolgáltatás-architektúra? Valódi előnyöket kell hoznia, növelve a munka hatékonyságát. Ha visszatérünk a grafikhoz, akkor itt van:

Ha elneveznénk hasznosnak, akkor a grafikon másik oldalán káros mikroszolgáltatás (akadályozza a munkát):

Visszatérve a „legfontosabb gondolatra”: érdemes egyáltalán bízni a tapasztalatommal? Az év eleje óta 85 projektet néztem meg. Nem mindegyik volt mikroszerviz (kb. a harmada és fele rendelkezett ilyen architektúrával), de ez így is nagy szám. A „Flant” cég számára, mint outsourcerek számára, lehetőségünk van széles spektrumú alkalmazásokat látni, amelyeket kis cégek (5 fejlesztő) és nagyobbak (~500 fejlesztő) fejlesztenek. További előny, hogy látjuk, hogyan élnek és fejlődnek ezek az alkalmazások évek során.Miért mikroszervizek?

A mikroszervizek előnyeire vonatkozó kérdésre van

egy meglehetősen konkrét válasz a már említett Martin Fowler szerint: világos moduláris határok;

független telepítés;
technológiai választás szabadsága.
Sok szoftverarchitektával és fejlesztővel beszélgettem, és megkérdeztem, miért van szükségük mikroszervizekre. Összeállítottam egy listát az elvárásaikról. Íme, ami kiderült:

Ha „érzésekben” le kellene írnom néhány pontot, akkor:

világos modulhatárok: itt van egy borzasztó monolitunk, most pedig minden szépen el lesz rendezve Git-repósokban, ahol minden „a helyén van”, nincsenek összekeverve a puha és a meleg;

a telepítés függetlensége: képesek leszünk a szolgáltatásokat függetlenül kiadni, így a fejlesztés gyorsabb lesz (párhuzamosan publikálva új funkciókat);
a fejlesztés függetlensége: ezt a mikroszervizt átadhatjuk annak a csapatnak/fejlesztőnek, a másikat pedig egy másiknak, amely lehetővé teszi számunkra a gyorsabb fejlesztést;
nagyobb megbízhatóság: ha részleges degradáció történik (az egyik mikroszerviz 20-ból leáll), akkor csak egy gomb nem fog működni, míg a rendszer összességében továbbra is működőképes marad.
bóJellemző (káros) mikroszerviz architektúra

Annál, hogy megmagyarázzam, miért nem mindig úgy van a valóságban, mint ahogy azt várjuk, bemutatok

egy összegző képet a mikroszerviz architektúráról, amely számos különböző projekt tapasztalataira épül. Egy példa szolgál majd absztrakt internetes bolt, amely az Amazonnal vagy legalább az OZON-nal kíván versenyezni. Ennek a mikroszerviz architektúrája így néz ki:

Sokféle okból ezek a mikroszervizek különböző platformokon készültek:

Mivel minden mikroszerviznek autonómiával kell rendelkeznie, sokuknak saját adatbázisra és cache-re van szüksége. A végső architektúra a következő:

Mivel minden mikroszerviznek önállónak kell lennie, soknak saját adatbázisra és gyorsítótárra van szüksége. Az végső architektúra a következőképpen alakul:

Mikroszolgáltatásoknak milyen következményei vannak?

Fowler szerint ezzel kapcsolatban van egy cikk — a mikroszolgáltatások használatának „fizetéséről”:

Megnézzük, beváltják-e a reményeinket.

A modulok világos határai...

sokkal hasznosabb kulcsokkal használni: hány mikroszolgáltatást kell valójában módosítanunk, hogy kiadhassunk egy változtatást? Tudunk-e egyáltalán boldogulni, ha nincs elosztott nyomkövetőnk (hiszen minden kérés a mikroszolgáltatások felének feldolgozása alatt áll)?

Létezik a „nagy mocskos golyó” mintázat, de itt egyenesen egy elosztott mocsokgömb jött létre. Íme egy példa arra, hogyan zajlanak a kérések:

A telepítések függetlensége...

Technikailag elérjük: minden mikroszolgáltatást külön-külön újratelepíthetünk. De a gyakorlatban figyelembe kell venni, hogy mindig számos mikroszolgáltatás kerül kiadásra. számos mikroszolgáltatást, és figyelembe kell venni a kibocsátásuk sorrendjét.Ideális esetben külön környezetben kell tesztelnünk, hogy helyes sorrendben adjuk-e ki a kiadást.

A technológiai választás szabadsága...

Ez létezik. Csak ne felejtsük el, hogy a szabadság gyakran anarchiába ütközik. Nagyon fontos, hogy ne válasszunk technológiákat csupán azért, hogy „játszunk” velük.

A fejlesztés függetlensége...

Hogyan készíthető tesztkörnyezet az egész alkalmazás számára (ennyi komponensből)? És még naprakészen kell tartani. Mindez odavezet, hogy a tényleges tesztkörnyezetek száma, amelyeket egyáltalán fenntarthatunk, mínimálisnak bizonyul..

És hogy mindezt helyben telepíthessük?... Ezért sok esetben a fejlesztő függetlenül végzi a munkáját, de „véletlenszerűen”, mert várnia kell, amíg felszabadul egy tesztkör.

Külön skálázhatóság...

Igen, de ez korlátozott a felhasznált DBMS-ek terén. A megadott architektúrában nem lesz probléma a Cassandrával, de a MySQL és PostgreSQL esetében problémák merülnek fel.

Bóövekező megbízhatóság...

Nemcsak azért, mert egy mikroszolgáltatás meghibásodása gyakran az egész rendszer működését megzavarja, de újabb probléma is felmerül: nagyon nehéz hibatűrővé tenni minden mikroszolgáltatást.Mert a mikroszolgáltatások különböző technológiákat (memcache, Redis stb.) használnak, mindegyikhez alaposan kell tervezni és megvalósítani, ami természetesen lehetséges, de hatalmas erőforrásokat igényel.

A terhelhetőség mérése…

Ezzel valóban minden rendben van.

A mikroszolgáltatások „könnyedsége”…

Nálunk nemcsak hatalmas hálózati költségek jelentek meg (a DNS-kérések és hasonlók felhalmozódnak), hanem a rengeteg al-kérdés miatt elkezdtük adatokat replikálni (cache-ket tárolni), ami jelentős tárolási mennyiséget eredményezett.

És itt van az eredménye az elvárásainkhoz való viszonyulásnak:

De ez még nem minden!

Mert:

Valószínűleg szükségünk lesz üzenetbuszra.
Hogyan lehet konzisztens biztonsági másolatot készíteni egy adott időpontban? Az egyetlen valódi lehetőség — leállítani a forgalmat ehhez. De hogyan tegyük ezt production környezetben?
Ha több régió támogatásáról van szó, akkor a stabilitás megszervezése mindegyikben — nagyon munkaigényes feladat.
Megjelenik a központosított változtatások bevezetésének problémája. Például, ha frissíteni kell a PHP verziót, akkor minden egyes tárolóban (amelyek számosan vannak) el kell végezni a commitot.
Az operatív bonyolultság növekedése első pillantásra exponenciálisnak tűnik.

Mit tegyünk mindezzel?

Kezdjünk egy monolitikus alkalmazással. Fowler tapasztalata mondja arról, hogy szinte minden sikeres mikroszolgáltatásos alkalmazás monolitból indult, amely túl naggyá vált, majd azután szétszedték. Ugyanakkor szinte minden rendszer, amelyet eredetileg mikroszolgáltatásként építettek fel, előbb-utóbb komoly problémákkal szembesült.

Még egy értékes gondolat — ahhoz, hogy egy mikroszolgáltatásos architektúrájú projekt sikeres legyen, nagyon jól kell ismerni mind a szakterületet, mind pedig a mikroszolgáltatások készítésének módját. A legjobb módja a szakterület megismerésének — készíteni egy monolitot.

De mi a teendő, ha már ilyen helyzetben vagyunk?

Az első lépés bármilyen probléma megoldásához — elfogadni, hogy ez probléma, és megérteni, hogy többet nem akarunk szenvedni.

Ha a túlnőtt monolittal (amikor már nem tudunk további erőforrásokat vásárolni) szétvágjuk, akkor ebben az esetben fordított a helyzet: amikor a túlzott mikroszolgáltatás már nem segít, hanem hátráltat — vágd le a felesleget és csoportosítsd!

Például a fent említett gyűjtőképre…

Szabadulj meg a legkétségesebb mikroszolgáltatásoktól:

Egyesítsd az összes mikroszolgáltatást, amelyek a frontend generálásáért felelnek:

… egy mikroszolgáltatásba, amely egy (modern és normális, ahogy magad is gondolod) nyelven/keretrendszeren íródott:

Egy ORM-je (egy DBMS) lesz, és eleinte pár alkalmazás:

… de valójában sokkal többet is át lehet vinni, ez a végeredmény:

A Kubernetesben mindezt külön példányokként indítjuk el, ami azt jelenti, hogy még mindig mérhetjük a terhelést és külön skálázhatjuk őket.

Összefoglalva

Nézz a kérdésre tágabb értelemben. Nagyon gyakran ezek a mikroszolgáltatásokkal kapcsolatos problémák azért merülnek fel, mert valaki átvette a feladatát, de "mikroszolgáltatásokkal" akarta játszani.

A "mikroszolgáltatások" szónak a "mikro" része felesleges. Csak azért "mikro", mert kisebbek, mint egy hatalmas monolit. De ne gondoljunk rájuk úgy, mint valami kicsire.

És a végső gondolatunkhoz visszatérve az eredeti grafikonhoz:

Az ahhoz írt megjegyzés (jobbra fent) arra összpontosít, hogy a csapat készsége, amely a projektedet készíti, mindig elsődleges — ők játszanak kulcsszerepet a mikroszolgáltatások és a monolit közötti választásban. Ha a csapat nem rendelkezik elegendő tudással, de elkezd mikroszolgáltatásokat készíteni, a történet biztosan végzetes lesz.

Videók és diák

Videó az előadásról (~50 perc; sajnos nem tudja visszaadni a látogatók számos érzelmét, ami nagymértékben befolyásolta az előadás hangulatát, de ez van):