Strangler Fig-patroon

Dit patroon migreert incrementeel een verouderd systeem door geleidelijk specifieke onderdelen van functionaliteit te vervangen door nieuwe toepassingen en services. Wanneer u functies van het oude systeem vervangt, omvat het nieuwe systeem uiteindelijk alle functies van het oude systeem. Deze benadering onderdrukt het oude systeem, zodat u het uit bedrijf kunt nemen.

Context en probleem

Naarmate systemen ouder worden, kunnen de ontwikkelhulpprogramma's, hostingtechnologie en systeemarchitecturen waarop ze zijn gebouwd verouderd worden. Naarmate er nieuwe functies en functionaliteit worden toegevoegd, worden deze toepassingen complexer, waardoor ze moeilijker te onderhouden of uit te breiden zijn.

Het vervangen van een heel complex systeem is een enorme onderneming. In plaats daarvan willen veel teams geleidelijk migreren naar een nieuw systeem en het oude systeem behouden om niet-gemigreerde functies te verwerken. Als u echter twee afzonderlijke versies van een toepassing uitvoert, moeten clients bijhouden welke versie afzonderlijke functies heeft. Telkens wanneer teams een functie of service migreren, moeten ze clients naar de nieuwe locatie leiden. Als u deze uitdagingen wilt overwinnen, kunt u een benadering kiezen die ondersteuning biedt voor incrementele migratie en onderbrekingen voor clients minimaliseert.

Oplossing

Gebruik een incrementeel proces om specifieke onderdelen van functionaliteit te vervangen door nieuwe toepassingen en services. Klanten kunnen dezelfde interface blijven gebruiken en zich er niet van bewust zijn dat deze migratie plaatsvindt.

Het Strangler Fig-patroon biedt een gecontroleerde en gefaseerde benadering van modernisering. Hierdoor kan de bestaande toepassing blijven functioneren tijdens de modernisering. Een façade (proxy) onderschept aanvragen die naar het oude back-endsysteem gaan. De façade stuurt deze aanvragen naar de legacy applicatie of naar de nieuwe diensten.

Dit patroon vermindert de risico's in de migratie door uw teams in staat te stellen vooruit te gaan in een tempo dat past bij de complexiteit van het project. Wanneer u functionaliteit naar het nieuwe systeem migreert, wordt het verouderde systeem verouderd en wordt u het verouderde systeem buiten gebruik gesteld.

1. Het Strangler Fig-patroon begint met het introduceren van een gevel (proxy) tussen de client-app, het verouderde systeem en het nieuwe systeem. De gevel fungeert als intermediair. Hiermee kan de client-app communiceren met het verouderde systeem en het nieuwe systeem. In eerste instantie stuurt de gevel de meeste aanvragen naar het verouderde systeem.

2. Naarmate de migratie vordert, verschuift de façade stapsgewijs aanvragen van het oude systeem naar het nieuwe systeem. Met elke iteratie implementeert u meer onderdelen van functionaliteit in het nieuwe systeem.

   Deze incrementele benadering vermindert geleidelijk de verantwoordelijkheden van het oude systeem en breidt het bereik van het nieuwe systeem uit. Het proces is iteratief. Hiermee kan het team complexe aspecten en afhankelijkheden aanpakken in beheerbare fasen. Deze fasen helpen het systeem stabiel en functioneel te blijven.

3. Nadat u alle functionaliteit hebt gemigreerd en er geen afhankelijkheden zijn van het verouderde systeem, kunt u het verouderde systeem buiten gebruik stellen. De gevel stuurt alle aanvragen uitsluitend naar het nieuwe systeem.

4. U verwijdert de gevel en configureert de client-app opnieuw om rechtstreeks met het nieuwe systeem te communiceren. Deze stap markeert de voltooiing van de migratie.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

• Overweeg hoe u services en gegevensarchieven verwerkt die zowel het nieuwe systeem als het verouderde systeem kunnen gebruiken. Zorg ervoor dat beide systemen tegelijkertijd toegang hebben tot deze resources.

• Nieuwe toepassingen en services structureren zodat u deze eenvoudig kunt onderscheppen en vervangen tijdens toekomstige migraties volgens het strangler fig-principe. Probeer bijvoorbeeld duidelijke afbakeningen te hebben tussen delen van uw oplossing, zodat u elk onderdeel afzonderlijk kunt migreren.

• Nadat de migratie is voltooid, verwijdert u meestal de strangler fig façade. U kunt ook de interface behouden als een adapter voor oudere clients om te gebruiken, terwijl u het kernsysteem bijwerkt voor nieuwere clients.

• Zorg ervoor dat de gevel de migratie bijhoudt.

• Zorg ervoor dat de gevel geen single point of failure wordt of een prestatieknelpunt.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• U migreert geleidelijk een back-endtoepassing naar een nieuwe architectuur, met name wanneer u grote systemen, belangrijke onderdelen of complexe functies vervangt, brengt risico's met zich mee.

• Het oorspronkelijke systeem kan gedurende langere tijd blijven bestaan tijdens de migratie.

Dit patroon is mogelijk niet geschikt wanneer:

• Aanvragen voor het back-endsysteem kunnen niet worden onderschept.

• Je migreert een klein systeem, en het vervangen van het hele systeem is eenvoudig.

• U moet de oorspronkelijke oplossing snel uit bedrijf nemen.

Werklastontwerp

Evalueer hoe u het Strangler Fig-patroon gebruikt in workloadontwerp om de doelen en principes van de pijlers van het Azure Well-Architected Framework te adresseren. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Houd rekening met eventuele afwegingen ten opzichte van de doelstellingen van de andere pijlers die dit patroon kan introduceren.

Voorbeeld

Verouderde systemen zijn doorgaans afhankelijk van een gecentraliseerde database. Na verloop van tijd kan een gecentraliseerde database moeilijk te beheren en ontwikkelen vanwege de vele afhankelijkheden. Om deze uitdagingen aan te pakken, kunnen verschillende databasepatronen de overgang van dergelijke verouderde systemen vergemakkelijken. Het Strangler Fig-patroon is een van deze patronen. Pas het Strangler Fig-patroon toe als een gefaseerde benadering om geleidelijk over te stappen van een verouderd systeem naar een nieuw systeem en onderbreking te minimaliseren.

1. U introduceert een nieuw systeem en het nieuwe systeem verwerkt enkele aanvragen van de client-app. Het nieuwe systeem is echter nog steeds afhankelijk van de verouderde database voor alle lees- en schrijfbewerkingen. Het verouderde systeem blijft operationeel, waardoor de overgang soepel verloopt zonder onmiddellijke structurele veranderingen.

2. In de volgende fase introduceert u een nieuwe database. U migreert de gegevensbelastinggeschiedenis naar de nieuwe database met behulp van een ETL-proces (extract, transform and load). Het ETL-proces synchroniseert de nieuwe database met de verouderde database. Tijdens deze fase voert het nieuwe systeem schaduwschrijfbewerkingen uit. Het nieuwe systeem werkt beide databases parallel bij. Het nieuwe systeem blijft lezen uit de verouderde database om consistentie te valideren.

3. Ten slotte wordt de nieuwe database het recordsysteem. De nieuwe database neemt alle lees- en schrijfbewerkingen over. U kunt beginnen met het afschaven van de verouderde database en het verouderde systeem. Nadat u de nieuwe database hebt gevalideerd, kunt u de verouderde database buiten gebruik stellen. Deze buitengebruikstelling voltooit het migratieproces met minimale onderbrekingen.

Volgende stap

Lees het blogbericht van Martin Fowler over Strangler Fig pattern application.

Gerelateerde resource

Berichtbrugpatroon