Kontejnerizované mikroslužby
Poznámka:
Tato elektronická kniha byla publikována na jaře roku 2017 a od té doby nebyla aktualizována. Existuje mnoho v knize, která zůstává cenná, ale některé materiály jsou zastaralé.
Vývoj klientských serverových aplikací má za následek zaměření se na vytváření vrstvených aplikací, které používají konkrétní technologie v každé vrstvě. Takové aplikace se často označují jako monolitické aplikace a jsou zabalené na hardware předem škálované pro zatížení ve špičce. Hlavní nevýhodou tohoto vývojového přístupu je úzká spojka mezi komponentami v rámci každé úrovně, že jednotlivé komponenty nelze snadno škálovat a náklady na testování. Jednoduchá aktualizace může mít nepředvídatelné účinky na zbytek vrstvy, takže změna komponenty aplikace vyžaduje opětovné otestování a opětovné nasazení celé vrstvy.
Zvláště pokud jde o věk cloudu, je to, že jednotlivé komponenty se nedají snadno škálovat. Monolitická aplikace obsahuje funkce specifické pro doménu a obvykle je rozdělená podle funkčních vrstev, jako je front-end, obchodní logika a úložiště dat. Monolitická aplikace se škáluje klonováním celé aplikace na více počítačů, jak je znázorněno na obrázku 8-1.
Obrázek 8–1: Přístup ke škálování monolitických aplikací
Mikroslužby
Mikroslužby nabízejí jiný přístup k vývoji a nasazení aplikací, přístup, který je vhodný pro požadavky na flexibilitu, škálování a spolehlivost moderních cloudových aplikací. Aplikace mikroslužeb je rozdělená do nezávislých komponent, které spolupracují na poskytování celkové funkčnosti aplikace. Pojem mikroslužba zdůrazňuje, že aplikace by se měly skládat ze služeb dostatečně malé, aby odrážely nezávislé obavy, takže každá mikroslužba implementuje jednu funkci. Kromě toho má každá mikroslužba dobře definované kontrakty, aby s ní ostatní mikroslužby mohly komunikovat a sdílet data. Mezi typické příklady mikroslužeb patří nákupní košíky, zpracování zásob, nákupní subsystémy a zpracování plateb.
Mikroslužby se můžou škálovat nezávisle, ve srovnání s obřími monolitických aplikací, které se škálují společně. To znamená, že konkrétní funkční oblast, která vyžaduje větší výpočetní výkon nebo šířku pásma sítě pro podporu poptávky, je možné škálovat místo zbytečně horizontálního navýšení kapacity jiných oblastí aplikace. Obrázek 8–2 znázorňuje tento přístup, kdy se mikroslužby nasazují a škálují nezávisle a vytvářejí instance služeb napříč počítači.
Obrázek 8–2: Přístup ke škálování aplikací mikroslužeb
Škálování mikroslužeb může být téměř okamžité, což aplikaci umožňuje přizpůsobit se měnícím zatížením. Například jedna mikroslužba ve webové funkci aplikace může být jedinou mikroslužbou v aplikaci, která potřebuje škálovat kapacitu tak, aby zpracovávala další příchozí provoz.
Klasickým modelem škálovatelnosti aplikací je mít vrstvu bezstavové vyrovnávání zatížení se sdíleným externím úložištěm dat pro ukládání trvalých dat. Stavové mikroslužby spravují svá vlastní trvalá data, obvykle je ukládají místně na servery, na kterých jsou umístěné, aby se zabránilo režii síťového přístupu a složitosti operací napříč službami. To umožňuje nejrychlejší zpracování dat a může eliminovat potřebu systémů ukládání do mezipaměti. Kromě toho škálovatelné stavové mikroslužby obvykle rozdělují data mezi své instance a spravují velikost dat a propustnost přenosu dat, nad kterou může jeden server podporovat.
Mikroslužby také podporují nezávislé aktualizace. Toto volné spojení mezi mikroslužbami poskytuje rychlý a spolehlivý vývoj aplikací. Jejich nezávislá distribuovaná povaha podporuje postupné aktualizace, kdy se v daném okamžiku aktualizuje pouze podmnožina instancí jedné mikroslužby. Proto pokud se zjistí problém, je možné vrátit aktualizaci chyby zpět před aktualizací všech instancí s chybným kódem nebo konfigurací. Podobně mikroslužby obvykle používají správu verzí schématu, aby klienti viděli konzistentní verzi při použití aktualizací bez ohledu na to, s jakou instancí mikroslužby se komunikuje.
Proto mají aplikace mikroslužeb mnoho výhod oproti monolitických aplikacím:
- Každá mikroslužba je relativně malá, snadno se spravuje a vyvíjí.
- Jednotlivé mikroslužby je možné vyvíjet a nasazovat nezávisle na ostatních službách.
- Jednotlivé mikroslužby je možné škálovat nezávisle na sobě. Například katalogová služba nebo služba nákupního košíku může být potřeba škálovat více než službu objednávek. Výsledná infrastruktura proto bude efektivněji využívat prostředky při horizontálním navýšení kapacity.
- Každá mikroslužba izoluje všechny problémy. Pokud například ve službě dojde k problému, ovlivní to jenom tuto službu. Ostatní služby můžou dál zpracovávat žádosti.
- Každá mikroslužba může používat nejnovější technologie. Vzhledem k tomu, že mikroslužby jsou autonomní a spuštěné souběžně, je možné používat nejnovější technologie a architektury, a ne vynucovat použití starší architektury, kterou může používat monolitická aplikace.
Řešení založené na mikroslužbách má ale také potenciální nevýhody:
- Volba způsobu rozdělení aplikace do mikroslužeb může být náročná, protože každá mikroslužba musí být zcela autonomní, kompletní, včetně odpovědnosti za zdroje dat.
- Vývojáři musí implementovat komunikaci mezi službami, což zvyšuje složitost a latenci aplikace.
- Atomické transakce mezi několika mikroslužbami obvykle nejsou možné. Obchodní požadavky proto musí zahrnovat konečnou konzistenci mezi mikroslužbami.
- V produkčním prostředí je při nasazování a správě systému ohroženého mnoha nezávislými službami provozní složitost.
- Přímá komunikace mezi klientem a mikroslužbou může ztížit refaktoring kontraktů mikroslužeb. Například způsob rozdělení systému do služeb v průběhu času může být potřeba změnit. Jedna služba se může rozdělit na dvě nebo více služeb a dvě služby se můžou sloučit. Když klienti komunikují přímo s mikroslužbami, může tato práce refaktoringu narušit kompatibilitu s klientskými aplikacemi.
Vytváření kontejnerů
Kontejnerizace je přístup k vývoji softwaru, ve kterém se aplikace a jeho verze sady závislostí a navíc jeho konfigurace prostředí abstrahuje jako soubory manifestu nasazení, jsou zabaleny společně jako image kontejneru, testovány jako jednotka a nasazeny do hostitelského operačního systému.
Kontejner je izolované, řízené a přenosné provozní prostředí, ve kterém může aplikace běžet bez zásahu do prostředků jiných kontejnerů nebo hostitele. Kontejner proto vypadá a funguje jako nově nainstalovaný fyzický počítač nebo virtuální počítač.
Existuje mnoho podobností mezi kontejnery a virtuálními počítači, jak je znázorněno na obrázku 8–3.
Obrázek 8–3: Porovnání virtuálních počítačů a kontejnerů
Kontejner spouští operační systém, má systém souborů a dá se k němu přistupovat přes síť, jako by šlo o fyzický nebo virtuální počítač. Technologie a koncepty používané kontejnery se ale velmi liší od virtuálních počítačů. Mezi virtuální počítače patří aplikace, požadované závislosti a úplný hostovaný operační systém. Kontejnery zahrnují aplikaci a její závislosti, ale sdílejí operační systém s jinými kontejnery, které běží jako izolované procesy v hostitelském operačním systému (kromě kontejnerů Hyper-V, které běží uvnitř speciálního virtuálního počítače na kontejner). Kontejnery proto sdílejí prostředky a obvykle vyžadují méně prostředků než virtuální počítače.
Výhodou přístupu zaměřeného na vývoj a nasazení kontejnerů je, že eliminuje většinu problémů, které vznikají z nekonzistentních nastavení prostředí a problémů, které s nimi přicházejí. Kontejnery navíc umožňují rychlé funkce vertikálního navýšení kapacity aplikací tak, že podle potřeby nastavují nové kontejnery.
Mezi klíčové koncepty při vytváření a práci s kontejnery patří:
- Hostitel kontejneru: Fyzický nebo virtuální počítač nakonfigurovaný pro hostování kontejnerů. Hostitel kontejneru spustí jeden nebo více kontejnerů.
- Image kontejneru: Image se skládá ze sjednocení vrstvených systémů souborů skládaných nad sebou a je základem kontejneru. Image nemá stav a při nasazení do různých prostředí se nikdy nemění.
- Kontejner: Kontejner je instance modulu runtime image.
- Image operačního systému kontejneru: Kontejnery se nasazují z imagí. Image operačního systému kontejneru je první vrstvou v potenciálně mnoha vrstvách imagí, které tvoří kontejner. Operační systém kontejneru je neměnný a nelze ho upravovat.
- Úložiště kontejnerů: Při každém vytvoření image kontejneru se image a její závislosti ukládají v místním úložišti. Tyto image je možné opakovaně používat na hostiteli kontejneru. Image kontejneru se dají uložit také do veřejného nebo privátního registru, jako je Docker Hub, aby je bylo možné použít napříč různými hostiteli kontejnerů.
Podniky stále častěji přijímají kontejnery při implementaci aplikací založených na mikroslužbách a Docker se stal standardní implementací kontejnerů, kterou přijala většina softwarových platforem a dodavatelů cloudu.
Referenční aplikace eShopOnContainers používá Docker k hostování čtyř kontejnerizovaných back-endových mikroslužeb, jak je znázorněno na obrázku 8-4.
Obrázek 8-4: Referenční mikroslužby back-endových aplikací eShopOnContainers
Architektura back-endových služeb v referenční aplikaci je rozdělena do několika autonomních dílčích systémů ve formě spolupráce mikroslužeb a kontejnerů. Každá mikroslužba poskytuje jednu oblast funkcí: službu identit, službu katalogu, službu objednávek a službu košíku.
Každá mikroslužba má svou vlastní databázi, která umožňuje úplné oddělení od ostatních mikroslužeb. V případě potřeby je dosaženo konzistence mezi databázemi z různých mikroslužeb pomocí událostí na úrovni aplikace. Další informace najdete v tématu Komunikace mezi mikroslužbami.
Další informace o referenční aplikaci naleznete v tématu Mikroslužby .NET: Architektura pro kontejnerizované aplikace .NET.
Komunikace mezi klientem a mikroslužbami
Mobilní aplikace eShopOnContainers komunikuje s kontejnerizovanými back-endovými mikroslužbami pomocí přímé komunikace mezi klientem a mikroslužbou , která je znázorněna na obrázku 8-5.
Obrázek 8-5: Přímá komunikace mezi klientem a mikroslužbou
Při přímé komunikaci mezi klientem a mikroslužbou mobilní aplikace provádí požadavky na každou mikroslužbu přímo prostřednictvím svého veřejného koncového bodu s jiným portem TCP na mikroslužbu. V produkčním prostředí by koncový bod obvykle mapoval na nástroj pro vyrovnávání zatížení mikroslužby, který distribuuje požadavky mezi dostupné instance.
Tip
Zvažte použití komunikace brány rozhraní API. Přímá komunikace mezi klientem a mikroslužbou může mít nevýhody při vytváření rozsáhlé a komplexní aplikace založené na mikroslužbách, ale je pro malou aplikaci vhodnější. Při navrhování velké aplikace založené na mikroslužbách s desítkami mikroslužeb zvažte použití komunikace brány rozhraní API. Další informace naleznete v tématu Mikroslužby .NET: Architektura pro kontejnerizované aplikace .NET.
Komunikace mezi mikroslužbami
Aplikace založená na mikroslužbách je distribuovaný systém, který může běžet na více počítačích. Každá instance služby je obvykle procesem. Služby proto musí komunikovat pomocí komunikačního protokolu mezi procesy, jako je HTTP, TCP, Advanced Message Queuing Protocol (AMQP) nebo binární protokoly v závislosti na povaze každé služby.
Dva běžné přístupy pro komunikaci mikroslužeb mezi mikroslužbami jsou komunikace ZALOŽENÝ NA PROTOKOLU HTTP při dotazování na data a zjednodušené asynchronní zasílání zpráv při komunikaci aktualizací mezi několika mikroslužbami.
Asynchronní komunikace založená na zasílání zpráv na základě událostí je důležitá při šíření změn napříč několika mikroslužbami. S tímto přístupem mikroslužba publikuje událost, když se stane něco, co se stane, například když aktualizuje obchodní entitu. Ostatní mikroslužby se k odběru těchto událostí přihlašují. Když pak mikroslužba obdrží událost, aktualizuje své vlastní obchodní entity, což může zase vést k publikování dalších událostí. Tato funkce publikování a odběru se obvykle dosahuje pomocí sběrnice událostí.
Sběrnice událostí umožňuje komunikaci s publikováním a odběrem mezi mikroslužbami, aniž by bylo nutné, aby si komponenty navzájem explicitně uvědomily, jak je znázorněno na obrázku 8-6.
Obrázek 8-6: Publikování odběru pomocí sběrnice událostí
Z pohledu aplikace je sběrnice událostí jednoduše kanál publikování a odběru vystavený prostřednictvím rozhraní. Způsob implementace sběrnice událostí se ale může lišit. Implementace sběrnice událostí může například používat RabbitMQ, Azure Service Bus nebo jiné servisní autobusy, jako je NServiceBus a MassTransit. Obrázek 8-7 ukazuje, jak se používá sběrnice událostí v referenční aplikaci eShopOnContainers.
Obrázek 8-7: Asynchronní komunikace řízená událostmi v referenční aplikaci
Sběrnice událostí eShopOnContainers implementovaná pomocí RabbitMQ poskytuje funkce asynchronního publikování a odběru 1:N. To znamená, že po publikování události může být několik odběratelů, kteří naslouchají stejné události. Tento vztah znázorňuje obrázek 8–9.
Obrázek 8-9: Komunikace 1:N
Tento komunikační přístup 1:N používá události k implementaci obchodních transakcí, které zahrnují více služeb a zajišťují konečnou konzistenci mezi službami. Konečná transakce se skládá z řady distribuovaných kroků. Proto když mikroslužba profilu uživatele obdrží příkaz UpdateUser, aktualizuje podrobnosti uživatele v jeho databázi a publikuje událost UserUpdated do sběrnice událostí. Mikroslužba košíku i objednávková mikroslužba se přihlásily k odběru této události a v odpovědi aktualizují informace o kupujících v příslušných databázích.
Poznámka:
Sběrnice událostí eShopOnContainers implementovaná pomocí RabbitMQ je určena pouze jako testování konceptu. U produkčních systémů by se měly zvážit alternativní implementace sběrnice událostí.
Informace o implementaci sběrnice událostí naleznete v tématu Mikroslužby .NET: Architektura pro kontejnerizované aplikace .NET.
Shrnutí
Mikroslužby nabízejí přístup k vývoji a nasazení aplikací, který je vhodný pro požadavky na flexibilitu, škálování a spolehlivost moderních cloudových aplikací. Jednou z hlavních výhod mikroslužeb je, že je možné škálovat nezávisle na sobě, což znamená, že je možné škálovat konkrétní funkční oblast, která vyžaduje větší výpočetní výkon nebo šířku pásma sítě pro podporu poptávky, aniž by zbytečně škálovaly oblasti aplikace, u kterých nedochází k zvýšené poptávce.
Kontejner je izolované, řízené a přenosné provozní prostředí, ve kterém může aplikace běžet bez zásahu do prostředků jiných kontejnerů nebo hostitele. Podniky stále častěji přijímají kontejnery při implementaci aplikací založených na mikroslužbách a Docker se stal standardní implementací kontejnerů, kterou přijala většina softwarových platforem a dodavatelů cloudu.