Strangler Fig vzor

Přírůstkově migrovat starší systém postupným nahrazením konkrétních funkcí novými aplikacemi a službami. Při nahrazení funkcí ze starší verze systému se nový systém nakonec skládá ze všech funkcí starého systému. Tento přístup potlačí starý systém, abyste ho mohli vyřadit z provozu.

Kontext a problém

Jako věk systémů mohou být vývojové nástroje, technologie hostingu a systémové architektury, na kterých jsou postaveny, zastaralé. Při přidání nových funkcí se tyto aplikace stávají složitějšími, což může znesnadnit údržbu nebo rozšíření.

Je obtížné nahradit celý složitý systém. Místo toho můžete migrovat do nového systému postupně a používat starý systém pro nemigrované funkce. Pokud ale spouštíte paralelní verze aplikace, klienti musí sledovat, která verze obsahuje jednotlivé funkce. Při migraci funkce nebo služby musíte klienty směrovat do nového umístění. Pokud chcete tyto problémy vyřešit, přijměte přístup, který podporuje přírůstkovou migraci a minimalizuje přerušení klientů.

Řešení

Po identifikaci nových hranic služeb použijte přírůstkový proces k nahrazení konkrétních částí funkčnosti novými aplikacemi a službami. Zákazníci budou dál používat stejné rozhraní a nebudou vědět, že probíhá migrace.

Čtyři diagramy, které znázorňují čtyři fáze vzoru Strangler Fig. V prvním diagramu fasáda Strangler Fig směruje požadavky klientů mezi starším systémem a novým systémem. Klientská aplikace odesílá požadavky prostřednictvím fasády Strangler Fig, která směruje některé požadavky na starší systém a další požadavky na nový systém. Ve druhém diagramu inkrementální dekompozice přesouvá funkcionalitu ze stávajícího systému do nového systému. Klientská aplikace odesílá požadavky prostřednictvím fasády Strangler Fig, která nyní směruje větší počet požadavků do nového systému než do staršího systému. Ve třetím diagramu je starší verze systému plně vyřazena z provozu a nemá žádné závislosti. Klientská aplikace odesílá požadavky přes fasádu Strangler Fig, která je všechny směruje do nového systému. Ve čtvrtém diagramu je fasáda Strangler Fig odstraněna a klient komunikuje přímo s novým systémem. Klientská aplikace odesílá požadavky přímo do nového systému.

Stáhněte si soubor aplikace Visio s touto architekturou.

Model Strangler Fig poskytuje řízený a fázovaný přístup k modernizaci. Umožňuje stávající aplikaci pokračovat v fungování během modernizace. Fasáda (proxy) zachycuje požadavky, které směřují do back-endového zastaralého systému. Fasáda směruje tyto požadavky buď do starší aplikace, nebo do nových služeb.

Tento model snižuje rizika při migraci tím, že týmům umožní přejít vpřed tempem, které vyhovuje složitosti projektu. Při migraci funkcí do nového systému se starší verze systému stane zastaralým a vyřadíte starší systém z provozu.

1. Model Strangler Fig začíná zavedením fasády (proxy) mezi klientskou aplikací, starším systémem a novým systémem. Fasáda působí jako zprostředkovatel. Umožňuje klientské aplikaci pracovat se starší verzí systému a novým systémem. Na začátku fasáda směruje většinu požadavků na starší systém.

2. Jak migrace postupuje, rozhraní postupně přesouvá požadavky ze staršího systému do nového systému. S každou iterací implementujete v novém systému více funkcí.

   Tento přírůstkový přístup postupně snižuje odpovědnost starší verze systému a rozšiřuje rozsah nového systému. Proces je iterativní. Umožňuje týmu řešit složitost a závislosti ve zvládnutelných fázích. Tyto fáze pomáhají systému zůstat stabilní a funkční.

3. Po migraci všech funkcí a neexistují žádné závislosti na starším systému, můžete starší systém vyřadit z provozu. Fasáda směruje všechny požadavky výhradně do nového systému.

4. Odeberete fasádu a znovu nakonfigurujete klientskou aplikaci tak, aby komunikoval přímo s novým systémem. Tento krok označuje dokončení migrace.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• Zvažte, jak zpracovávat služby a úložiště dat, které může nový systém i starší systém používat. Ujistěte se, že oba systémy mají přístup k těmto prostředkům současně.

• Strukturujte nové aplikace a služby, abyste je mohli snadno zachytit a nahradit v budoucích migracích škrticích fíku. Snažte se například, abyste měli jasné demarace mezi částmi vašeho řešení, abyste mohli jednotlivé části migrovat jednotlivě.

• Po dokončení migrace obvykle odeberete škrtínovou fíkovou fasádu. Alternativně můžete zachovat fasádu jako adaptér pro starší klienty, kteří ho budou používat při aktualizaci základního systému pro novější klienty.

  Představte si tuto architekturu jako přechodnou architekturu a vyvažte výhody zmírnění rizik této architektury oproti dočasným nákladům na infrastrukturu.

• Ujistěte se, že fasáda udržuje krok s migrací.

• Ujistěte se, že se fasáda nestane jediným bodem selhání ani úzkým místem výkonu.

• Plánování závislostí mezi systémy Během migrace musí oba systémy existovat společně a komunikovat. Nový systém může například potřebovat volat nemigrované funkce ze starší verze systému a nemigrované starší komponenty můžou volat migrované funkce z nového systému. Pro správu těchto volání použijte vzor vrstvy proti poškození. Vrstva proti poškození funguje jako adaptér, který překládá požadavky mezi těmito dvěma systémy. Tato vrstva chrání návrh nového systému před starší sémantikou, aby starší systém mohl dosáhnout nových služeb bez významných změn kódu. Bez tohoto adaptéru můžou závislosti mezi systémy narušit komponenty nebo vynutit, aby nový systém přijal starší konvence.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• Back-endovou aplikaci postupně migrujete do nové architektury, zejména při nahrazení velkých systémů, klíčových komponent nebo složitých funkcí představuje riziko.

• Původní systém může během migrace i nadále existovat po delší dobu.

Tento vzor nemusí být vhodný v těchto případech:

• Požadavky na back-endový systém nelze zachytit.

• Nemůžete získat přístup ke zdrojovému kódu starší verze systému. Pokud chcete migrované funkce zakázat a přesměrovat interní volání, musíte být schopni upravit zdrojový kód starší verze systému.

• Migrace malého systému a nahrazení celého systému je jednoduché.

• Původní řešení musíte rychle vyřadit z provozu.

Návrh úloh

Vyhodnoťte, jak použít model Strangler Fig v návrhu úlohy k řešení cílů a principů pilířů architektury Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Přírůstkový přístup tohoto modelu může pomoct zmírnit rizika během přechodu součástí v porovnání s prováděním velkých systémových změn najednou. - RE:08 Testování
Optimalizace nákladů se zaměřuje na udržení a zlepšenínávratnosti investic do vašich úloh.	Cílem tohoto přístupu je maximalizovat využití stávajících investic do aktuálně běžícího systému při postupné modernizaci. Umožňuje provádět výměny s vysokou návratností investice (ROI) před výměnami s nízkou návratností investice (ROI). - CO:07 Náklady na komponenty - CO:08 Náklady na prostředí
Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti.	Tento model poskytuje nepřetržitý přístup ke zlepšování. Přírůstkové nahrazení, které v průběhu času provádějí malé změny, jsou vhodnější než velké systémové změny, které jsou rizikové pro implementaci. - OE:06 Dodavatelský řetězec pro vývoj úloh - Postupy bezpečného nasazení OE:11

Zvažte všechny kompromisy proti cílům ostatních pilířů, které by tento model mohl zavést.

Příklad

Starší systémy obvykle závisejí na centralizované monolitické databázi, která obsluhuje více domén. V průběhu času se tato sdílená databáze obtížně spravuje a vylepšuje kvůli závislostem mezi doménami. Aby bylo možné tento problém vyřešit, model Strangler Fig přírůstkově extrahuje tabulky specifické pro doménu, uložené procedury a související data z monolitické databáze do izolovaných doménových databází. Každá databáze obsahuje pouze jednu doménu. Opakujte proces extrahování, dokud nebude monolitická databáze zcela rozložena.

Tři diagramy znázorňující model Strangler Fig použitý u databáze První diagram znázorňuje novou integraci systému. Klientská aplikace odesílá požadavky do nového systému, ale ne do starší verze systému. Nový systém čte a zapisuje do starší databáze prostřednictvím starších systémových rozhraní API nebo přímého přístupu. Starší databáze je monolitická a obsahuje více datových domén. Druhý diagram znázorňuje integraci nové databáze s kopií dat. Klientská aplikace odesílá požadavky do nového systému, ale ne do starší verze systému. Nový systém čte ze stávající databáze a zapisuje do ní i do nové doménové databáze. Starší verze databáze provádí počáteční načtení do nové databáze domény pomocí procesu extrakce, transformace a načítání (ETL). Starší databáze se synchronizuje s novou doménovou databází pomocí procesu záznamu dat změn (CDC). Nová databáze domény obsahuje extrahované tabulky, procedury a funkce specifické pro doménu (podle vázaného kontextu). Třetí schéma znázorňuje přepnutí doménové databáze. Klientská aplikace odesílá požadavky do nového systému, ale ne do starší verze systému. Nový systém čte a zapisuje do nové databáze domény, ale ne do starší databáze. Odeberou se data a objekty starší databáze. Vedle diagramu tři poznámky vysvětlují, že se odpovědnost směrování přesouvá ze staršího systému do nového systému, že ověřování dat a kontroly konzistence jsou dokončené a že vrácení zpět je možné, dokud nebude starší databáze úplně vyřazena z provozu.

1. Představte si novou systémovou službu, která začne spravovat žádosti o svou doménu. Nová systémová služba stále čte a zapisuje do monolitické databáze pro své doménové tabulky. Starší verze systému nadále obsluhuje všechny ostatní domény.

2. Zavedení izolované databáze domény pro nový systém. Migrujte relevantní tabulky domény a jejich historická data do nové databáze pomocí procesu extrakce, transformace a načítání (ETL). Proces zachytávání dat změn (CDC) synchronizuje data domény z monolitické databáze do nové databáze domény. Během této fáze stávající systém nadále čte z monolitické databáze a zapisuje do ní, zatímco nový systém zapisuje do nové doménové databáze. Před přímou migrací ověřte konzistenci mezi oběma databázemi.

3. Po ověření je nová databáze domény systémem záznamu pro danou doménu. Nový systém provádí všechny operace čtení a zápisu s doménovou databází. Odstraňte z monolitické databáze odpovídající doménové tabulky, uložené procedury a závislosti. Tento postup opakujte pro každou doménu, dokud se monolitická databáze plně rozloží.

   Pokud tabulky domény a synchronizační procesy stále existují v monolitické databázi, můžete se vrátit do monolitické databáze ve fázi 2 a na začátku fáze 3. Chcete-li se vrátit zpět do monolitické databáze po odebrání doménových tabulek, uložených procedur a synchronizačních procesů z monolitické databáze, musíte tyto objekty obnovit a znovu přehrát změny dat. Tento proces ale výrazně zvyšuje úsilí a riziko. Považujte odstranění zastaralých objektů za záměrný závěrečný krok pro každou doménu. Starší objekty odeberte až po ověření nového systému.

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autoři:

• Adnan Khan | Vedoucí architekt cloudových řešení
• Ovais Mehboob Ahmed Khan | Vedoucí architekt cloudových řešení

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se k LinkedIn.

Další krok

• Přečtěte si blogový příspěvek Martina Fowlera o použití vzoru Strangler Fig

Související prostředky

• Model mostu pro zasílání zpráv
• Plánujte migraci úloh z Amazon Web Services na Azure