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 to, že vývojáři vytvářejí distribuované aplikace pro cloud.

Tady je několik měnících se 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í 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í tím, že jsou užitečné pro lidi. Neúspěšné aplikace se nevyvinou a nakonec se přestanou používat. 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 platí jenom v rámci vaší společnosti a že se sestavy nebudou uchovávat dlouho. Váš přístup se bude lišit od toho, z toho například vytvoření služby, která poskytuje videoobsílům desítky milionů zákazníků.

Někdy je jako důkaz konceptu něco mimo dveře. Víte, že aplikaci můžete později přepracovat. V nadměrném inženýrství je něco, co se nikdy nepoužilo. 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í: sestavování, měření, učení a iterace.

Během období klienta/serveru se zaměřujeme 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 úzce propojený návrh byl použit mezi komponentami v každé vrstvě. Vývojáři navrhli a faktorovali třídy kompilované do knihoven a propojili je do několika spustitelných souborů a knihoven DLL.

Monolitický přístup k návrhu přináší výhody. Monolitické aplikace se často snadněji navrhují a volání mezi komponentami jsou rychlejší, protože tato volání jsou často přes komunikaci mezi procesy (IPC). Všichni také testují 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á spojka 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í ale také výhody i závazky. Výhody mikroslužeb jsou, že každá z nich obvykle zapouzdřuje jednodušší obchodní funkce, které můžete škálovat na více instancí, 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 nemusí standardizovat technologie pro údržbu aplikací mikroslužeb. Jednotlivé týmy, které vlastní služby, můžou dělat, co pro ně 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 chatovacích, 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 přistupují k mikroslužbám tak, že určují, jak komunikovat a tolerovat jenom to, co potřebujete z nějaké služby, a ne pevné kontrakty. Tyto kontrakty je důležité definovat předem v návrhu, protože služby se vzájemně 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 odsouhlasených standardů pro komunikaci.

Vzhledem k tomu, že se vytváří více cloudových aplikací, lidé zjistili, že toto rozkladové rozložení celkové aplikace na nezávislé služby zaměřené na scénáře představuje lepší dlouhodobý přístup.

Porovnání přístupů k vývoji aplikací

Service Fabric platform application development

  1. Monolitická aplikace obsahuje funkce specifické pro doménu a je obvykle rozdělena do funkčních vrstev, jako je web, firma a data.

  2. Monolitickou aplikaci můžete škálovat tak, že ji naklonujete na více serverech, virtuálních počítačích nebo kontejnerech.

  3. Aplikace mikroslužeb odděluje funkce do samostatných menších služeb.

  4. Přístup k mikroslužbám se škáluje tak, že každou službu nasadí nezávisle a vytvoří 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 budete mít možnost kód později přepracovat do návrhu mikroslužeb, může to mít smysl začít 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é potřebují 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 může vyvíjet.

Co je mikroslužba?

Existují různé definice mikroslužeb. Většina těchto charakteristik mikroslužeb je ale široce přijatá:

  • Zapouzdřte zákazníka nebo obchodní scénář. 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ž oba jsou nezávisle na verzích, nasazených a škálovaných.
  • 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í.

Shrnout to takto:

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 pomocí 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 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 jazyka C# nebo Java, důležitější. V některých případech může být potřeba použít konkrétní knihovnu partnerů, technologii úložiště dat nebo metodu vystavení 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 verzích, nasazení a škálování kódu a stavu.

Bez ohledu na to, jak píšete mikroslužby, kód a volitelně i stav, by se měl 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í způsobu dělení (nebo horizontálního dělení) kódu i stavu náročné. Když kód a stav používají různé technologie, což je dnes běžné, skripty nasazení pro vaši mikroslužbu musí být schopné je škálovat obě. Toto oddělení je také o flexibilitě a flexibilitě, takže můžete některé mikroslužby 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ů k mikroslužbám. Tento diagram znázorňuje rozdíly v přístupech k ukládání stavu:

State Storage pro dva přístupy

Service Fabric platform state storage

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 se stav obvykle vztahuje 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 stát, což je výzva. Někdo bude mít tendenci přidávat sloupec do existující tabulky zákazníků, provádět spojení mezi tabulkami a vytvářet závislosti na 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 je zodpovědná za škálování kódu i stavu společně tak, aby splňovala požadavky služby. Nevýhodou je to, že když potřebujete vytvořit 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 spustit několik improvizující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 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 dřívější 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 před uvedením do širšího rozsahu otestovali nové funkce.

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. Komunikace služby obecně 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ás nemělo zastavit v používání binárních protokolů nebo vlastních datových formátů. Mějte na paměti, že uživatelé budou mít obtížnější používání mikroslužeb, pokud tyto protokoly a formáty nejsou otevřené.

Má jedinečný název (URL) použitý k překladu jeho umístění.

Vaše mikroslužba musí být adresovatelná všude, kde je spuštěná. Pokud přemýšlíte o počítačích a o tom, na kterém běží konkrétní mikroslužba, může se to rychle zkazit.

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 jeho 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 mezi tím, jak je vaše služba nasazená a jak je zjištěna, existuje interakce, protože musí existovat registr služeb. Když dojde k selhání počítače, služba registru vás musí informovat o tom, 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ů, 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, je určená ke zpracování výjimek. Během testování také trávíme nejvíce času na zpracování 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 spuštěná mikroslužba, selže? Potřebujete zjistit selhání, což je problém sám o sobě. Musíte ale také restartovat mikroslužbu.

Kvůli dostupnosti musí být mikroslužba odolná vůči chybám a schopná restartovat 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í.

Odolnost je obtížné dosáhnout při selhání během upgradu aplikace. Mikroslužba, která pracuje se systémem nasazení, se nemusí obnovit. Musí určit, jestli může pokračovat v přechodu na novější verzi, nebo se vrátit k předchozí verzi, aby zachoval konzistentní stav. Musíte zvážit 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.

Hlášení stavu a diagnostiky

Může to vypadat jako běžné a často je přehlédnuto, 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 pohledu provozu. Korelace diagnostickýchudálostchm službám nezávislá sada služeb a řešení nerovnoměrných časových šikm Stejně jako v případě, že komunikujete s mikroslužbou přes schválené 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žeb hlásí svůj aktuální stav, aby podnikl odpovídající akce. Dobrým příkladem je práce s mechanismy upgradu a nasazení pro zachování dostupnosti. I když může být služba momentálně v pořádku kvůli chybovému ukončení procesu nebo restartování počítače, může být služba stále funkční. Poslední věcí, kterou potřebujete, je zhoršit situaci spuštěním upgradu. Nejlepším řešením je nejprve prozkoumat mikroslužbu nebo umožnit, aby se mikroslužba obnovila. Zdravotní události z mikroslužby nám pomáhají při informovaných rozhodnutích a ve skutečnosti pomáhají vytvářet samoobslužné 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 objevil, když Microsoft přešel z dodávky 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, protože 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 vám pomůže 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í neúspěšných služeb, zjišťování služeb, směrování zpráv, správu stavu a monitorování stavu.
  • Schopnost nasazovat aplikace buď 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 sestavovat 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 integrované vysoké dostupnosti.

Service Fabric je nezávislý na tom, jak službu sestavíte, 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 stávající kód a modernizovat ho pomocí nových mikroslužeb. Modernizace aplikací je 5 fází a můžete ji spustit a zastavit v libovolné fázi. Fáze jsou:

  1. Začněte s tradiční monolitickou aplikací.
  2. Migrovat. K hostování existujícího kódu v Service Fabric použijte kontejnery nebo spustitelné soubory hosta.
  3. Modernizovat. Přidejte nové mikroslužby spolu s existujícím kontejnerizovaným kódem.
  4. Inovovat. Rozdělte monolitickou aplikaci do mikroslužeb na základě potřeby.
  5. Transformujte aplikace na mikroslužby. Transformujte existující monolitické aplikace nebo sestavte nové aplikace ze zeleného pole.

Migration to microservices

Nezapomeňte, že můžete začít a zastavit v některé z těchto fází. Nemusíte pokračovat do další fáze.

Podívejme se na příklady pro každou z těchto fází.

Migrate
Z dvou důvodů mnoho společností migruje existující monolitické aplikace do kontejnerů:

  • Snížení nákladů, ať už 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 se kontejnerizuje mnoho stávajících aplikací, 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 nasazení a správy aplikací. Zmírní operace, aby se musely zabývat složitostí podpory různých technologií, aniž by vývojáři museli vybírat jen některé z nich. 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 se stávajícím kontejnerizovaným kódem. Pokud napíšete 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 jejich vývoj a nasazení.

Inovace
Přístup mikroslužeb vyhovuje měnícím se obchodním potřebám. V této fázi se musíte rozhodnout, jestli chcete začít rozdělit monolitickou aplikaci na služby nebo inovovat. 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 žádostí o pracovní postupy je potřeba práci distribuovat pro škálování. Vezměte konkrétní část aplikace, která není škálování 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ělena do). Abyste se dostali k tomuto bodu, udělali jste 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 více týmů začalo vytvářet z cloudových důvodů z obchodních důvodů, mnoho z nich si uvědomilo výhody přístupu podobného mikroslužbám. Bing například už několik let používá mikroslužby. Pro ostatní týmy byl přístup mikroslužeb nový. Týmy zjistily, že byly těžké problémy vyřešit mimo jejich základní oblasti síly. Proto 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. Začněte s malými, škálujte v případě potřeby, zastarejte služby, přidejte nové a vyvíjet se s využitím zákazníků. Také víme, že existuje mnoho dalších problémů, které je ještě potřeba vyřešit, aby byly mikroslužby přístupnější pro většinu vývojářů. Kontejnery a programovací model actor jsou příklady malých kroků v daném směru. Jsme si jistí, že se objeví další inovace, abychom usnadnili přístup k mikroslužbám.

Další kroky