Proč při sestavování aplikací používat přístup využívající mikroslužby
Pro vývojáře softwaru není faktorace aplikace do součástí nic nového. Obvykle se používá vrstvený přístup s back-endovým úložištěm, obchodní logikou střední vrstvy a front-endovým uživatelským rozhraním (UI). V posledních několika letech se změnilo to, že vývojáři vytvářejí distribuované aplikace pro cloud.
Tady jsou některé měnící se obchodní potřeby:
- Služba vytvořená a provozovaná ve velkém měřítku tak, aby oslovovala zákazníky v nových geografických oblastech.
- Rychlejší poskytování funkcí a možností, které agilně reagují na požadavky zákazníků.
- Vylepšené využití prostředků za účelem snížení nákladů
Tyto obchodní potřeby ovlivňují způsob vytváření aplikací.
Další informace o přístupu Azure k mikroslužbám najdete v tématu Mikroslužby: Aplikační revoluce založená na cloudu.
Monolitický vs. přístup k návrhu mikroslužeb
Aplikace se v průběhu času vyvíjejí. Úspěšné aplikace se vyvíjejí tak, že jsou užitečné pro lidi. Neúspěšné aplikace se nevyvíjí a jsou nakonec zastaralé. Tady je otázka: kolik toho víte o svých požadavcích dnes a jaké budou v budoucnu? Řekněme například, že vytváříte aplikaci pro vytváření sestav pro oddělení ve vaší společnosti. Jste si jistí, že aplikace platí jenom v rámci vaší společnosti a že se sestavy nebudou uchovávat dlouho. Váš přístup se bude lišit od například při vytváření služby, která bude poskytovat videoobsoubor desítkám milionů zákazníků.
Někdy je hlavním faktorem dostat něco ven jako důkaz konceptu. Víte, že aplikaci je možné později přepracovat. Nemá smysl přetěžovat něco, co se nikdy nepoužije. Na druhou stranu platí, že když společnosti vytvářejí pro cloud, očekává se růst a využití. Růst a škálování jsou nepředvídatelné. Chceme rychle vytvořit prototyp a zároveň vědět, že jsme na cestě, která zvládne budoucí úspěch. Toto je přístup štíhlého startupu: sestavení, měření, učení a iterace.
Během éry klienta/serveru jsme se zaměřili na vytváření vrstvených aplikací pomocí konkrétních technologií v každé vrstvě. Pro popis těchto přístupů se objevil termín monolitická aplikace. Rozhraní se většinou nacházela mezi vrstvami a mezi komponentami v jednotlivých vrstvách byl použit těsněji propojený návrh. Vývojáři navrhli a faktorovali třídy, které byly zkompilovány do knihoven a propojeny do několika spustitelných souborů a knihoven DLL.
Monolitický přístup k návrhu má své výhody. Návrh monolitických aplikací je často jednodušší a volání mezi komponentami jsou rychlejší, protože tato volání často probíhají přes komunikaci mezi procesy (IPC). Všichni také testují jeden produkt, což je efektivnější využití lidských zdrojů. Nevýhodou je, že mezi vrstvenými vrstvami existuje úzká vazba a není možné škálovat jednotlivé komponenty. Pokud potřebujete provést opravy nebo upgrady, musíte počkat, až ostatní dokončí testování. Je těžší být agilní.
Mikroslužby řeší tyto nevýhody a více odpovídají předchozím obchodním požadavkům. Mají ale také výhody i závazky. Výhodou mikroslužeb je, že každá z nich obvykle zapouzdřuje jednodušší obchodní funkce, které můžete nezávisle na sobě škálovat na více nebo méně instancí, testovat, nasazovat a spravovat. Jednou z důležitých výhod přístupu k mikroslužbám je to, že týmy jsou řízeny spíše obchodními scénáři než technologiemi. Menší týmy vyvíjejí mikroslužby založené na scénáři zákazníka a využívají libovolné technologie, které chce použít.
Jinými slovy, organizace nepotřebuje standardizovat technologie, aby mohla udržovat aplikace mikroslužeb. Jednotlivé týmy, které vlastní služby, můžou dělat to, co je pro ně vhodné, na základě odborných znalostí týmu nebo toho, co je nejvhodnější k vyřešení problému. V praxi je vhodnější použít sadu doporučených technologií, jako je konkrétní úložiště NoSQL nebo architektura webové aplikace.
Nevýhodou mikroslužeb je, že musíte spravovat samostatnější entity a řešit složitější nasazení a správu verzí. Zvyšuje se síťový provoz mezi mikroslužbami, stejně jako odpovídající latence sítě. Spousta chatrných, podrobných služeb může způsobit noční můru výkonu. Bez nástrojů, které vám pomohou zobrazit tyto závislosti, je obtížné vidět celý systém.
Standardy umožňují, aby přístup k mikroslužbám fungoval tak, že určuje, jak komunikovat, a tolerují pouze to, co od služby potřebujete, a nikoli pevné kontrakty. Při návrhu je důležité tyto kontrakty definovat předem, protože služby se aktualizují nezávisle na sobě. Dalším popisem návrhu s přístupem založeným na mikroslužbách je jemně odstupňovaná architektura SOA (Service-Oriented Architecture).
V nejjednodušším případě se návrh mikroslužeb týká oddělené federace služeb s nezávislými změnami a dohodnutými standardy komunikace.
Vzhledem k tomu, že se vytváří více cloudových aplikací, lidé zjistili, že tento rozklad celkové aplikace do nezávislých služeb zaměřených na scénáře je lepším dlouhodobým přístupem.
Porovnání přístupů k vývoji aplikací
Monolitická aplikace obsahuje funkce specifické pro doménu a obvykle se dělí na funkční vrstvy, jako jsou web, obchodní a data.
Monolitickou aplikaci škálujete tak, že ji naklonujete na více serverech, virtuálních počítačích nebo kontejnerech.
Aplikace mikroslužeb rozděluje funkce do samostatných menších služeb.
Přístup k mikroslužbám se škáluje na více instancí tak, že každou službu nasadí nezávisle a vytvoří instance těchto služeb napříč servery, virtuálními počítači a kontejnery.
Návrh s využitím mikroslužeb není vhodný pro všechny projekty, ale lépe odpovídá obchodním cílům popsaným výše. Pokud víte, že budete mít možnost později kód přepracovat do návrhu mikroslužeb, může být vhodné začít monolitickým přístupem. Častěji začínáte s monolitickou aplikací a pomalu ji rozdělujete postupně, počínaje funkčními oblastmi, které musí být škálovatelné nebo agilnější.
Při použití přístupu využívajícího mikroslužby vytváříte aplikaci mnoha malých služeb. Tyto služby běží v kontejnerech nasazených napříč clustery počítačů. Menší týmy vyvíjejí službu, která se zaměřuje na konkrétní scénář a nezávisle testuje, vytváří verze, nasazuje a škáluje jednotlivé služby tak, aby se celá aplikace vyvíjela.
Co je mikroslužba?
Existují různé definice mikroslužeb. Většina těchto charakteristik mikroslužeb se ale všeobecně přijímá:
- Zapouzdření zákazníka nebo obchodního scénáře Jaký problém řešíte?
- Vyvinutý malým technickým týmem.
- Napsané v libovolném programovacím jazyce s použitím libovolné architektury.
- Skládají se z kódu a volitelně i stavu, z nichž oba mají nezávisle na sobě verze, nasazují se a škálují se.
- Interakce s jinými mikroslužbami přes dobře definovaná rozhraní a protokoly
- Mají jedinečné názvy (adresy URL), které se používají k překladu jejich umístění.
- Zůstaňte konzistentní a k dispozici v případě selhání.
Abychom to shrnuli:
Aplikace mikroslužeb se skládají z malých služeb s nezávislou správou verzí, které lze přizpůsobit zákazníkům a které spolu komunikují přes standardní protokoly s dobře definovanými rozhraními.
Napsané v libovolném programovacím jazyce s použitím libovolné architektury
Jako vývojáři chceme mít možnost zvolit jazyk nebo architekturu v závislosti na našich dovednostech a potřebách služby, kterou vytváříme. U některých služeb můžete nad čímkoli jiným ocenět výkonové výhody jazyka C++. Pro ostatní může být jednodušší spravovaný vývoj, který získáte z C# nebo Javy. V některých případech může být potřeba použít konkrétní partnerskou knihovnu, technologii úložiště dat nebo metodu pro zpřístupnění služby klientům.
Po výběru technologie je potřeba zvážit správu a škálování služby v provozním nebo životním cyklu.
Umožňuje nezávislé nastavení verzí, nasazení a škálování kódu a stavu.
Bez ohledu na to, jak mikroslužby píšete, kód a případně i stav, by se měly nezávisle nasazovat, upgradovat a škálovat. Tento problém je těžké vyřešit, protože záleží na vaší volbě technologií. Pro škálování je obtížné porozumět tomu, jak rozdělit kód (nebo shardovat) na oddíly a stav. Když kód a stav používají různé technologie, což je dnes běžné, musí být skripty nasazení pro mikroslužbu schopné je obě škálovat. Toto oddělení se týká také flexibility a flexibility, takže některé mikroslužby můžete upgradovat, aniž byste je museli upgradovat všechny najednou.
Vraťme se na chvíli k našemu porovnání monolitických přístupů a přístupů k mikroslužbám. Tento diagram znázorňuje rozdíly v přístupech k ukládání stavu:
Úložiště stavu pro tyto dva přístupy
Monolitický přístup vlevo má jednu databázi a vrstvy konkrétních technologií.
Přístup k mikroslužbám napravo obsahuje graf vzájemně propojených mikroslužeb, kde je stav obvykle vymezený na mikroslužbu a používají se různé technologie.
V monolitickém přístupu aplikace obvykle používá jednu databázi. Výhodou použití jedné databáze je, že je v jednom umístění, což usnadňuje nasazení. Každá komponenta může mít jednu tabulku pro uložení svého stavu. Týmy musí striktně oddělit stát, což je výzva. Někdo bude nevyhnutelně v pokušení přidat sloupec do existující tabulky zákazníka, provést spojení mezi tabulkami a vytvořit závislosti na vrstvě úložiště. Jakmile k tomu dojde, nebudete moct škálovat jednotlivé komponenty.
V přístupu k mikroslužbám každá služba spravuje a ukládá svůj vlastní stav. Každá služba zodpovídá za společné škálování kódu a stavu tak, aby splňovaly požadavky služby. Nevýhodou je, že když potřebujete vytvořit zobrazení nebo dotazy dat vaší aplikace, musíte dotazovat napříč několika úložišti stavů. Tento problém obvykle řeší samostatná mikroslužba, která sestavuje zobrazení napříč kolekcí mikroslužeb. Pokud potřebujete na data spouštět více improvizačních dotazů, měli byste zvážit zápis dat jednotlivých mikroslužeb do služby datových skladů pro offline analýzy.
Mikroslužby mají verze. Je možné, že různé verze mikroslužby běží vedle sebe. Novější verze mikroslužby může při upgradu selhat a je potřeba ji vrátit zpět na starší verzi. Správa verzí je také užitečná pro testování A/B, kde různí uživatelé mají různé verze služby. Například je běžné upgradovat mikroslužbu pro konkrétní sadu zákazníků, aby před jejím širším zavedením otestovali nové funkce.
Interakce s dalšími mikroslužbami přes dobře definovaná rozhraní a protokoly
Za posledních 10 let byly publikovány rozsáhlé informace popisující komunikační vzory v architekturách orientovaných na služby. Obecně platí, že komunikace služby používá přístup REST s protokoly HTTP a TCP a XML nebo JSON jako formát serializace. Z hlediska rozhraní se jedná o přístup k návrhu webu. Ale nic by vám nemělo bránit v používání binárních protokolů nebo vlastních datových formátů. Mějte na paměti, že pokud tyto protokoly a formáty nebudou otevřené, budou mít uživatelé potíže s používáním vašich mikroslužeb.
Má jedinečný název (adresu URL) použitý k překladu svého umístění.
Mikroslužba musí být adresovatelná bez ohledu na to, kde je spuštěná. Pokud přemýšlíte o počítačích a o tom, který z nich spouští konkrétní mikroslužbu, může se to rychle pokazit.
Stejně jako DNS překládá konkrétní adresu URL na konkrétní počítač, potřebuje vaše mikroslužba jedinečný název, aby bylo možné zjistit její aktuální umístění. Mikroslužby potřebují adresovatelné názvy, které jsou nezávislé na infrastruktuře, na které běží. To znamená, že existuje interakce mezi tím, jak je vaše služba nasazena a jak se zjistí, protože musí existovat registr služby. Když počítač selže, musí vás služba registru informovat, kam se služba přesunula.
Zůstává konzistentní a k dispozici v případě selhání
Řešení neočekávaných selhání je jedním z nejtěžších problémů, které je potřeba vyřešit, zejména v distribuovaném systému. Většina kódu, který píšeme jako vývojáři, slouží ke zpracování výjimek. Během testování také trávíme nejvíce času zpracováním výjimek. Proces je více zapojen než psaní kódu pro zpracování selhání. Co se stane, když počítač, na kterém je mikroslužba spuštěná, selže? Potřebujete zjistit selhání, což je sám o sobě těžký problém. Musíte ale také restartovat mikroslužbu.
Kvůli dostupnosti musí být mikroslužba odolná vůči selháním a schopná restartovat se na jiném počítači. Kromě těchto požadavků na odolnost by se data neměla ztratit a data musí zůstat konzistentní.
Pokud během upgradu aplikace dojde k chybám, je obtížné dosáhnout odolnosti. Mikroslužba, která pracuje se systémem nasazení, se nemusí obnovovat. Potřebuje určit, jestli může pokračovat v přechodu na novější verzi, nebo se vrátit k předchozí verzi, aby se zachoval konzistentní stav. Je třeba zvážit několik otázek, jako je to, jestli je k dispozici dostatek počítačů, abyste mohli pokračovat vpřed, a jak obnovit předchozí verze mikroslužby. K těmto rozhodnutím potřebujete, aby mikroslužba vysílala informace o stavu.
Sestavy stavu a diagnostika
Může to vypadat jako běžné a často se to přehlíží, ale mikroslužba musí hlásit svůj stav a diagnostiku. Jinak máte malý přehled o jeho stavu z provozního hlediska. Korelace diagnostických událostí napříč sadou nezávislých služeb a zpracování nerovnoměrných dat strojového času, aby bylo možné vycítit pořadí událostí, je náročné. Stejně jako komunikujete s mikroslužbou přes schválené protokoly a formáty dat, musíte standardizovat způsob protokolování stavu a diagnostických událostí, které nakonec skončí v úložišti událostí pro dotazování a prohlížení. S přístupem k mikroslužbám se různé týmy musí dohodnout na jednom formátu protokolování. Musí existovat konzistentní přístup k zobrazení diagnostických událostí v aplikaci jako celku.
Stav se liší od diagnostiky. Stav je o tom, že mikroslužba hlásí svůj aktuální stav, aby podnikla příslušné akce. Dobrým příkladem je práce s mechanismy upgradu a nasazení, aby se zachovala dostupnost. I když služba může být momentálně v pořádku kvůli chybovému ukončení procesu nebo restartování počítače, může být stále funkční. Poslední věc, kterou potřebujete, je zhoršit situaci spuštěním upgradu. Nejlepším přístupem je nejprve prověřit nebo umožnit obnovení mikroslužby. Události stavu z mikroslužby nám pomáhají činit informovaná rozhodnutí a ve skutečnosti pomáhají vytvářet služby samoopravení.
Pokyny k návrhu mikroslužeb v Azure
Pokyny k návrhu a vytváření mikroslužeb v Azure najdete v Centru architektury Azure.
Service Fabric jako platforma mikroslužeb
Služba Azure Service Fabric se objevila, když Microsoft přešel od dodávání krabicových produktů, které byly obvykle monolitické, k poskytování služeb. Zkušenosti s vytvářením a provozem velkých služeb, jako jsou Azure SQL Database a Azure Cosmos DB, formovaly Service Fabric. Platforma se v průběhu času vyvíjela s tím, jak ji přijalo více služeb. Service Fabric musel běžet nejen v Azure, ale také v samostatných nasazeních Windows Serveru.
Cílem Service Fabric je vyřešit těžké problémy při vytváření a provozování služby a efektivně využívat prostředky infrastruktury, aby týmy mohly řešit obchodní problémy pomocí přístupu využívajícího mikroslužby.
Service Fabric pomáhá vytvářet aplikace, které používají přístup využívající mikroslužby, tím, že poskytuje:
- Platforma, která poskytuje systémové služby pro nasazení, upgrade, zjišťování a restartování služeb, které selhaly, zjišťování služeb, směrování zpráv, správu stavu a monitorování stavu.
- Možnost nasazovat aplikace spuštěné v kontejnerech nebo jako procesy. Service Fabric je orchestrátor kontejnerů a procesů.
- Rozhraní API pro produktivní programování, která vám pomůžou vytvářet aplikace jako mikroslužby: ASP.NET Core, Reliable Actors a Reliable Services. Můžete například získat informace o stavu a diagnostice nebo můžete využít výhod integrované vysoké dostupnosti.
Service Fabric je nezávislý na tom, jak vytváříte službu, a můžete použít jakoukoli technologii. Poskytuje ale integrovaná programovací rozhraní API, která usnadňují vytváření mikroslužeb.
Migrace existujících aplikací do Service Fabric
Service Fabric umožňuje opakovaně používat existující kód a modernizovat ho pomocí nových mikroslužeb. Modernizace aplikace má pět fází a v libovolné fázi můžete začít a zastavit. Fáze jsou:
- Začněte s tradiční monolitickou aplikací.
- Migrovat. K hostování existujícího kódu v Service Fabric použijte kontejnery nebo spustitelné soubory hosta.
- Modernizovat. Přidejte nové mikroslužby společně s existujícím kontejnerizovaným kódem.
- Inovovat. Rozdělte monolitickou aplikaci na mikroslužby podle potřeby.
- Transformujte aplikace na mikroslužby. Transformujte existující monolitické aplikace nebo sestavte nové aplikace na zelené louce.
Nezapomeňte, že můžete začít a zastavit v kterékoli z těchto fází. Nemusíte pokročit do další fáze.
Podívejme se na příklady pro každou z těchto fází.
Migrate
Mnoho společností migruje stávající monolitické aplikace do kontejnerů ze dvou důvodů:
- Snížení nákladů, a to buď z důvodu konsolidace a odebrání stávajícího hardwaru, nebo kvůli spouštění aplikací s vyšší hustotou.
- Konzistentní kontrakt nasazení mezi vývojem a provozem
Snížení nákladů je jednoduché. V Microsoftu se mnoho stávajících aplikací kontejnerizuje, což vede k úsporám v milionech dolarů. Konzistentní nasazení je těžší vyhodnotit, ale stejně důležité. To znamená, že si vývojáři můžou vybrat technologie, které jim vyhovují, ale operace budou přijímat pouze jednu metodu pro nasazení a správu aplikací. Zmírňují provoz, aby se nemusely zabývat složitostí podpory různých technologií, aniž by vývojáři museli vybírat jenom určité technologie. V podstatě se každá aplikace kontejnerizuje do samostatných imagí nasazení.
Mnoho organizací se tady zastaví. Už mají výhody kontejnerů a Service Fabric poskytuje kompletní prostředí pro správu, včetně nasazení, upgradů, správy verzí, vrácení zpět a monitorování stavu.
Modernizovat
Modernizace je přidání nových služeb spolu s existujícím kontejnerizovaným kódem. Pokud se chystáte psát nový kód, je nejlepší udělat malé kroky v cestě mikroslužeb. To může znamenat přidání nového koncového bodu rozhraní REST API nebo nové obchodní logiky. Tímto způsobem zahájíte proces vytváření nových mikroslužeb a procvičíte si jejich vývoj a nasazení.
Inovace
Přístup k mikroslužbám vyhovuje měnícím se obchodním potřebám. V této fázi se musíte rozhodnout, jestli chcete začít s rozdělením monolitické aplikace na služby nebo s inovacemi. Klasickým příkladem je, když se databáze, kterou používáte jako frontu pracovního postupu, stane kritickým bodem zpracování. S rostoucím počtem požadavků pracovního postupu je potřeba práci distribuovat pro účely škálování. Vezměte si konkrétní část aplikace, která se neškáluje nebo kterou je potřeba častěji aktualizovat, a rozdělte ji jako mikroslužbu a inovujte.
Transformace aplikací na mikroslužby
V této fázi se vaše aplikace plně skládá z mikroslužeb (nebo je rozdělená do). K dosažení tohoto bodu jste se vydali na cestu mikroslužeb. Můžete začít tady, ale to bez platformy mikroslužeb, která vám pomůže, vyžaduje značné investice.
Jsou mikroslužby pro mou aplikaci vhodné?
Podle potřeby. Když se v Microsoftu začalo z obchodních důvodů stavět více týmů pro cloud, mnoho z nich si uvědomilo výhody přístupu podobného mikroslužbám. Například Bing už léta používá mikroslužby. Pro ostatní týmy byl přístup k mikroslužbám nový. Týmy zjistily, že řešení problémů bylo obtížné vyřešit mimo své klíčové oblasti. To je důvod, proč Service Fabric získal trakci jako technologie pro vytváření služeb.
Cílem Service Fabric je snížit složitost při vytváření aplikací mikroslužeb, abyste nemuseli procházet tolik nákladným přepracováním. Začněte v malém, škálujte je v případě potřeby, vyřadíte služby, přidávejte nové a vyvíjet se s využitím zákazníků. Víme také, že je ještě potřeba vyřešit řadu dalších problémů, aby byla mikroslužba pro většinu vývojářů přístupnější. Kontejnery a programovací model objektu actor jsou příklady malých kroků v daném směru. Jsme si jistí, že se objeví další inovace, které usnadní přístup k mikroslužbám.