19. septembra v Moskve prvé tematické stretnutie HUG (Highload++ User Group), ktoré bolo venované mikroslužbám. Uskutočnila sa prezentácia „Prevádzkové mikroslužby: Na veľkosti záleží, aj keď máte Kubernetes“, v ktorej sme sa podelili o Flantove rozsiahle skúsenosti s prevádzkovaním projektov s architektúrou mikroslužieb. V prvom rade to bude užitočné pre všetkých vývojárov, ktorí uvažujú o použití tohto prístupu vo svojom aktuálnom alebo budúcom projekte.
Predstavujeme sa (50 minút, oveľa informatívnejšie ako článok), ako aj hlavný úryvok z neho v textovej podobe.
Poznámka: Video a prezentácia sú tiež k dispozícii na konci tohto príspevku.
Úvod
Zvyčajne dobrý príbeh má začiatok, hlavnú zápletku a rozuzlenie. Táto správa je skôr predohrou a zároveň tragickou. Je tiež dôležité poznamenať, že poskytuje pohľad zvonka na mikroslužby. prevádzkové.
Začnem týmto grafom, ktorého autor (v roku 2015) Martin Fowler:
Ukazuje, ako v prípade monolitickej aplikácie, ktorá dosiahne určitú hodnotu, produktivita začne klesať. Mikroslužby sa vyznačujú tým, že počiatočná produktivita je u nich nižšia, ale s rastúcou zložitosťou nie je pre nich degradácia efektívnosti taká výrazná.
Do tohto grafu pridám pre prípad použitia Kubernetes:
Prečo je aplikácia s mikroslužbami lepšia? Pretože takáto architektúra kladie vážne požiadavky na architektúru, ktoré sú zase dokonale pokryté schopnosťami Kubernetes. Na druhej strane, niektoré z týchto funkcií budú užitočné pre monolit, najmä preto, že typický monolit dnes nie je úplne monolit (podrobnosti budú neskôr v správe).
Ako vidíte, výsledný graf (keď sú v infraštruktúre s Kubernetes monolitické aj mikroservisné aplikácie) sa veľmi nelíši od pôvodného. Ďalej si povieme niečo o aplikáciách prevádzkovaných pomocou Kubernetes.
Užitočné a škodlivé mikroslužby
A tu je hlavná myšlienka:
čo je normálne architektúra mikroslužieb? Mala by vám priniesť skutočné výhody, zvýšiť efektivitu vašej práce. Ak sa vrátime ku grafu, tu je:
Ak jej zavoláš užitočné, potom na druhej strane grafu bude škodlivé mikroslužby (zasahujú do práce):
Vráťme sa k „hlavnej myšlienke“: mám vôbec dôverovať svojim skúsenostiam? Od začiatku tohto roka som sa pozrel 85 projektov. Nie všetky boli mikroslužby (takúto architektúru mala asi tretina až polovica), no stále je to veľké množstvo. My (spoločnosť Flant) ako outsourcers dokážeme vidieť širokú škálu aplikácií vyvíjaných v malých spoločnostiach (s 5 vývojármi) aj vo veľkých spoločnostiach (~ 500 vývojárov). Ďalšou výhodou je, že tieto aplikácie vidíme naživo a v priebehu rokov sa vyvíjajú.
Prečo mikroslužby?
Na otázku o výhodách mikroslužieb existuje od už spomínaného Martina Fowlera:
- jasné hranice modularity;
- nezávislé nasadenie;
- sloboda výberu technológií.
Veľa som hovoril so softvérovými architektmi a vývojármi a pýtal som sa, prečo potrebujú mikroslužby. A urobil som si zoznam ich očakávaní. Tu je to, čo sa stalo:
Ak opíšeme niektoré body „v pocitoch“, potom:
- jasné hranice modulov: tu máme strašný monolit a teraz bude všetko úhľadne usporiadané v úložiskách Git, v ktorých je všetko „na policiach“, teplé a mäkké sa nemiešajú;
- nezávislosť nasadenia: budeme môcť zavádzať služby nezávisle, aby vývoj šiel rýchlejšie (súbežne zverejňovať nové funkcie);
- nezávislosť na vývoji: túto mikroslužbu môžeme poskytnúť jednému tímu/vývojárovi a inému inému, vďaka čomu sa môžeme rozvíjať rýchlejšie;
- боväčšia spoľahlivosť: ak dôjde k čiastočnej degradácii (padne jedna mikroslužba z 20), potom prestane fungovať iba jedno tlačidlo a systém ako celok bude naďalej fungovať.
Typická (škodlivá) architektúra mikroslužieb
Aby som vysvetlil, prečo realita nie je taká, akú očakávame, uvediem kolektívne obraz architektúry mikroslužieb založený na skúsenostiach z mnohých rôznych projektov.
Príkladom môže byť abstraktný internetový obchod, ktorý sa chystá konkurovať Amazonu alebo aspoň OZONu. Jeho mikroservisná architektúra vyzerá takto:
Z viacerých dôvodov sú tieto mikroslužby napísané na rôznych platformách:
Keďže každá mikroslužba musí mať autonómiu, mnohé z nich potrebujú vlastnú databázu a vyrovnávaciu pamäť. Konečná architektúra je nasledovná:
Aké sú jej dôsledky?
Fowler to má tiež — o „platbe“ za používanie mikroslužieb:
A uvidíme, či sa naše očakávania naplnili.
Jasné hranice modulov...
Ale koľko mikroslužieb vlastne potrebujeme opraviť?zaviesť zmenu? Dokážeme vôbec prísť na to, ako všetko funguje bez distribuovaného sledovača (napokon, každú požiadavku spracuje polovica mikroslužieb)?
Existuje vzor"“, a tu sa ukázalo, že je to rozložená hruda špiny. Aby sme to potvrdili, tu je približná ilustrácia toho, ako prebiehajú žiadosti:
Nezávislosť nasadenia...
Technicky to bolo dosiahnuté: môžeme zaviesť každú mikroslužbu samostatne. Ale v praxi treba počítať s tým, že sa to vždy vyvalí veľa mikroslužieba musíme vziať do úvahy poradie ich zavádzania. V dobrom slova zmysle musíme vo všeobecnosti otestovať v samostatnom okruhu, či spúšťame vydanie v správnom poradí.
Sloboda výberu technológie...
Ona je. Len si pamätajte, že sloboda často hraničí s nezákonnosťou. Tu je veľmi dôležité nevyberať si technológie len preto, aby ste sa s nimi „hrali“.
Nezávislosť vývoja...
Ako urobiť testovaciu slučku pre celú aplikáciu (s toľkými komponentmi)? Stále ho však musíte aktualizovať. To všetko vedie k tomu, že skutočný počet testovacích okruhov, ktoré v zásade môžeme obsahovať, sa ukazuje ako minimálny.
Čo tak toto všetko nasadiť lokálne?... Ukazuje sa, že často vývojár robí svoju prácu samostatne, ale „náhodne“, pretože je nútený čakať, kým sa okruh uvoľní na testovanie.
Samostatné škálovanie...
Áno, ale je to obmedzené v oblasti použitého DBMS. V danom príklade architektúry nebude mať problémy Cassandra, ale MySQL a PostgreSQL áno.
Боväčšia spoľahlivosť...
Nielenže zlyhanie jednej mikroslužby v skutočnosti často narúša správne fungovanie celého systému, ale je tu aj nový problém: urobiť každú mikroslužbu odolnou voči chybám je veľmi ťažké. Keďže mikroslužby využívajú rôzne technológie (memcache, Redis atď.), pre každú je potrebné všetko premyslieť a implementovať, čo je, samozrejme, možné, ale vyžaduje si obrovské zdroje.
Merateľnosť zaťaženia...
Toto je naozaj dobré.
„Ľahkosť“ mikroslužieb...
Máme nielen obrovské sieťová réžia (množia sa požiadavky na DNS a pod.), ale aj kvôli mnohým poddotazom, ktoré sme začali replikovať dáta (store cache), čo viedlo k značnému objemu úložiska.
A tu je výsledok naplnenia našich očakávaní:
Ale to nie je všetko!
Pretože:
- S najväčšou pravdepodobnosťou budeme potrebovať zbernicu správ.
- Ako vytvoriť konzistentnú zálohu v správnom čase? Jediný reálny možnosť je vypnúť premávku. Ale ako to urobiť vo výrobe?
- Ak hovoríme o podpore viacerých regiónov, potom je organizácia udržateľnosti v každom z nich veľmi náročná na prácu.
- Vzniká problém centralizovaných zmien. Napríklad, ak potrebujeme aktualizovať verziu PHP, budeme sa musieť zaviazať ku každému úložisku (a sú ich desiatky).
- Rast prevádzkovej zložitosti je, mimochodom, exponenciálny.
Čo s tým všetkým robiť?
Začnite s monolitickou aplikáciou. Fowlerova skúsenosť že takmer všetky úspešné mikroservisné aplikácie začali ako monolit, ktorý sa stal príliš veľkým a potom sa rozbil. Zároveň takmer všetky systémy postavené ako mikroslužby od samého začiatku skôr či neskôr zaznamenali vážne problémy.
Ďalšou cennou myšlienkou je, že ak má byť projekt s architektúrou mikroslužieb úspešný, musíte to veľmi dobre vedieť a predmet a ako robiť mikroslužby. A najlepší spôsob, ako sa naučiť predmet, je vytvoriť monolit.
Ale čo ak sme už v tejto situácii?
Prvým krokom k riešeniu akéhokoľvek problému je súhlasiť s ním a pochopiť, že je to problém, že už nechceme trpieť.
Ak v prípade prerasteného monolitu (keď nám došla možnosť dokúpiť si naň zdroje) ho osekáme, tak v tomto prípade sa ukáže opačný príbeh: keď nadmerné mikroslužby už nepomáhajú, ale prekážajú - odrezať prebytok a zväčšiť!
Napríklad pre vyššie uvedený kolektívny obrázok...
Zbavte sa najspornejších mikroslužieb:
Skombinujte všetky mikroslužby zodpovedné za generovanie frontendu:
... do jednej mikroslužby, napísanej v jednom (modernom a normálnom, ako si sami myslíte) jazyku/rámci:
Bude mať jeden ORM (jeden DBMS) a najskôr niekoľko aplikácií:
... ale vo všeobecnosti tam môžete preniesť oveľa viac a získate nasledujúci výsledok:
Navyše v Kubernetes to všetko spúšťame v samostatných inštanciách, čo znamená, že stále môžeme merať zaťaženie a škálovať ich samostatne.
Zhrnutie
Pozrite sa na väčší obrázok. Všetky tieto problémy s mikroslužbami veľmi často vznikajú preto, že niekto zobral svoju úlohu, ale chcel sa „hrať s mikroslužbami“.
V slove "mikroslužby" je časť "mikro" nadbytočná.. Sú „mikro“ len preto, že sú menšie ako obrovský monolit. Neberte ich však ako niečo malé.
A na záver sa vráťme k pôvodnému grafu:
Na ňom napísaná poznámka (hore vpravo) redukuje na skutočnosť, že zručnosti tímu, ktorý tvorí váš projekt, sú vždy prvoradé — budú hrať kľúčovú úlohu pri vašom výbere medzi mikroslužbami a monolitom. Ak tím nebude mať dostatok zručností, no začne robiť mikroslužby, príbeh bude určite osudný.
Videá a diapozitívy
Video z prejavu (~50 minút; žiaľ, nevyjadruje početné emócie návštevníkov, ktoré do značnej miery určovali náladu reportáže, ale je to tak):
Prezentácia správy:
PS
Ďalšie správy na našom blogu:
- «» (Dmitrij Stolyarov; 28. mája 2018 na RootConf);
- «» (Dmitrij Stolyarov; 7. novembra 2017 na HighLoad++);
- «» (Dmitrij Stolyarov; 6. júna 2017 na RootConf);
- «» (Dmitrij Stolyarov; 8. novembra 2016 na HighLoad++);
- «» (Dmitrij Stolyarov; 31. mája 2016 na RootConf).
Mohli by vás zaujímať aj nasledujúce publikácie:
- «»;
- «»;
- «".
Zdroj: hab.com