Proč při sestavování aplikací používat přístup k mikroslužbám
Pro vývojáře softwaru není faktoring 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 uživatelským rozhraním front-endu. V posledních několika letech se změnilo , že vývojáři vytvářejí distribuované aplikace pro cloud.
Tady je několik změn obchodních potřeb:
- Služba, která je vytvořená a provozovaná ve velkém měřítku, aby se dostala k zákazníkům v nových geografických oblastech.
- Rychlejší doručování funkcí a možností, které reagují na požadavky zákazníků agilním způsobem.
- 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: Revoluce aplikací využívající cloud.
Přístup k návrhu monolitických vs. mikroslužeb
Aplikace se v průběhu času vyvíjejí. Úspěšné aplikace se vyvíjejí tím, že jsou užitečné pro lidi. Neúspěšné aplikace se nevyvíjí a nakonec jsou zastaralé. Tady je otázka: kolik víte o vašich požadavcích dnes a o čem 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 bude platit jenom v rámci vaší společnosti a že sestavy se nebudou uchovávat dlouho. Váš přístup se bude lišit od vytvoření služby, která doručuje videoobsádek desítkám milionů zákazníků.
Někdy je hnacím faktorem získání něčeho ze dveří jako důkaz konceptu. Víte, že aplikaci můžete později přepracovat. V nadměrném inženýrství je něco, co se nikdy nepoužívá. Na druhou stranu, 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á dokáže zvládnout budoucí úspěch. Jedná se o štíhlý přístup při spuštění: sestavení, měření, učení a iterace.
Během období klienta/serveru jsme se zaměřili na vytváření vrstvených aplikací pomocí konkrétních technologií v každé vrstvě. Objevila se monolitická aplikace, která tyto přístupy popisuje. Rozhraní mají tendenci být mezi vrstvami a těsněji propojený návrh byl použit mezi komponentami v rámci každé vrstvy. Vývojáři navrhli a faktorovali třídy, které byly zkompilovány do knihoven a vzájemně propojené do několika spustitelných souborů a knihoven DLL.
Monolitický přístup k návrhu má několik výhod. Monolitické aplikace jsou často jednodušší a volání mezi komponentami jsou rychlejší, protože tato volání jsou často přes komunikaci mezi procesy (IPC). Každý také testuje jeden produkt, který má tendenci být efektivnějším využitím lidských zdrojů. Nevýhodou je, že mezi vrstvenými vrstvami existuje úzká vazba a nemůžete š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 přesněji odpovídají předchozím obchodním požadavkům. Mají však 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 škálovat na více systémů, testovat, nasazovat a spravovat nezávisle. Jednou z důležitých výhod přístupu k mikroslužbám je to, že týmy jsou řízeny více 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 pro údržbu aplikací mikroslužeb. Jednotlivé týmy, které vlastní služby, můžou dělat, co jim dává smysl na základě odborných znalostí týmu nebo co je nejvhodnější k vyřešení problému. V praxi je vhodnější sada doporučených technologií, jako je konkrétní úložiště NoSQL nebo architektura webových aplikací.
Nevýhodou mikroslužeb je, že musíte spravovat samostatnější entity a řešit složitější nasazení a správu verzí. Síťový provoz mezi mikroslužbami se zvyšuje, stejně jako odpovídající latence sítě. Spousta chatty, granulárních služeb může způsobit noční můru výkonu. Bez nástrojů, které vám pomůžou tyto závislosti zobrazit, je obtížné zobrazit celý systém.
Standardy umožňují, aby přístup k mikroslužbám fungoval tak, že určují, jak komunikovat a tolerovat pouze věci, které potřebujete ze služby, a ne pevné kontrakty. Tyto kontrakty je důležité definovat předem v návrhu, protože služby se aktualizují nezávisle na sobě. Dalším popisem návrhu s využitím přístupu mikroslužeb je "jemně odstupňovaná architektura zaměřená na služby (SOA)."
V nejjednodušším případě se přístup k návrhu mikroslužeb týká oddělené federace služeb s nezávislými změnami jednotlivých a dohodnutých standardů pro komunikaci.
S tím, jak se vytváří více cloudových aplikací, lidé zjistili, že toto rozložení celkové aplikace na nezávislé služby zaměřené na scénáře je lepší dlouhodobý přístup.
Porovnání přístupů k vývoji aplikací
Monolitická aplikace obsahuje funkce specifické pro doménu a obvykle je rozdělena do funkčních vrstev, jako je web, firma a data.
Monolitická aplikace můžete škálovat tak, že ji naklonujete na více serverech, virtuálních počítačích nebo kontejnerech.
Aplikace mikroslužeb odděluje funkce do samostatných menších služeb.
Přístup k mikroslužbám se škáluje nasazením jednotlivých služeb nezávisle a vytváří instance těchto služeb napříč servery, virtuálními počítači nebo kontejnery.
Návrh s využitím přístupu k mikroslužbám není vhodný pro všechny projekty, ale úzce odpovídá obchodním cílům popsaným výše. Pokud víte, že později budete mít možnost kód přepracovat do návrhu mikroslužeb, může mít začínat monolitickým přístupem. Častěji začínáte monolitickou aplikací a pomalu ji rozdělíte ve fázích, počínaje funkčními oblastmi, které musí být škálovatelné nebo agilnější.
Při použití přístupu k mikroslužbám vytvoříte aplikaci mnoha malých služeb. Tyto služby běží v kontejnerech nasazených v clusteru počítačů. Menší týmy vyvíjejí službu, která se zaměřuje na scénář a nezávisle testuje, verzi, nasazuje a škáluje každou službu, aby se celá aplikace vyvinula.
Co je mikroslužba?
Existují různé definice mikroslužeb. Většina z těchto charakteristik mikroslužeb je však široce přijímána:
- Zapouzdření zákazníka nebo obchodního scénáře Jaký problém řešíte?
- Vyvinul malý technický tým.
- Napsané v libovolném programovacím jazyce pomocí libovolné architektury.
- Skládají se z kódu a volitelně i stavu, z nichž obě jsou nezávislé verze, nasazené a škálované.
- 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í.
Sečtení:
Aplikace mikroslužeb se skládají z malých, nezávislých verzí a škálovatelných služeb zaměřených na zákazníky, které vzájemně komunikují přes standardní protokoly s dobře definovanými rozhraními.
Napsané v libovolném programovacím jazyce pomocí libovolné architektury
Jako vývojáři chceme mít volný výběr jazyka nebo architektury v závislosti na našich dovednostech a potřebách služby, kterou vytváříme. U některých služeb můžete ohodnotit výhody výkonu jazyka C++ nad čímkoli jiným. Pro ostatní může být jednodušší spravovaný vývoj, který získáte z C# nebo Javy, důležitější. V některých případech může být potřeba použít konkrétní partnerská knihovna, technologii úložiště dat nebo metodu pro zveřejnění služby klientům.
Po výběru technologie je potřeba zvážit provozní nebo životní cyklus správy a škálování služby.
Umožňuje nezávisle nařazovat verze kódu a stavu, nasazovat a škálovat.
Bez ohledu na to, jak píšete mikroslužby, kód a volitelně i stav, by se měly nezávisle nasazovat, upgradovat a škálovat. Tento problém je těžké vyřešit, protože jde o vaši volbu technologií. Pro škálování je pochopení toho, jak rozdělit (nebo horizontálně) kód i stav, je náročné. Když kód a stav používají různé technologie, které jsou dnes společné, musí být skripty nasazení pro vaši mikroslužbu schopné škálovat obojí. Toto oddělení je také o flexibilitě a flexibilitě, takže některé mikroslužby můžete upgradovat, aniž byste museli upgradovat všechny najednou.
Pojďme se na chvíli vrátit k porovnání monolitických přístupů a přístupů mikroslužeb. Tento diagram znázorňuje rozdíly v přístupech k ukládání stavu:
State Storage pro dva přístupy
Monolitický přístup nalevo má jednu databázi a vrstvy konkrétních technologií.
Přístup k mikroslužbám na pravé straně má graf 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í stavu. Týmy musí striktně oddělit stav, což je výzva. Někdo bude nutně chtít přidat sloupec do existující tabulky zákazníka, provést spojení mezi tabulkami a vytvořit závislosti ve vrstvě úložiště. Jakmile k tomu dojde, nemůžete š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 škálování kódu i stavu společně tak, aby splňovala požadavky služby. Nevýhodou je, že když potřebujete vytvářet zobrazení nebo dotazy na data vaší aplikace, musíte se dotazovat napříč několika úložišti stavů. Tento problém obvykle řeší samostatná mikroslužba, která vytváří zobrazení napříč kolekcí mikroslužeb. Pokud potřebujete na datech 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ého skladu pro offline analýzy.
Mikroslužby jsou verze. Je možné, aby různé verze mikroslužby běžely vedle sebe. Novější verze mikroslužby může při upgradu selhat a je potřeba ji vrátit zpět do starší verze. Správa verzí je užitečná také 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 určitou sadu zákazníků, aby si otestovali nové funkce předtím, než ji zpřístupníte častěji.
Interakce s jinými mikroslužbami přes dobře definovaná rozhraní a protokoly
Během 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á jako formát serializace přístup REST s protokoly HTTP a TCP a XML nebo JSON. Z pohledu rozhraní se jedná o přístup k návrhu webu. Neměli byste ale nic bránit v používání binárních protokolů nebo vlastních datových formátů. Mějte jen na paměti, že uživatelé budou mít obtížnější používání vašich mikroslužeb, pokud tyto protokoly a formáty nejsou otevřené.
Má jedinečný název (URL) používaný k překladu jeho umístění.
Mikroslužba musí být adresovatelná všude, kde je spuštěná. Pokud uvažujete o počítačích a o tom, na kterém běží konkrétní mikroslužba, může to být špatně.
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 jeho aktuální umístění bylo zjistitelné. Mikroslužby potřebují adresovatelné názvy, které jsou nezávislé na infrastruktuře, na které běží. To znamená, že mezi tím, jak je služba nasazená, a způsobem jeho zjištění existuje interakce, protože musí existovat registr služby. Když se počítač nezdaří, musí vám služba registru sdělit, kam se služba přesunula.
Zůstává konzistentní a dostupný v případě selhání
Řešení neočekávaných selhání je jedním z nejtěžších problémů při řešení, zejména v distribuovaném systému. Většina kódu, který píšeme jako vývojáři, je určená ke zpracování výjimek. Během testování také trávíme nejvíce času na zpracování výjimek. Tento 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 problém sám o sobě. Musíte ale také restartovat mikroslužbu.
V případě dostupnosti musí být mikroslužba odolná vůči selháním a schopná se restartovat na jiném počítači. Kromě těchto požadavků na odolnost by se neměla ztratit data a data musí zůstat konzistentní.
Odolnost je obtížné dosáhnout, když dojde k selháním během upgradu aplikace. Mikroslužba, která pracuje se systémem nasazení, se nemusí obnovit. Potřebuje určit, jestli se může pokračovat v přechodu k novější verzi, nebo se vrátit k předchozí verzi, aby zachoval konzistentní stav. Je potřeba vzít v úvahu několik otázek, jako je to, jestli je k dispozici dostatek počítačů, abyste mohli pokračovat v pohybu a jak obnovit předchozí verze mikroslužby. K těmto rozhodnutím potřebujete mikroslužbu, která bude generovat informace o stavu.
Sestavy stavu a diagnostiky
Může to vypadat jako běžné a často se přehlíží, ale mikroslužba musí hlásit svůj stav a diagnostiku. V opačném případě máte malý přehled o jeho stavu z hlediska provozu. Korelace diagnostických událostí napříč sadou nezávislých služeb a zpracování nerovnoměrné distribuce hodin počítačů, které mají smysl pro pořadí událostí, je náročné. Stejně jako s mikroslužbou pracujete s odsouhlasenými protokoly a formáty dat, musíte standardizovat, jak protokolovat události stavu a diagnostiky, které nakonec skončí v úložišti událostí pro dotazování a prohlížení. S přístupem k mikroslužbám musí různé týmy souhlasit s jedním formátem protokolování. Musí existovat konzistentní přístup k zobrazení diagnostických událostí v aplikaci jako celku.
Stav se liší od diagnostiky. Stav mikroslužby hlásí aktuální stav, aby bylo potřeba provést příslušné akce. Dobrým příkladem je práce s mechanismy upgradu a nasazení pro zachování dostupnosti. I když služba kvůli chybovému ukončení procesu nebo restartování počítače v současné době není v pořádku, může být služba stále funkční. Poslední věcí, kterou potřebujete, je zhoršovat situaci spuštěním upgradu. Nejlepším přístupem je nejprve prozkoumat mikroslužbu nebo umožnit, aby se mikroslužba obnovila. Události stavu z mikroslužby nám pomáhají činit informovaná rozhodnutí a v podstatě pomáhají vytvářet samoobslužné opravy.
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
Azure Service Fabric se objevila, když Microsoft přešel z dodávání krabicových produktů, které byly obvykle monolitické, na 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, mají tvar 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 sestavování a provozování služby a efektivně využívat prostředky infrastruktury, aby týmy mohly řešit obchodní problémy pomocí přístupu k mikroslužbám.
Service Fabric pomáhá sestavovat aplikace, které používají přístup k mikroslužbám, a to poskytnutím:
- Platforma, která poskytuje systémové služby pro nasazení, upgrade, zjišťování a restartování služeb, zjišťování služeb, směrování zpráv, správu stavu a monitorování stavu.
- Schopnost nasazovat aplikace spuštěné v kontejnerech nebo jako procesy. Service Fabric je orchestrátor kontejnerů a procesů.
- Produktivní programovací rozhraní API, 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 libovolnou 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. K modernizaci aplikace existuje pět fází a v libovolné fázi můžete spustit a zastavit. Fáze jsou:
- Začněte tradiční monolitickou aplikací.
- Migrace. Použijte kontejnery nebo spustitelné soubory hosta k hostování existujícího kódu v Service Fabric.
- Modernizovat. Přidejte nové mikroslužby spolu s existujícím kontejnerizovaným kódem.
- Inovujte. Rozdělte monolitickou aplikaci na mikroslužby na základě potřeby.
- Transformujte aplikace na mikroslužby. Transformujte stávající monolitické aplikace nebo sestavte nové aplikace zeleně.
Nezapomeňte, že můžete začít a zastavit v kterékoli z těchto fází. Nemusíte pokračovat k další fázi.
Podívejme se na příklady pro každou z těchto fází.
Migrace
Z dvou důvodů mnoho společností migruje existující monolitické aplikace do kontejnerů:
- Snížení nákladů buď kvůli konsolidaci 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 je mnoho stávajících aplikací kontejnerizováno, což vede k milionům dolarů v úsporách. Konzistentní nasazení je obtížnější vyhodnotit, ale stejně důležité. Znamená to, že vývojáři můžou zvolit technologie, které jim vyhovují, ale operace budou přijímat pouze jednu metodu pro nasazení a správu aplikací. Zmírní operace, protože se musí vypořádat se složitostí podpory různých technologií, aniž by vývojáři museli vybírat jen určité technologie. Každá aplikace je v podstatě kontejnerizovaná 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 budete psát nový kód, je nejlepší provést malé kroky v cestě k mikroslužbám. 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í.
Inovovat
Přístup k mikroslužbám se přizpůsobí měnícím se obchodním potřebám. V této fázi se musíte rozhodnout, jestli se má monolitická aplikace rozdělit na služby nebo inovovat. Klasický příklad 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 distribuovat práci pro škálování. Vezměte si konkrétní část aplikace, která se nes škáluje nebo která je potřeba aktualizovat častěji, a rozdělte ji jako mikroslužbu a inovace.
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 provedli cestu k mikroslužbám. Můžete začít zde, ale můžete to udělat bez platformy mikroslužeb, která vám pomůže vyžadovat významnou investici.
Jsou mikroslužby pro mou aplikaci správné?
Podle potřeby. V Microsoftu, protože z obchodních důvodů začaly vytvářet více týmů z cloudu, mnoho z nich si uvědomilo výhody přístupu podobného mikroslužbám. Bing například už roky používá mikroslužby. Pro ostatní týmy byl přístup k mikroslužbám nový. Týmy zjistily, že došlo k těžkým problémům při řešení mimo jejich základní oblasti síly. Proto služba Service Fabric získala trakci jako technologie pro vytváření služeb.
Cílem Service Fabric je snížit složitost vytváření aplikací mikroslužeb, abyste nemuseli procházet tolik nákladných úprav. V případě potřeby začněte s malým škálováním, vyřadit služby, přidávat nové a vyvíjet se s využitím zákazníků. Víme také, že existuje mnoho dalších problémů, které je ještě potřeba vyřešit, aby byly mikroslužby pro většinu vývojářů přístupnější. Příkladem malých kroků v daném směru jsou kontejnery a programovací model objektu actor. Jsme si jistí, že se objeví další inovace, abychom usnadnili přístup k mikroslužbám.