Úvod
V posledním desetiletí se vývoj aplikací rychle vyvíjel, aby držel krok s technologickým pokrokem a potřebami spotřebitelů.
Zatímco tradiční vývoj spoléhal na jeden velký kus kódu, většina dnešních aplikací je konstruována z několika miniaplikací nebo mikroslužby , z nichž každý odpovídá za jednu funkci aplikace.
Společně tvoří systém označovaný jako architektura mikroslužeb.
Co jsou mikroslužby?
Mikroslužby , respektive architektura mikroslužeb , je systém používaný k vývoji aplikace, založený na výběru jednotlivých služeb, které spolupracují, aby zajistily bezproblémový a vysoce citlivý výkon.
Pokud vytváříte webovou aplikaci pomocí architektury mikroslužeb, rozdělíte ji na jednotlivé funkce, přičemž každou vyvíjíte a nasazujete jako samostatnou aplikaci.
Na rozdíl od monolitického vývoje, kde je vše sloučené a tudíž na sobě závislé, se architektura mikroservisů skládá z více modulů autonomních komponent. Jde o typ architektury spoléhající na systém volné vazby .
Poznámka :Volná vazba strukturuje systém, ve kterém si prvky navzájem neuvědomují, ale mohou komunikovat.
Například webová stránka elektronického obchodu vyžaduje mnoho různých služeb, včetně online plateb, vracení zboží, uživatelských profilů a tak dále. Při vytvoření webu by se vývojáři rozdělili do týmů, z nichž každý by odpovídal za vytvoření jedné z používaných mikroslužeb.
Jak spolu mikroslužby mluví?
Jakmile pochopíte strukturu, můžete se divit, jak se tyto samostatné entity spojují, aby vytvořily jednu harmonickou službu nebo aplikaci. Odpověď spočívá v navázání přímé, rychlé a bezchybné komunikace mezi všemi službami. Mikroslužby tedy spolu komunikují prostřednictvím API .
Rozhraní pro programování aplikací (API ) je přístupový bod každé modulární funkce, který umožňuje modulům interakci. Mikroslužba používá toto rozhraní k odesílání a odpovídání na požadavky z jiných modulů.
Každá mikroslužba musí mít jasně definovaný koncový bod API (jeden konec komunikačního kanálu), aby bylo zajištěno, že bude vždy přístupný pro dotazy. Ve většině případů se jedná o bezstavová rozhraní REST API . Bez jasně definovaných koncových bodů systém neví, kde hledat informace, které potřebuje.
Týmy DEV by proto ke sdílení koncových bodů mezi sebou využívaly oficiální standardy a vzory. Je jejich odpovědností vytvořit REST API prostřednictvím spolupráce a jasné komunikace.
Rozdíl mezi tradiční architekturou a architekturou mikroslužeb
Abychom lépe porozuměli mikroslužbám, porovnejme je se systémem používaným před jejich vývojem – monolitická architektura .
Monolitická architektura fungovalo dobře pro tradiční serverové systémy. Jedná se o systémy založené na jediné aplikaci. Všechny funkce jsou umístěny v jedné struktuře, používají stejný systém souborů, komunikují se stejným serverem a nakonec jsou nasazeny na stejném počítači.
Tento druh architektury umožňuje vývojářům vytvářet aplikace rychleji, protože potřebují sestavit pouze základní funkce, ke kterým by později přidali další funkce. Výkon byl také rychlejší, protože proces nezahrnuje rozhraní API.
S expanzí webových aplikací přišla potřeba svižnosti a konzistentní doby provozuschopnosti. Monolitická architektura měla příliš mnoho překážek na to, aby udržela krok s těmito požadavky.
Nevýhody monolitické architektury
Protože tyto systémy měly úzce propojený proces, jakékoli změny provedené v kódu mohly potenciálně ohrozit výkon celé aplikace. Funkce byly na sobě příliš závislé na nový technologický věk, který vyžadoval neustálé inovace a přizpůsobování.
Dalším problémem monolitické architektury byla její neschopnost škálovat jednotlivé funkcionality. Jedním z klíčových aspektů úspěšných podniků je jejich schopnost držet krok s požadavky spotřebitelů. Tyto požadavky přirozeně závisí na různých faktorech a v čase kolísají.
V určitém okamžiku bude vaše firma muset škálovat pouze určitou funkci své služby, aby mohla reagovat na rostoucí počet požadavků. U monolitických aplikací jste nemohli škálovat jednotlivé prvky, ale museli jste škálovat aplikaci jako celek.
Výhody mikroslužeb
Zavedení mikroslužeb vyřešilo mnoho problémů, které monolitický vývoj nedokázal.
1. Vysoce flexibilní
Za prvé, architektura mikroslužeb je vysoce flexibilní . Vzhledem k tomu, že každá mikroslužba je nezávislá, programátoři mohou vytvářet moduly pomocí různých jazyků nebo platforem. Tyto moduly budou moci mezi sebou komunikovat díky API.
Navíc s mikroslužbami se žádná organizace nemusí dlouhodobě zavázat k technologickému zásobníku. Vývojáři tak mohou vždy pracovat s nejnovější technologií.
2. Opakovaně použitelné funkční moduly
Tato funkce navíc umožňuje vývojářům opakovaně používat funkční moduly a aplikovat je na další aplikace. Využití již propracovaných mikroslužeb šetří zdroje společnosti a umožňuje vývojářům soustředit se na jiné projekty.
3. Odolné vůči změnám
Další podstatnou vlastností je, že systém je celkemodolný vůči změnám. Volně spojené funkce v rámci aplikace nejsou tak vzájemně závislé. Vývojáři mohou efektivně přidávat nové funkce nebo upravovat ty stávající. Mění kód jednoho modulu namísto celé aplikace.
4. Škálovatelný
Na rozdíl od monolitických aplikací jsou mikroslužby vynikající pro škálování . Zajišťují, že vaše aplikace je neustále v provozu, aniž by utrácely peníze za nepoužívané moduly. Protože nasazujete funkce na různé servery, systém vám umožňuje škálovat pouze potřebné zdroje.
5. Rychlejší vývojové cykly
V distribuovaném modelu je aplikace rozdělena na menší služby. Pokud vaše organizace přijala agilní vývoj, vaše týmy jej mohou snadněji aktualizovat a urychlit vývojové cykly.
Z obchodního hlediska jsou rychlejší vývojové cykly jedním z největších vylepšení zavedených mikroslužbami.
6. Transparentní model
Noví zaměstnanci například kód snadněji pochopí a upraví. To vychází ze skutečnosti, že aplikace je distribuována mezi četné služby. Obsluha jedné mikroslužby najednou je jednodušší než řešení celého integrovaného systému.
Nevýhody mikroslužeb
1. Složitosta
Nevýhodou číslo jedna architektury mikroslužeb je její složitost . Oproti monolitickým aplikacím má nově vyvinutý systém mnohem více komponent. Tyto komponenty (mikroslužby) musí bezchybně fungovat samy o sobě a uvnitř systému.
2. Výdajy
Tento systém je také dražší . Protože jsou služby nasazeny na více serverech, aplikace nakonec vyžaduje větší počet CPU a více běhových prostředí. Mikroslužby navíc kvůli své potřebě neustálé komunikace uskutečňují mnoho vzdálených hovorů. Tyto a další faktory se sčítají, což vyžaduje zvýšený rozpočet na vývoj.
3. Zabezpečení
Mikroslužby také vyžadují vyšší zabezpečení opatření. Jak bylo zmíněno výše, služby spolu mluví prostřednictvím API. To znamená, že si vyměňují informace po síti, což je vždy potenciální hrozba. Z tohoto důvodu musí být údržba a upgrady bezvadné.
4. Výkona
Složitost architektury ovlivňuje i její výkon . Protože mikroslužby zahrnují více instancí JVM (Java Virtual Machine) a meziprocesovou komunikaci, jejich účinnost může být pomalejší než u monolitických aplikací.
| PROS | CONS |
| Nezávislost služeb. Každý kontejner služeb má svou vlastní obchodní logiku a zaměřuje se na jednu obchodní schopnost. Architektura podporuje jednotlivé nasaditelné jednotky nezávislé na sobě. | Složité nastavení. Vzhledem k jejich individualismu vyžaduje nastavení systému více konfigurace a zdrojů, což má za následek provozní režii. |
| Flexibilní/agilní nasazení. Každá mikroslužba může být škálována nezávisle s možností používat různé technologie a provozovat na různých stacků a produktech. | Provozní složitost. Je obtížnější odstraňovat problémy, ladit a sledovat transakce prostřednictvím ekosystému mikroslužeb. Řešení problémů v systému vyžaduje vysokou úroveň automatizace. |
| Tolerance chyb. Mikroslužby jsou volně propojené jednotky, které lze automaticky obnovit. Tyto jednotky nejsou vzájemně závislé, což umožňuje vývojářům zvýšit dostupnost každé jednotky, když je to potřeba. | Bezpečnostní riziko. Přestože izolované služby jsou odolnější vůči chybám, stejná funkce může způsobit problémy se zabezpečením během transakcí mezi jednotkami. |
| Podporuje CI/CD. Protože jsou mikroslužby nasazovány nezávisle, lze vyvíjet a nasazovat více instancí současně. To vede k rychlejšímu a častějšímu vydávání softwaru. | Společně závislá rozhraní. Služby komunikují přes rozhraní, která jsou na sobě závislá. Je nemožné upravit jedno rozhraní bez úpravy druhého. |
| Zjednodušuje přidávání nových funkcí. Je snazší přidávat nové funkce změnou stávajících služeb nebo přidáním nových bez narušení výkonu ostatních služeb. | Pomalší výkon. Ve srovnání s monolitickými aplikacemi potřebují mikroslužby více času na provedení úkolů kvůli jejich složité architektuře a meziprocesní komunikaci. |
Výzvy k přijetí mikroslužeb
1. Navrhování distribuovaného modelu
Prvotní výzvou pro přijetí mikroslužeb je navržení spolehlivého a udržitelného modelu . Mikroslužby používají volně distribuovaný systém, takže je pravděpodobné, že skončíte se složitým návrhem. Všechny systémové závislosti musí být pečlivě zváženy a brány v úvahu.
2. Integrační testování
Další výzvou je integrace a end-to-end testování. Testování se stává obtížnějším a přitom důležitějším než kdy dříve. Mikroslužby musí vzájemně komunikovat a podporovat se, takže všechny služby musí být bez chyb. Chyba v jedné službě může způsobit závažnou chybu v jiné. To je důvod, proč je průběžné testování pomocí mikroslužeb prvořadé.
3. Nasazení
Pokud stále nasazujete ručně, váš tým bude muset zpočátku investovat čas do automatizace procesu. Kvůli složitosti distribuovaných modelů je ruční nasazení příliš složité.
4. Monitorování a protokolování
Organizace přijímající mikroslužby musí zavést centralizovaný systém monitorování a protokolování . Pokud není nakonfigurován, identifikace a ladění problémů bude nemožné.
5. Ladění
Kvůli všem výše uvedeným faktorům a dalším složitostem, jako je vyrovnávání zátěže a latence, problémy s laděním , v distribuovaném systému, je složitý. Neexistuje jednoduchá odpověď na to, který přístup funguje nejlépe, a určitě bude nějakou dobu trvat, než zjistíte, co je pro váš projekt nejlepší.
6. Další úvahy
Nakonec se vaše organizace musí přizpůsobit, aby přijala model mikroslužeb. Způsob, jakým vaše týmy pracují a spolupracují, se bude muset změnit. Podpořte změnu firemní kultury a připravte své týmy na mikroslužby.
Příklady mikroslužeb
Mikroslužby v Javě
Mikroslužby můžete vyvíjet pomocí různých jazyků. Nicméně Java je stále považován za jednu z nejlepších možností pro vytváření aplikací s takovou architekturou.
Pro vývoj v Javě se používá několik rámců mikroslužeb, včetně:
- Spring Boot
- Nahánět se
- Dres
- Dropwizard
- JHipster
- Vert.x
- Hrát
Kromě toho se nastavení mikroslužeb často používá k podpoře prostředí strojového učení (ML), protože umožňuje více rámců strojového učení v pracovním postupu. TensorFlow, Apache Mahout a Apache Singa jsou příklady rámců ML používaných s Javou.
Sběrem, agregací a analýzou toku dat mohou rámce předvídat výsledek a poskytovat srovnání mezi modely.
Mikroslužby v Dockeru
Docker je další skvělý software pro vytváření mikroslužeb. Protože platforma používá kontejnery ke spouštění virtuálních prostředí, umožňuje několik způsobů organizace mikroslužeb:
- Každý kontejner může být vyhrazen pro samostatnou službu.
- Jednu službu lze rozdělit do několika kontejnerů pro samostatné procesy v rámci služby.
Kontejnery jsou praktickým způsobem izolace mikroslužeb. Jsou lehké, rozmístitelné a škálovatelné pro různé operační systémy a infrastrukturu.
Pokud provozujete vícekontejnerovou aplikaci Docker, Docker Compose je nástroj, který vám může pomoci spravovat a konfigurovat všechny vaše mikroslužby. To vše se provádí pomocí jediného yaml a provádí úkoly spouštění, spouštění, komunikace a zavírání kontejnerů pomocí jediného koordinovaného příkazu.
Vícekontejnerové aplikace s mnoha hostiteli Docker se nejlépe spravují pomocí platformy pro orchestraci kontejnerů, jako je Swarm nebo Kubernetes. Obě platformy umožňují spravovat clustery serverů, z nichž každý má na sobě více služeb. Chcete-li se dozvědět více o jejich rozdílech, přečtěte si náš článek Kubernetes vs Docker Swarm.
Následuje ukázka toho, jak spravovat clustery kontejnerů pomocí Swarm a Compose spolupracujících v jednotném systému.
