Poznámka
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento model přírůstkově migruje starší systém postupným nahrazením konkrétních částí 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í.
Nahrazení celého komplexního systému je obrovským závazkem. Mnoho týmů raději migruje do nového systému postupně a udržuje starý systém pro zpracování nemigrovaných funkcí. Spuštění dvou samostatných verzí aplikace však vynutí klienty sledovat, která verze má jednotlivé funkce. Pokaždé, když týmy migrují funkci nebo službu, musí klienty směrovat do nového umístění. Pokud chcete tyto výzvy překonat, můžete přijmout přístup, který podporuje přírůstkovou migraci a minimalizuje přerušení klientů.
Řešení
Pomocí přírůstkového procesu můžete nahradit konkrétní funkce novými aplikacemi a službami. Zákazníci můžou dál používat stejné rozhraní, aniž by si uvědomili, že k této migraci dochází.
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.
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.
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í.
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.
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.
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.
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.
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é databázi. V průběhu času může být centralizovaná databáze obtížně spravovat a vyvíjet kvůli mnoha závislostem. Při řešení těchto problémů mohou různé vzory databáze usnadnit přechod od takových starších systémů. Model Strangler Fig je jedním z těchto vzorů. Použití modelu Strangler Fig jako postupného přístupu k postupnému přechodu ze staršího systému na nový systém a minimalizaci přerušení.
Zavádíte nový systém a nový systém začne zpracovávat některé požadavky z klientské aplikace. Nový systém ale stále závisí na starší databázi pro všechny operace čtení a zápisu. Starší systém zůstává funkční, což usnadňuje hladký přechod bez okamžitých strukturálních změn.
V další fázi zavádíte novou databázi. Historii načítání dat migrujete do nové databáze pomocí procesu extrakce, transformace a načítání (ETL). Proces ETL synchronizuje novou databázi se starší verzí databáze. Během této fáze nový systém provádí stínové zápisy. Nový systém aktualizuje obě databáze paralelně. Nový systém nadále čte ze starší databáze a ověřuje konzistenci.
Nová databáze se nakonec stane systémem záznamu. Nová databáze přebírá všechny operace čtení a zápisu. Můžete začít ukončovat použití zastaralé databáze a systému. Po ověření nové databáze můžete starší databázi vyřadit. Toto ukončení dokončí proces migrace s minimálním přerušením.
Další krok
Přečtěte si blogový příspěvek Martina Fowlera o použití vzoru strangler fig.