Kontext

Vyvíjíte podnikovou aplikaci na straně serveru. Musí podporovat celou řadu různých klientů, včetně prohlížečů pro stolní počítače, mobilních prohlížečů a nativní mobilní aplikace. Aplikace může také vystavit API, které spotřebují třetí strany. Může se také integrovat s jinými aplikacemi prostřednictvím webových služeb nebo zprostředkovatele zpráv. Aplikace zpracovává požadavky (požadavky HTTP a zprávy) prováděním obchodní logiky; přístup do databáze; výměna zpráv s jinými systémy; a vrácení odpovědi HTML / JSON / XML. Existují logické komponenty odpovídající různým funkčním oblastem aplikace.

Problém

Jaká je architektura nasazení aplikace?

Forces

• Na aplikaci pracuje tým vývojářů
• Noví členové týmu musí být rychle produktivní
• Aplikace musí být snadno pochopitelná a upravit
• Chcete si vyzkoušet nepřetržité nasazení aplikace
• Abyste mohli splnit požadavky na škálovatelnost a dostupnost, musíte spustit více instancí aplikace na více počítačích
• Chcete využít výhody vznikajících technologií (rámce, programovací jazyky atd.)

Řešení

Definujte architekturu, která strukturuje aplikaci jako sadu volně spojených, spolupracující služby. Tento přístup odpovídá ose Y Scale Cube. Každá služba je:

• Vysoce udržovatelná a testovatelná – umožňuje Pid a častý vývoj a nasazení
• Volně spojený s dalšími službami – umožňuje týmu pracovat většinu času nezávisle na svých službách, aniž by byl ovlivněn změnami jiných služeb a aniž by to ovlivnilo jiné služby
• Nezávisle nasaditelný – umožňuje týmu nasadit své služby bez nutnosti koordinace s jinými týmy
• Schopnost vývoje malým týmem – nezbytná pro vysokou produktivitu tím, že se vyhne vysoké komunikační hlavě velkých týmy

Služby komunikují pomocí synchronních protokolů, jako je HTTP / REST, nebo asynchronních protokolů, jako je AMQP. Služby lze vyvíjet a nasazovat nezávisle na sobě. Každá služba má svou vlastní databázi, aby být oddělen od ostatních služeb. Konzistence dat mezi službami je udržována pomocí Saga vzoru.

Chcete-li se dozvědět více o povaze služby, přečtěte si tento článek.

Příklady

Fiktivní aplikace elektronického obchodování on

Představme si, že vytváříte aplikaci pro elektronické obchodování, která přijímá objednávky od zákazníků, ověřuje zásoby a dostupný kredit a dodává je. Aplikace se skládá z několika komponent včetně StoreFrontUI, které implementuje uživatelské rozhraní , spolu s některými backendovými službami pro kontrolu kreditu, údržbu inventáře a přepravní objednávky. Aplikace se skládá ze sady služeb.

Ukaž mi kód

Přečtěte si ukázkové aplikace vyvinuté Chrisem Richardsonem. Tyto příklady na Githubu ilustrují různé aspekty architektury mikroslužeb.

Výsledný kontext

Výhody

Toto řešení má řadu výhod:

• Umožňuje nepřetržité doručování a nasazování velkých a složitých aplikací.
  • Vylepšená udržovatelnost – každá služba je relativně malá, a proto je snazší ji pochopit a změnit
  • Lepší testovatelnost – služby jsou menší a rychlejší k testování
  • Lepší nasazení – služby lze nasadit samostatně
  • Umožňuje vám organizovat vývojové úsilí kolem několika samostatných týmů. Každý tým (tzv. Dvě pizzy) vlastní a odpovídá za jednu nebo více služeb. Každý tým může vyvíjet, testovat, nasazovat a škálovat své služby nezávisle na všech ostatních týmech.
• Každá mikroslužba je relativně malá:
  • Jednodušší pro vývojář rozumí
  • IDE je rychlejší, což zvyšuje produktivitu vývojářů
  • aplikace se spouští rychleji, což zvyšuje produktivitu vývojářů a urychluje nasazení
• Vylepšená izolace chyb. Například pokud v jedné službě dojde k úniku paměti, bude ovlivněna pouze tato služba. Ostatní služby budou nadále zpracovávat požadavky. Ve srovnání může jedna nesprávně fungující součást monolitické architektury snížit celý systém.
• Eliminuje jakýkoli dlouhodobý závazek k technologickému zásobníku. Při vývoji nové služby si můžete vybrat nový technologický zásobník. Podobně při provádění zásadních změn ve stávající službě ji můžete přepsat pomocí nového technologického zásobníku.

Nevýhody

Toto řešení má řadu nevýhod:

• Vývojáři se musí vypořádat s další složitostí vytváření distribuovaného systému:
  • Vývojáři musí implementovat mechanismus mezioborové komunikace a vypořádat se s částečným selháním
  • Implementace požadavků zahrnujících více služeb je obtížnější
  • Testování interakcí mezi službami je mnohem náročnější obtížné
  • Implementace požadavků, které zahrnují více služeb, vyžaduje pečlivou koordinaci mezi týmy.
  • Vývojářské nástroje / IDE jsou orientovány na vytváření monolitických aplikací a neposkytují výslovnou podporu pro vývoj distribuovaných aplikací.
• Složitost nasazení. Ve výrobě existuje také provozní složitost nasazení a správy systému složeného z mnoha různých služeb.
• Zvýšená spotřeba paměti. Architektura mikroslužeb nahrazuje instance N monolitických aplikací instancemi služeb NxM. Pokud každá služba běží ve svém vlastním JVM (nebo ekvivalentním), což je obvykle nutné k izolaci instancí, pak existuje režie M krát tolik běhových modulů JVM. Pokud navíc každá služba běží na svém vlastním virtuálním počítači (např. Instance EC2), jak je tomu v případě Netflixu, režie je ještě vyšší.

Problémy

Existují mnoho problémů, které musíte řešit.

Kdy použít architekturu mikroslužeb?

Jednou z výzev při použití tohoto přístupu je rozhodnout, kdy má smysl jej použít. Při vývoji první verze aplikace, často nemáte problémy, které tento přístup řeší. Kromě toho použití propracované distribuované architektury zpomalí vývoj. To může být velkým problémem pro startupy, jejichž největší výzvou je často, jak rychle vyvinout obchodní model a doprovodné Použití rozdělení osy Y může ztěžovat rychlou iteraci. Později však, když je výzvou způsob škálování a potřebujete použít funkční rozklad, zamotané závislosti mohou zkomplikovat rozložení vaší monolitické aplikace na soubor služeb.

Jak rozložit aplikaci do služeb?

Další výzvou je rozhodování o tom, jak rozdělit systém na mikroslužby. Je to umění, ale existuje řada strategií, které vám mohou pomoci:

• Rozložit podle obchodních schopností a definovat služby odpovídající obchodním schopnostem.
• Rozložit podle domény řízené subdomény designu.
• Rozložit podle slovesa nebo použít případ a definovat služby, které jsou odpovědné za konkrétní akce . např. a Shipping Service odpovědný za odeslání úplných objednávek.
• Rozložte se podstatnými jmény nebo prostředky definováním služby, která odpovídá za všechny operace s entitami / prostředky daného typ. např. Account Service odpovědný za správu uživatelských účtů.

V ideálním případě by každá služba měla mít jen malou sadu odpovědností. (strýc) Bob Martin hovoří o navrhování tříd pomocí principu jednotné odpovědnosti (SRP). SRP definuje odpovědnost třídy jako důvod ke změně a uvádí, že třída by měla mít pouze jeden důvod ke změně. Má smysl použít SRP na design služeb také.

Další analogií, která pomáhá s návrhem služeb, je návrh unixových utilit. Unix poskytuje velké množství utilit, jako jsou grep, cat a find. Každá utilita dělá přesně jednu věc, často výjimečně dobře, a je zamýšleno ke kombinování s dalšími obslužnými programy pomocí skriptu shellu k provádění složitých úkolů.

Jak zachovat konzistenci dat?

Aby byla zajištěna volná vazba, každá služba má své vlastní databáze. Zachování konzistence dat mezi službami je výzvou, protože 2 transakce fázového potvrzení / distribuce nejsou možnost pro mnoho aplikací.Aplikace musí místo toho použít vzor Saga.Služba publikuje událost, když se změní její data.Ostatní služby tuto událost spotřebují a aktualizují svá data.Existuje několik způsobů spolehlivé aktualizace dat a publikování událostí, včetně Event Sourcing a Sledování protokolu transakcí.

Jak implementovat dotazy?

Další výzvou je implementace dotazů, které potřebují načíst data vlastněná více službami.

• API Složení a vzory segregace odpovědnosti za příkazové dotazy (CQRS).

Existuje mnoho vzorů souvisejících se vzorem mikroslužeb. Monolitická architektura je alternativou k architektuře mikroslužeb. Ostatní vzory řeší problémy, se kterými se setkáte při použití architektury mikroslužeb.

• Decomposition patterns
  • Decompose by business capability
  • Decompose by subdomain
• The Database per Service pattern describes how each služba má vlastní databázi, aby bylo zajištěno volné propojení.
• Vzor brány API definuje, jak klienti přistupují ke službám v architektuře mikroslužeb.
• Vzory zjišťování na straně klienta a zjišťování na straně serveru se používají k směrování požadavků pro klienta na dostupná instance služby v architektuře mikroslužeb.
• Vzory zasílání zpráv a vzdálené procedury jsou dva různé způsoby, kterými mohou služby komunikovat.
• Vzory jedné služby na hostitele a více služeb na hostitele jsou dvě různé strategie nasazení.
• Vzory průřezových problémů: Vzor šasi mikroslužeb a Externí konfigurace
• Testovací vzory: Test komponent služby a Test smlouvy o integraci služby
• Okruh Breaker
• Přístupový token
• Vzory pozorovatelnosti:
  • Agregace protokolu
  • Metriky aplikace
  • Protokolování auditu
  • Distribuované trasování
  • Sledování výjimek
  • Kontrola stavu API
  • Protokolovat nasazení a změny
• Vzory uživatelského rozhraní:
  • Složení fragmentu stránky na straně serveru
  • Složení uživatelského rozhraní na straně klienta

Známá použití

Většina rozsáhlých webových stránek, včetně Netflix, Amazon a eBay, se vyvinula z monolitické architektury do architektury mikroslužeb.

Netflix, což je velmi populární služba pro streamování videa, která je zodpovědná až 30% internetového provozu, má rozsáhlou architekturu orientovanou na služby. Zpracovávají více než miliardu volání denně na jejich API pro streamování videa z více než 800 různých druhů zařízení. Každé API volá fanoušky v průměru na šest volání back-endových služeb.

Amazon.com měla původně dvoustupňovou architekturu. Aby bylo možné škálovat, migrovaly na architekturu orientovanou na služby skládající se ze stovek back-endových služeb. Několik aplikací tyto služby volá, včetně aplikací které implementují web Amazon.com a API webových služeb. Webová aplikace Amazon.com volá 100-150 služeb, aby získala data, která byla použita k vytvoření webové stránky.

Aukční web ebay.com se také vyvinul z monolitické architektury na architekturu orientovanou na služby. Aplikační vrstva se skládá z několika nezávislých aplikací. Každá aplikace implementuje obchodní logiku pro konkrétní funkční oblast, jako je nákup nebo prodej. Každá aplikace používá rozdělení osy X a některé aplikace, jako je vyhledávání, používají rozdělení osy Z. WebBay.com také použije kombinaci škálování ve stylu X, Y a Z na databázová vrstva.

Existuje řada dalších příkladů společností využívajících architekturu mikroslužeb.

Chris Richardson má příklady aplikací založených na mikroslužbách.

Viz také

Viz můj Keynote Code Freeze 2018, který poskytuje dobrý úvod do architektury mikroslužeb.