szeptember 19-én Moszkvában az első tematikus találkozó a HUG (Highload++ User Group), amelyet a mikroszolgáltatásoknak szenteltek. Volt egy „Operating Microservices: Size Matters, Even If You Have Kubernetes” című előadás, amelyben megosztottuk Flant széleskörű tapasztalatait a mikroszolgáltatási architektúrával végzett projektek üzemeltetésében. Mindenekelőtt minden fejlesztő számára hasznos lesz, aki ezen a megközelítésen gondolkodik jelenlegi vagy jövőbeli projektjeiben.
Bemutatkozik (50 perc, sokkal informatívabb, mint a cikk), valamint a fő kivonat belőle szöveges formában.
Megjegyzés: Videó és prezentáció is elérhető a bejegyzés végén.
Bevezetés
Általában egy jó történetnek van eleje, fő cselekménye és megoldása. Ez a jelentés inkább egy előjáték, és egyben tragikus is. Fontos megjegyezni azt is, hogy kívülálló képet ad a mikroszolgáltatásokról. kizsákmányolás.
Ezzel a grafikonnal kezdem, amelynek szerzője (2015-ben) Martin Fowler:
Megmutatja, hogy egy bizonyos értéket elérő monolitikus alkalmazás esetén hogyan kezd csökkenni a termelékenység. A mikroszolgáltatások annyiban különböznek egymástól, hogy alacsonyabb velük a kezdeti termelékenység, de a komplexitás növekedésével a hatékonyság romlása nem annyira észrevehető náluk.
Ezt a grafikont a Kubernetes használatához adom hozzá:
Miért jobb egy mikroszolgáltatással rendelkező alkalmazás? Mert egy ilyen architektúra komoly követelményeket támaszt az architektúrával szemben, amit viszont tökéletesen lefednek a Kubernetes képességei. Másrészt ennek a funkciónak egy része hasznos lesz egy monolit esetében, különösen azért, mert a mai tipikus monolit nem éppen monolit (részletek a jelentésben később lesznek).
Mint látható, a végső grafikon (amikor a monolitikus és a mikroszolgáltatási alkalmazások is a Kubernetes infrastruktúrájában vannak) nem sokban különbözik az eredetitől. Ezután a Kubernetes használatával működő alkalmazásokról lesz szó.
Hasznos és káros mikroszolgáltatások
És itt van a fő gondolat:
Mi normális mikroszolgáltatás architektúra? Valós hasznot kell hoznia, növelve a munka hatékonyságát. Ha visszamegyünk a grafikonhoz, akkor itt van:
Ha felhívod hasznos, akkor a grafikon másik oldalán ott lesz káros mikroszolgáltatások (zavarja a munkát):
Visszatérve a „fő gondolathoz”: bíznom kell-e egyáltalán a tapasztalataimban? Ez év eleje óta nézegettem 85 projekt. Nem mindegyik volt mikroszolgáltatás (kb. harmada-fele volt ilyen architektúrával), de ez még mindig nagy szám. Nekünk (Flant cégnek) mint outsource-nak sokféle alkalmazást találunk kifejlesztve mind a kis cégeknél (5 fejlesztővel), mind a nagyoknál (~500 fejlesztő). További előny, hogy ezeket az alkalmazásokat élőben látjuk, és az évek során fejlődnek.
Miért mikroszolgáltatások?
A mikroszolgáltatások előnyeivel kapcsolatos kérdéshez ott van a már említett Martin Fowlertől:
- a modularitás világos határai;
- független telepítés;
- a technológia megválasztásának szabadsága.
Sokat beszélgettem szoftvertervezőkkel és fejlesztőkkel, és megkérdeztem, miért van szükségük mikroszolgáltatásokra. És elkészítettem a listámat az elvárásaikról. Íme, mi történt:
Ha leírunk néhány pontot „érzékelésben”, akkor:
- a modulok világos határai: itt van egy szörnyű monolit, és most minden szépen elrendeződik a Git tárolókban, amelyekben minden „a polcokon van”, a meleg és a puha nem keveredik;
- telepítési függetlenség: a szolgáltatásokat önállóan tudjuk majd kivezetni, így a fejlesztés gyorsabban megy (új funkciók párhuzamos közzététele);
- fejlesztési függetlenség: ezt a mikroszolgáltatást egy csapatnak/fejlesztőnek, azt a másiknak adhatjuk, aminek köszönhetően gyorsabban fejlődhetünk;
- боnagyobb megbízhatóság: ha részleges romlás következik be (20-ból egy mikroszolgáltatás elesik), akkor csak egy gomb fog leállni, és a rendszer egésze tovább fog működni.
Tipikus (káros) mikroszolgáltatás architektúra
Hogy megmagyarázzam, hogy a valóság miért nem az, amit várunk, bemutatom kollektív egy mikroszolgáltatási architektúra képe, amely számos különböző projekt tapasztalatain alapul.
Példa erre egy absztrakt online áruház, amely versenyezni fog az Amazonnal vagy legalább az OZON-nal. A mikroszolgáltatás architektúrája így néz ki:
Több ok miatt ezek a mikroszolgáltatások különböző platformokon íródnak:
Mivel minden mikroszolgáltatásnak önállósággal kell rendelkeznie, sokuknak saját adatbázisra és gyorsítótárra van szüksége. A végső architektúra a következő:
Milyen következményekkel jár?
Fowlernek is ez van — a mikroszolgáltatások igénybevételének „fizetéséről”:
És meglátjuk, beváltották-e az elvárásainkat.
A modulok világos határai...
De valójában hány mikroszolgáltatást kell javítanunk?bevezetni a változást? Egyáltalán kitalálhatjuk, hogyan működik minden elosztott nyomkövető nélkül (elvégre minden kérést a mikroszolgáltatások fele dolgoz fel)?
Van egy minta"“, és itt kiderült, hogy ez egy elosztott koszdarab. Ennek megerősítésére itt van egy hozzávetőleges illusztráció a kérések menetéről:
A telepítés függetlensége...
Technikailag sikerült: minden mikroszolgáltatást külön-külön ki tudunk építeni. De a gyakorlatban figyelembe kell venni, hogy mindig kigurul sok mikroszolgáltatás, és figyelembe kell vennünk kiterjesztésük sorrendjét. Jó értelemben általában külön áramkörben kell tesztelnünk, hogy a megfelelő sorrendben tesszük-e ki a kiadást.
A technológia megválasztásának szabadsága...
Ő az. Ne feledje, hogy a szabadság gyakran határos a törvénytelenséggel. Itt nagyon fontos, hogy ne csak azért válasszunk technológiákat, hogy „játszanak” velük.
A fejlesztés függetlensége...
Hogyan készítsünk teszthurkot a teljes alkalmazáshoz (annyi összetevővel)? De továbbra is naprakészen kell tartania. Mindez oda vezet, hogy tesztáramkörök tényleges száma, amit elvileg tartalmazhatunk, minimálisnak bizonyul.
Mit szólnál, ha mindezt helyben telepítenéd?... Kiderült, hogy a fejlesztő sokszor önállóan, de „véletlenszerűen” végzi a munkáját, mert kénytelen megvárni, amíg az áramkör felszabadul a tesztelésre.
Külön méretezés...
Igen, de ez korlátozott a használt DBMS területén. Az adott architektúra példában a Cassandrának nem lesz problémája, de a MySQL-nek és a PostgreSQL-nek igen.
Боnagyobb megbízhatóság...
Nemcsak egy mikroszolgáltatás meghibásodása a valóságban gyakran megzavarja az egész rendszer megfelelő működését, hanem egy új probléma is felmerül: nagyon nehéz minden mikroszolgáltatást hibatűrővé tenni. Mivel a mikroszolgáltatások különböző technológiát használnak (memcache, Redis stb.), mindegyiknél mindent át kell gondolni és megvalósítani, ami természetesen lehetséges, de hatalmas erőforrásokat igényel.
Terhelés mérhetősége...
Ez nagyon jó.
A mikroszolgáltatások "könnyedsége"...
Nálunk nem csak hatalmas hálózati rezsi (szaporodnak a DNS-kérések stb.), hanem az általunk indított sok segédlekérdezés miatt is replikálni az adatokat (tároló gyorsítótárak), ami jelentős mennyiségű tárhelyhez vezetett.
És íme, az elvárásaink teljesítésének eredménye:
De ez még nem minden!
Mert:
- Valószínűleg szükségünk lesz egy üzenetbuszra.
- Hogyan készítsünk konzisztens biztonsági mentést a megfelelő pillanatban? Az egyetlen igazi lehetőség a forgalom kikapcsolása erre. De hogyan kell ezt megtenni a termelésben?
- Ha több régió támogatásáról beszélünk, akkor a fenntarthatóság megszervezése mindegyikben igen munkaigényes feladat.
- Felmerül a központosított változtatások problémája. Például, ha frissítenünk kell a PHP verziót, akkor minden tárolóhoz (és több tucatnyi van) el kell köteleznünk magunkat.
- A működési összetettség növekedése exponenciális.
Mit kezdjünk ezzel az egésszel?
Kezdje egy monolitikus alkalmazással. Fowler tapasztalata hogy szinte minden sikeres mikroszolgáltatási alkalmazás monolitként indult, amely túl nagy lett, majd elromlott. Ugyanakkor szinte minden, kezdettől fogva mikroszolgáltatásként épített rendszer előbb-utóbb komoly problémákkal küzdött.
Egy másik értékes gondolat az, hogy egy mikroszolgáltatási architektúrával rendelkező projekt sikerességéhez nagyon jól kell tudnia és a tárgykör, valamint a mikroszolgáltatások elkészítésének módja. Egy tantárgy megtanulásának legjobb módja a monolit elkészítése.
De mi van, ha már ebben a helyzetben vagyunk?
Minden probléma megoldásának első lépése az, hogy egyetértünk vele, és megértjük, hogy ez egy probléma, és nem akarunk tovább szenvedni.
Ha egy túlnőtt monolit esetében (amikor elfogyott a lehetőség, hogy további forrásokat vásároljunk hozzá) levágjuk, akkor ebben az esetben az ellenkezője derül ki: amikor a túlzott mikroszolgáltatások már nem segítenek, hanem hátráltatnak - vágja le a felesleget és nagyítsa ki!
Például a fentebb tárgyalt kollektív képhez...
Megszabadulni a leginkább megkérdőjelezhető mikroszolgáltatásoktól:
Kombinálja a frontend generálásért felelős összes mikroszolgáltatást:
... egyetlen mikroszolgáltatásba, egyetlen (modern és normál, ahogy Ön gondolja) nyelven/keretrendszerben írva:
Egy ORM-je (egy DBMS) lesz, és először néhány alkalmazás:
... de általában sokkal többet is átvihet oda, és a következő eredményt kapja:
Ráadásul a Kubernetesben mindezt külön példányokban futtatjuk, ami azt jelenti, hogy a terhelést továbbra is külön-külön tudjuk mérni és skálázni.
Összegezve
Nézd meg a nagyobb képet. Nagyon gyakran a mikroszolgáltatásokkal kapcsolatos problémák azért merülnek fel, mert valaki vállalta a feladatát, de szeretne „játszani a mikroszolgáltatásokkal”.
A "mikroszolgáltatások" szóban a "mikro" rész felesleges.. Csak azért „mikro”-ok, mert kisebbek egy hatalmas monolitnál. De ne tekintsd őket apróságnak.
És egy utolsó gondolatként térjünk vissza az eredeti diagramhoz:
Egy megjegyzés van ráírva (jobb felső) abból fakad, hogy a projektet készítő csapat képességei mindig elsődlegesek — kulcsszerepet játszanak majd a mikroszolgáltatások és a monolit közötti választásban. Ha a csapat nem rendelkezik kellő képességekkel, de elkezdi a mikroszolgáltatások készítését, a történet biztosan végzetes lesz.
Videók és diák
Videó a beszédből (~50 perc; sajnos nem közvetíti a látogatók számos érzelmet, ami nagyban meghatározta a riport hangulatát, de ez van):
A jelentés bemutatása:
PS
További beszámolók a blogunkon:
- «» (Dmitry Stolyarov; 28. május 2018., RootConf);
- «» (Dmitry Stolyarov; 7. november 2017. a HighLoad++-on);
- «» (Dmitry Stolyarov; 6. június 2017., RootConf);
- «» (Dmitry Stolyarov; 8. november 2016. a HighLoad++-on);
- «» (Dmitry Stolyarov; 31. május 2016., RootConf).
Az alábbi kiadványok is érdekelhetik:
- «";
- «";
- «".
Forrás: will.com