19. září v Moskvě první tematické setkání HUG (Highload++ User Group), které bylo věnováno mikroslužbám. Proběhla prezentace „Provozování mikroslužeb: Na velikosti záleží, i když máte Kubernetes“, ve které jsme sdíleli Flantovy rozsáhlé zkušenosti s provozováním projektů s architekturou mikroslužeb. V první řadě se bude hodit všem vývojářům, kteří uvažují o využití tohoto přístupu ve svém současném nebo budoucím projektu.
Představujeme (50 minut, mnohem informativnější než článek), stejně jako hlavní výtah z něj v textové podobě.
Pozn.: Video a prezentace jsou také k dispozici na konci tohoto příspěvku.
úvod
Obvykle má dobrý příběh začátek, hlavní zápletku a rozuzlení. Tato zpráva je spíše předehrou, a to tragickou. Je také důležité poznamenat, že poskytuje pohled zvenčí na mikroslužby. vykořisťování.
Začnu tímto grafem, jehož autor (v roce 2015) Martin Fowler:
Ukazuje, jak v případě monolitické aplikace, která dosáhne určité hodnoty, začne produktivita klesat. Mikroslužby se liší tím, že počáteční produktivita je u nich nižší, ale jak se zvyšuje složitost, degradace efektivity u nich není tak patrná.
K tomuto grafu přidám pro případ použití Kubernetes:
Proč je aplikace s mikroslužbami lepší? Protože taková architektura klade vážné požadavky na architekturu, které jsou zase dokonale pokryty schopnostmi Kubernetes. Na druhou stranu se některé z těchto funkcí budou hodit pro monolit, zejména proto, že typický monolit dnes není zrovna monolit (podrobnosti budou později ve zprávě).
Jak vidíte, výsledný graf (když jsou v infrastruktuře s Kubernetes monolitické i mikroservisní aplikace) se od toho původního příliš neliší. Dále si povíme o aplikacích provozovaných pomocí Kubernetes.
Užitečné a škodlivé mikroslužby
A zde je hlavní myšlenka:
Co je normální architektura mikroslužeb? Mělo by vám to přinést skutečné výhody, zvýšit efektivitu vaší práce. Pokud se vrátíme ke grafu, zde je:
Pokud jí zavoláte užitečný, pak na druhé straně grafu bude škodlivý mikroslužby (ruší práci):
Vraťme se k „hlavní myšlence“: mám vůbec věřit svým zkušenostem? Od začátku tohoto roku jsem se díval 85 projektů. Ne všechny byly mikroslužby (takovou architekturu měla asi třetina až polovina z nich), ale i tak je to velké číslo. My (společnost Flant) jako outsourcers dokážeme vidět širokou škálu aplikací vyvíjených jak v malých společnostech (s 5 vývojáři), tak ve velkých (~500 vývojářů). Další výhodou je, že tyto aplikace vidíme naživu a v průběhu let se vyvíjejí.
Proč mikroslužby?
Na otázku o výhodách mikroslužeb existuje od již zmíněného Martina Fowlera:
- jasné hranice modularity;
- nezávislé nasazení;
- svobodu výběru technologií.
Hodně jsem mluvil se softwarovými architekty a vývojáři a ptal jsem se, proč potřebují mikroslužby. A udělal jsem si seznam jejich očekávání. Co se stalo:
Pokud popíšeme některé body „v pocitech“, pak:
- jasné hranice modulů: tady máme hrozný monolit a nyní bude vše úhledně uspořádáno v repozitářích Git, ve kterých je vše „na policích“, teplé a měkké se nemíchají;
- nezávislost na nasazení: budeme schopni zavádět služby nezávisle, takže vývoj půjde rychleji (souběžně zveřejňovat nové funkce);
- nezávislost na vývoji: tuto mikroslužbu můžeme dát jednomu týmu/vývojáři a tu druhému, díky čemuž se můžeme vyvíjet rychleji;
- боvětší spolehlivost: pokud dojde k částečné degradaci (padne jedna mikroslužba z 20), přestane fungovat pouze jedno tlačítko a systém jako celek bude nadále fungovat.
Typická (škodlivá) architektura mikroslužeb
Abych vysvětlil, proč realita není to, co očekáváme, uvedu kolektivní obraz architektury mikroslužeb založený na zkušenostech z mnoha různých projektů.
Příkladem může být abstraktní internetový obchod, který se chystá konkurovat Amazonu nebo alespoň OZONu. Jeho architektura mikroslužeb vypadá takto:
Z různých důvodů jsou tyto mikroslužby napsány na různých platformách:
Protože každá mikroslužba musí mít autonomii, mnoho z nich potřebuje vlastní databázi a mezipaměť. Konečná architektura je následující:
Jaké to má důsledky?
Fowler to má taky — o „platbě“ za používání mikroslužeb:
A uvidíme, zda se naše očekávání naplnila.
Jasné hranice modulů...
Ale kolik mikroslužeb vlastně potřebujeme opravit?zavést změnu? Dokážeme vůbec přijít na to, jak vše funguje bez distribuovaného traceru (koneckonců jakýkoli požadavek zpracovává polovina mikroslužeb)?
Existuje vzorec"“, a tady se ukázalo, že je to rozložená hrouda hlíny. Abychom to potvrdili, zde je přibližná ilustrace toho, jak žádosti probíhají:
Nezávislost nasazení...
Technicky toho bylo dosaženo: můžeme zavést každou mikroslužbu samostatně. V praxi je ale potřeba počítat s tím, že se to vždy vyvalí mnoho mikroslužeba musíme vzít v úvahu pořadí jejich zavádění. V dobrém slova smyslu obecně potřebujeme otestovat v samostatném okruhu, zda vydáváme vydání ve správném pořadí.
Svoboda volby technologie...
Je. Pamatujte, že svoboda často hraničí s bezprávím. Zde je velmi důležité nevybírat technologie jen proto, abychom si s nimi „hráli“.
Nezávislost vývoje...
Jak udělat testovací smyčku pro celou aplikaci (s tolika komponentami)? Stále je ale musíte udržovat aktuální. To vše vede k tomu, že skutečný počet testovacích okruhůkteré v zásadě můžeme obsahovat, se ukazuje jako minimální.
Co takhle to vše nasadit lokálně?... Ukazuje se, že často vývojář dělá svou práci samostatně, ale „nahodile“, protože je nucen čekat, až se okruh uvolní pro testování.
Samostatné škálování...
Ano, ale je to omezené v oblasti použitého DBMS. V uvedeném příkladu architektury nebude mít problémy Cassandra, ale MySQL a PostgreSQL ano.
Боvětší spolehlivost...
Nejen, že selhání jedné mikroslužby ve skutečnosti často naruší správné fungování celého systému, ale je tu také nový problém: učinit každou mikroslužbu odolnou proti chybám je velmi obtížné. Protože mikroslužby využívají různé technologie (memcache, Redis atd.), u každé je potřeba vše promyslet a implementovat, což je samozřejmě možné, ale vyžaduje to obrovské prostředky.
Měřitelnost zátěže...
To je opravdu dobré.
"Lehkost" mikroslužeb...
Máme nejen obrovské síťová režie (množí se požadavky na DNS atd.), ale také kvůli mnoha poddotazům, které jsme spustili replikovat data (store cache), což vedlo k značnému množství úložiště.
A zde je výsledek splnění našich očekávání:
Ale to není všechno!
Protože:
- S největší pravděpodobností budeme potřebovat sběrnici zpráv.
- Jak vytvořit konzistentní zálohu ve správný okamžik? Jediný skutečný možností je vypnout provoz za tímto účelem. Ale jak to udělat ve výrobě?
- Pokud mluvíme o podpoře několika regionů, pak organizace udržitelnosti v každém z nich je velmi pracný úkol.
- Vzniká problém provádění centralizovaných změn. Pokud například potřebujeme aktualizovat verzi PHP, budeme se muset zavázat ke každému repozitáři (a jsou jich desítky).
- Nárůst provozní složitosti je exponenciální.
Co s tím vším dělat?
Začněte s monolitickou aplikací. Fowlerova zkušenost že téměř všechny úspěšné aplikace mikroslužeb začínaly jako monolit, který se stal příliš velkým a poté byl rozbit. Přitom téměř všechny systémy postavené od samého počátku jako mikroslužby dříve či později zaznamenaly vážné problémy.
Další cennou myšlenkou je, že aby byl projekt s architekturou mikroslužeb úspěšný, musíte to velmi dobře vědět a předmět a jak dělat mikroslužby. A nejlepší způsob, jak se naučit předmět, je vyrobit si monolit.
Ale co když už jsme v této situaci?
Prvním krokem k vyřešení jakéhokoli problému je souhlasit s ním a pochopit, že je to problém, že už nechceme trpět.
Pokud v případě přerostlého monolitu (když nám došla možnost dokoupit si na něj další zdroje) jej seřízneme, pak v tomto případě dopadá opačný příběh: když nadměrné mikroslužby již nepomáhají, ale překáží - odřízněte přebytek a zvětšete!
Například pro kolektivní obrázek diskutovaný výše...
Zbavte se nejspornějších mikroslužeb:
Kombinujte všechny mikroslužby zodpovědné za generování frontendu:
... do jedné mikroslužby, napsané v jednom (moderním a normálním, jak si sami myslíte) jazyce/rámci:
Bude mít jeden ORM (jeden DBMS) a nejprve několik aplikací:
... ale obecně tam můžete přenést mnohem více a získáte následující výsledek:
Navíc v Kubernetes to vše spouštíme v samostatných instancích, což znamená, že stále můžeme měřit zátěž a škálovat je samostatně.
Shrnutí
Podívejte se na větší obrázek. Všechny tyto problémy s mikroslužbami velmi často vznikají proto, že někdo vzal svůj úkol, ale chtěl si „hrát s mikroslužbami“.
Ve slově "mikroslužby" je část "mikro" nadbytečná.. Jsou „mikro“ jen proto, že jsou menší než obrovský monolit. Ale neberte je jako něco malého.
A na závěr se vraťme k původnímu grafu:
Na to napsaná poznámka (vpravo nahoře) se scvrkává na skutečnost, že dovednosti týmu, který tvoří váš projekt, jsou vždy primární — budou hrát klíčovou roli při vašem výběru mezi mikroslužbami a monolitem. Pokud tým nebude mít dostatek dovedností, ale začne dělat mikroslužby, příběh bude určitě osudový.
Videa a diapozitivy
Video z projevu (~50 minut; bohužel nevyjadřuje četné emoce návštěvníků, které do značné míry určovaly náladu reportáže, ale je to tak):
Prezentace zprávy:
PS
Další zprávy na našem blogu:
- «» (Dmitry Stolyarov; 28. května 2018 na RootConf);
- «» (Dmitry Stolyarov; 7. listopadu 2017 na HighLoad++);
- «» (Dmitry Stolyarov; 6. června 2017 na RootConf);
- «» (Dmitry Stolyarov; 8. listopadu 2016 na HighLoad++);
- «» (Dmitry Stolyarov; 31. května 2016 na RootConf).
Také by vás mohly zajímat následující publikace:
- «";
- «";
- «".
Zdroj: www.habr.com