Proč při sestavování aplikací používat přístup k mikroslužbám

Článek
2025-04-08

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? Představte si, že vytváříte aplikaci pro reportování pro oddělení ve vaší společnosti. Jste si jistí, že aplikace platí jenom v rámci vaší společnosti, a že sestavy nebudou uchovávány 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 rychlé dokončení něčeho jako důkaz konceptu. Víte, že aplikaci můžete později přepracovat. Nemá smysl nadměrně navrhovat něco, co se nikdy nepoužije. 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žbu na základě scénáře zákazníka a používají všechny technologie, které chtějí 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í

Vývoj aplikací platformy Service Fabric

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. Začít s monolitickým přístupem může dávat smysl, pokud víte, že později budete mít možnost přepracovat kód do návrhu mikroslužeb. Č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:

Popis zákaznického 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, které jsou obě nezávisle verzovány, nasazovány a škálovány.
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 určení jejich umístění.
Zůstaňte konzistentní a k dispozici v případě selhání.

Shrnutí:

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 kódu a stavu nezávislé verzování, nasazování a škálování.

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 náročné pochopit, jak rozdělit (nebo rozřezávat) kód i stav. 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í se týká také agility a flexibility, takže můžete upgradovat některé mikroslužby, 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:

Ukládání stavu pro dva přístupy

Úložiště stavu platformy Service Fabric

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 verzovány. 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 určení 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 komplexnější 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í, nemusí být obnovena. 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.

Zprávy o zdraví a diagnostice

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í nesouhlasů hodin počítačů pro určení správného 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. Zdraví spočívá v tom, že mikroslužba hlásí svůj aktuální stav, aby bylo možné provést příslušné kroky. 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 zdraví z mikroslužby nám pomáhají činit informovaná rozhodnutí a v podstatě pomáhají vytvářet samoopravné služby.

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, detekci selhání a restartování služeb, objevování služeb, směrování zpráv, správu stavu a monitorování zdravotního 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í.
Migrovat. Použijte kontejnery nebo spustitelné soubory hosta k hostování existujícího kódu v Service Fabric.
Modernizuj. Přidejte nové mikroslužby spolu s existujícím kontejnerizovaným kódem.
Inovovat. 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 z nuly.

Migrace do mikroslužeb

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írňuje pracovníkům operací potřebu vypořádat se se složitostí zajištění podpory různých technologií, aniž by tím omezovalo vývojáře na výběr jen určitých technologií. 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 neškáluje nebo kterou je potřeba aktualizovat častěji, 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 absolvovali cestu mikroslužbami. Můžete začít zde, ale pokud tak učiníte bez platformy mikroslužeb, která vám pomůže, bude to vyžadovat významnou investici.

Jsou mikroslužby pro mou aplikaci správné?

Možná. Jak více týmů v Microsoftu začalo budovat pro cloud z obchodních důvodů, 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 si platforma Service Fabric získala oblibu 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. Začněte v malém, škálujte podle potřeby, postupně ukončujte služby, přidávejte nové a vyvíjejte se podle využití 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.

Sdílet prostřednictvím