Stranglerfikonmönster

Migrera ett äldre system stegvis genom att gradvis ersätta specifika funktioner med nya program och tjänster. När du ersätter funktioner från det äldre systemet omfattar det nya systemet så småningom alla det gamla systemets funktioner. Den här metoden undertrycker det gamla systemet så att du kan inaktivera det.

Kontext och problem

När systemen åldras kan de utvecklingsverktyg, värdteknik och systemarkitekturer som de bygger på bli föråldrade. När nya funktioner läggs till blir dessa program mer komplexa, vilket kan göra dem svårare att underhålla eller utöka.

Det är svårt att ersätta ett helt komplext system. I stället kan du migrera till ett nytt system gradvis och använda det gamla systemet för omigrerade funktioner. Men om du kör parallella versioner av ett program måste klienter spåra vilken version som innehåller varje funktion. När du migrerar en funktion eller tjänst måste du dirigera klienter till den nya platsen. För att hantera dessa utmaningar använder du en metod som stöder inkrementell migrering och minimerar störningar för klienter.

Lösning

När du har identifierat nya tjänstgränser använder du en inkrementell process för att ersätta specifika funktioner med nya program och tjänster. Kunderna fortsätter att använda samma gränssnitt och känner inte till att en migrering pågår.

Ladda ned en Visio-fil av den här arkitekturen.

Strangler Fig-mönstret ger en kontrollerad och stegvis metod för modernisering. Det gör att det befintliga programmet kan fortsätta att fungera under moderniseringen. En fasad (proxy) fångar upp begäranden som går till det äldre systemet. Fasaden dirigerar dessa begäranden antingen till det äldre programmet eller till de nya tjänsterna.

Det här mönstret minskar riskerna vid migrering genom att göra det möjligt för dina team att gå framåt i en takt som passar projektets komplexitet. När du migrerar funktioner till det nya systemet blir det äldre systemet föråldrat och du inaktiverar det äldre systemet.

1. Strangler Fig-mönstret börjar med att introducera en fasad (proxy) mellan klientappen, det äldre systemet och det nya systemet. Fasaden fungerar som mellanhand. Det gör att klientappen kan interagera med det äldre systemet och det nya systemet. Inledningsvis dirigerar fasaden de flesta förfrågningarna till det äldre systemet.

2. Allt eftersom migreringen fortskrider, flyttar fasaden succesivt begäranden från det äldre systemet till det nya systemet. Med varje iteration implementerar du fler funktioner i det nya systemet.

   Den här inkrementella metoden minskar gradvis det äldre systemets ansvarsområden och utökar omfånget för det nya systemet. Processen är iterativ. Det gör att teamet kan hantera komplexitet och beroenden i hanterbara steg. Dessa steg hjälper systemet att förbli stabilt och funktionellt.

3. När du har migrerat alla funktioner och det inte finns några beroenden för det äldre systemet kan du inaktivera det äldre systemet. Fasaden dirigerar alla förfrågningar uteslutande till det nya systemet.

4. Du tar bort fasaden och konfigurerar om klientappen för att kommunicera direkt med det nya systemet. Det här steget markerar slutförandet av migreringen.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera det här mönstret:

• Överväg att hantera tjänster och datalager som både det nya systemet och det äldre systemet kan använda. Kontrollera att båda systemen kan komma åt dessa resurser samtidigt.

• Strukturera nya applikationer och tjänster så att du enkelt kan avsätta och byta ut dem i framtida strangler fig-migreringar. Du kan till exempel sträva efter att ha tydliga avgränsningar mellan delar av din lösning så att du kan migrera varje del individuellt.

• När migreringen är klar tar du vanligtvis bort den strypta fikonfasaden. Alternativt kan du behålla fasaden som en adapter för äldre klienter medan du uppdaterar kärnsystemet för nyare klienter.

  Konceptualisera detta som övergångsarkitektur och balansera den här arkitekturens riskreduceringsfördelar mot dess tillfälliga infrastrukturkostnader.

• Se till att fasaden hänger med i migreringen.

• Kontrollera att fasaden inte blir en enda felpunkt eller en flaskhals för prestanda.

• Planera för systemöverskridande beroenden. Under migreringen måste båda systemen samexistera och kommunicera. Det nya systemet kan till exempel behöva anropa omigrerade funktioner från det äldre systemet, och omigrerade äldre komponenter kan behöva anropa migrerade funktioner från det nya systemet. Om du vill hantera dessa anrop använder du mönstret Lager mot korruption. Ett antikorrumperingslager fungerar som en adapter som översätter förfrågningar mellan de två systemen. Det här lagret skyddar det nya systemets design från äldre semantik så att det äldre systemet kan nå nya tjänster utan betydande kodändringar. Utan den här adaptern kan beroenden mellan system bryta komponenter eller tvinga det nya systemet att anta äldre konventioner.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

• Gradvis migreras en bakändsapplikation till en ny arkitektur, särskilt när ersättning av stora system, nyckelkomponenter eller komplexa funktioner innebär en risk.

• Det ursprungliga systemet kan fortsätta att finnas under en längre tid under migreringsarbetet.

Det här mönstret kanske inte är lämpligt när:

• Begäranden till bakändssystemet kan inte fångas upp.

• Du kan inte komma åt det äldre systemets källkod. Om du vill inaktivera migrerade funktioner och omdirigera interna anrop måste du kunna ändra det äldre systemets källkod.

• Du migrerar ett litet system och det är enkelt att ersätta hela systemet.

• Du måste snabbt avveckla den ursprungliga lösningen.

Design av arbetsbelastning

Utvärdera hur du använder Strangler Fig-mönstret i en arbetsbelastnings design för att hantera målen och principerna för Grundpelarna i Azure Well-Architected Framework. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Överväg eventuella kompromisser mot målen för de andra pelarna som det här mönstret kan införa.

Exempel

Äldre system är vanligtvis beroende av en centraliserad monolitisk databas som hanterar flera domäner. Med tiden blir den här delade databasen svår att hantera och förbättra på grund av dess beroenden mellan domäner. För att hantera den här utmaningen extraherar Strangler Fig-mönstret inkrementellt domänspecifika tabeller, lagrade procedurer och relaterade data från den monolitiska databasen till isolerade domändatabaser. Varje databas innehåller bara en domän. Upprepa extraktionsprocessen tills den monolitiska databasen är helt uppdelad.

1. Introducera en ny systemtjänst som börjar hantera begäranden för sin domän. Den nya systemtjänsten läser fortfarande från och skriver till den monolitiska databasen för sina domäntabeller. Det äldre systemet fortsätter att betjäna alla andra domäner.

2. Introducera en isolerad domändatabas för det nya systemet. Migrera relevanta domäntabeller och deras historiska data till den nya databasen med hjälp av en ETL-process (extrahering, transformering och inläsning). En cdc-process (change data capture) synkroniserar domändata från den monolitiska databasen till den nya domändatabasen. Under den här fasen fortsätter det äldre systemet att läsa från och skriva till den monolitiska databasen och det nya systemet skriver till den nya domändatabasen. Verifiera att båda databaserna är konsekventa före driftsättning.

3. Efter validering är den nya domändatabasen det primära systemet för den aktuella domänen. Det nya systemet utför alla läs- och skrivåtgärder mot domändatabasen. Ta bort motsvarande domäntabeller, lagrade procedurer och beroenden från den monolitiska databasen. Upprepa denna process för varje domän tills den monolitiska databasen är helt dekomponerad.

   Du kan återställa till den monolitiska databasen under fas 2 och i början av fas 3, när domäntabellerna och synkroniseringsprocesserna fortfarande finns i den monolitiska databasen. Om du vill återställa till den monolitiska databasen när du har ta bort domäntabellerna, lagrade procedurer och synkroniseringsprocesser från den monolitiska databasen måste du återställa objekten och spela upp dataändringar. Den här processen ökar dock ansträngningen och risken avsevärt. Behandla borttagning av äldre objekt som ett avsiktligt sista steg för varje domän. Ta bara bort äldre objekt när det nya systemet har verifierats.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande bidragsgivare skrev den här artikeln.

Huvudsakliga författare:

• Adnan Khan | Senior Cloud Solutions Architect
• Ovais Mehboob Ahmed Khan | Senior Cloud Solution Architect

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

• Läs Martin Fowlers blogginlägg om Strangler Fig-mönsterprogrammet

Relaterade resurser

• Mönster för meddelandebrygga
• Planera din arbetsbelastningsmigrering från Amazon Web Services till Azure