Tento článek popisuje, jak pomocí návrhu řízeného doménou (DDD) migrovat monolitické aplikace do mikroslužeb.
Monolitická aplikace je obvykle aplikační systém, ve kterém jsou všechny příslušné moduly zabaleny společně jako jedna nasaditelná jednotka provádění. Může to být například webová aplikace v Javě (WAR) spuštěná na Tomcatu nebo asp. NET spuštěná ve službě IIS. Typická monolitická aplikace používá vrstvený návrh se samostatnými vrstvami pro uživatelské rozhraní, logiku aplikace a přístup k datům.
Tyto systémy začínají v malém, ale mají tendenci se v průběhu času rozrůstat, aby splňovaly obchodní potřeby. V určitém okamžiku, když se přidají nové funkce, může monolitická aplikace začít trpět následujícími problémy:
- Jednotlivé části systému nelze nezávisle škálovat, protože jsou úzce propojené.
- Je obtížné udržovat kód kvůli těsnému propojení a skrytým závislostem.
- Testování je obtížnější a zvyšuje se pravděpodobnost zavedení ohrožení zabezpečení.
Tyto problémy se mohou stát překážkou budoucího růstu a stability. Týmy začnou při provádění změn opatrovat, zejména pokud původní vývojáři už na projektu nepracují a dokumenty návrhu jsou řídké nebo zastaralé.
Navzdory těmto omezením může monolitický návrh dávat smysl jako výchozí bod pro aplikaci. Monolity jsou často nejrychlejší cestou k vytvoření testování konceptu nebo minimálního životaschopného produktu. V raných fázích vývoje mají monolity tendenci být:
- Jednodušší sestavení, protože existuje jeden sdílený základ kódu.
- Jednodušší ladění, protože kód běží v rámci jednoho procesu a prostoru paměti.
- Je to jednodušší, protože existuje méně pohyblivých částí.
S rostoucí složitostí aplikace však tyto výhody můžou vymizet. Velké monolity jsou často progresivně obtížnější sestavovat, ladit a uvažovat o nich. V určitém okamžiku problémy převáží výhody. To je bod, kdy může dávat smysl migrovat aplikaci na architekturu mikroslužeb. Na rozdíl od monolitů jsou mikroslužby obvykle decentralizované, volně propojené jednotky provádění. Následující diagram znázorňuje typickou architekturu mikroslužeb:
Migrace monolitu do mikroslužby vyžaduje značné množství času a investic, aby se zabránilo selháním nebo přetečením. Aby byla migrace úspěšná, je dobré porozumět výhodám i výzvám, které mikroslužby přináší. Nabízí například tyto výhody:
- Služby se můžou vyvíjet nezávisle na základě potřeb uživatelů.
- Služby se můžou škálovat nezávisle, aby uspokojily poptávku uživatelů.
- Postupem času se vývojové cykly zrychlovnou, protože funkce se dají rychleji vydávat na trh.
- Služby jsou izolované a jsou tolerantnější k selhání.
- Jedna služba, která selže, nespustí celou aplikaci.
- Testování bude koherentní a konzistentnější s využitím vývoje založeného na chování.
Další informace o výhodách a výzvách mikroslužeb najdete v tématu Styl architektury mikroslužeb.
Použití návrhu řízeného doménou
Jakákoli strategie migrace by měla týmům umožnit přírůstkové refaktoringování aplikace do menších služeb a zároveň poskytovat kontinuitu služeb koncovým uživatelům. Tady je obecný přístup:
- Přestaňte do monolitu přidávat funkce.
- Rozdělte front-end od back-endu.
- Rozložte a oddělte monolit do řady mikroslužeb.
Pro usnadnění tohoto rozkladu je životaschopným přístupem k vývoji softwaru použití principů návrhu řízeného doménou (DDD).
Domain Driven Design (DDD) je přístup k vývoji softwaru, který poprvé představil Eric Evans. DDD vyžaduje dobrou znalost domény, pro kterou bude aplikace napsána. Znalosti potřebné k vytvoření aplikace se nacházejí v lidech, kteří jí rozumí – v doménových expertech.
Přístup DDD lze použít zpětně u existující aplikace jako způsob, jak zahájit rozklad aplikace.
Začněte všudypřítomným jazykem, společnou slovní zásobou, která se sdílí mezi všemi zúčastněnými stranami.
Identifikujte relevantní moduly v monolitické aplikaci a použijte pro ně společnou slovní zásobu.
Definujte doménové modely monolitické aplikace. Doménový model je abstraktní model obchodní domény.
Definujte ohraničené kontexty pro modely. Ohraničený kontext je hranice v rámci domény, na které se vztahuje konkrétní model domény. Použijte explicitní hranice s jasně definovanými modely a odpovědnostmi.
Ohraničené kontexty uvedené v kroku 4 jsou kandidáty pro refaktoring do menších mikroslužeb. Následující diagram znázorňuje existující monolit s ohraničenými kontexty:
Další informace o použití přístupu DDD pro architektury mikroslužeb najdete v tématu Použití analýzy domény k modelování mikroslužeb.
Použití lepicího kódu (vrstva proti poškození)
Zatímco se tato vyšetřovací práce provádí při inventarizaci monolitické aplikace, je možné přidat nové funkce použitím zásad DDD jako samostatných služeb. Připevnit kód umožňuje monolitické aplikaci proxy volání nové služby, aby získala nové funkce.
Lepicí kód (vzor adaptéru) efektivně funguje jako vrstva proti poškození a zajišťuje, aby nová služba nebyla znečišťována datovými modely vyžadovanými monolitickou aplikací. Kód lepidla pomáhá zprostředkovát interakce mezi těmito dvěma a zajišťuje, že se předávají pouze data vyžadovaná novou službou, aby byla zajištěna kompatibilita.
Prostřednictvím procesu refaktoringu můžou týmy inventarizaci monolitické aplikace a identifikovat kandidáty pro refaktoring mikroslužeb a zároveň vytvořit nové funkce s novými službami.
Další informace o vrstvách proti poškození najdete v tématu Vzor vrstvy proti poškození.
Vytvoření prezentační vrstvy
Dalším krokem je oddělení prezentační vrstvy od back-endové vrstvy. V tradiční n-vrstvé aplikaci je aplikační (obchodní) vrstva obvykle komponentami, které jsou jádrem aplikace a mají v sobě logiku domény. Tato hrubě odstupňovaná rozhraní API interagují s vrstvou přístupu k datům a načítají trvalá data z databáze. Tato rozhraní API vytvářejí přirozenou hranici prezentační vrstvy a pomáhají oddělit prezentační vrstvu do samostatného aplikačního prostoru.
Následující diagram znázorňuje vrstvu prezentace (UI) rozdělenou od aplikační logiky a vrstvy přístupu k datům.
Tento diagram také představuje další vrstvu, bránu rozhraní API, která se nachází mezi prezentační vrstvou a aplikační logikou. Brána rozhraní API je vrstva fasády, která poskytuje konzistentní a jednotné rozhraní pro interakci prezentační vrstvy a zároveň umožňuje nezávislému vývoji podřízených služeb, aniž by to mělo vliv na aplikaci. Brána rozhraní API může používat technologii, jako je Azure API Management, a umožňuje aplikaci interagovat způsobem RESTful.
Prezentační úroveň je možné vyvíjet v libovolném jazyce nebo architektuře, ve které má tým zkušenosti, jako je jednostránková aplikace nebo aplikace MVC. Tyto aplikace interagují s mikroslužbami prostřednictvím brány pomocí standardních volání HTTP. Další informace o branách rozhraní API najdete v tématu Použití bran rozhraní API v mikroslužbách.
Začněte vyřazovat monolit
V této fázi může tým začít odlupovat monolitickou aplikaci a pomalu extrahovat služby, které byly vytvořeny jejich ohraničenými kontexty, do vlastní sady mikroslužeb. Mikroslužby můžou zpřístupnit rozhraní RESTful pro aplikační vrstvu pro interakci s pomocí brány rozhraní API s vloženým kódem pro komunikaci s monolitem za určitých okolností.
Jak budete pokračovat v odlupování monolitu, nakonec přijde bod, kdy už nemusí existovat a mikroslužby byly úspěšně extrahovány z monolitu. V tomto okamžiku je možné vrstvu proti poškození (kód lepidla) bezpečně odebrat.
Tento přístup je příkladem modelu Strangler Fig a umožňuje řízený rozklad monolitu na sadu mikroslužeb. Postupem času, když se stávající funkce přesunou do mikroslužeb, se monolit zmenší co do velikosti a složitosti až do té míry, že už neexistuje.
Přispěvatelé
Tento článek spravuje Microsoft. Původně ji napsali následující přispěvatelé.
Hlavní autor:
- Lavan Nallainathan | Vedoucí architekt cloudových řešení
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
Když se aplikace rozloží na základní mikroslužby, je možné ke správě životního cyklu jednotlivých služeb použít moderní orchestrační nástroje, jako je Azure DevOps . Další informace najdete v tématu CI/CD pro architektury mikroslužeb.