Strangler-Muster

Migrieren Sie inkrementell ein Legacysystem, indem Sie bestimmte Funktionen schrittweise durch neue Anwendungen und Dienste ersetzen. Wenn Sie Features aus dem älteren System ersetzen, umfasst das neue System schließlich alle Features des alten Systems. Dieser Ansatz unterdrückt das alte System, damit Sie es außer Betrieb setzen können.

Kontext und Problem

Da Systeme altern, können die Entwicklungstools, Hostingtechnologie und Systemarchitekturen, auf denen sie basieren, veraltet werden. Da neue Features und Funktionen hinzugefügt werden, werden diese Anwendungen komplexer, wodurch sie schwieriger zu warten oder zu erweitern sind.

Es ist schwierig, ein gesamtes komplexes System zu ersetzen. Stattdessen können Sie schrittweise zu einem neuen System migrieren und das alte System für nicht migrierte Features verwenden. Wenn Sie jedoch parallele Versionen einer Anwendung ausführen, müssen Clients nachverfolgen, welche Version die einzelnen Features enthält. Wenn Sie ein Feature oder einen Dienst migrieren, müssen Sie Clients an den neuen Speicherort weiterleiten. Um diese Herausforderungen zu bewältigen, setzen Sie einen Ansatz ein, der die inkrementelle Migration unterstützt und Unterbrechungen für Clients minimiert.

Lösung

Nachdem Sie neue Dienstgrenzen identifiziert haben, verwenden Sie einen inkrementellen Prozess, um bestimmte Funktionen durch neue Anwendungen und Dienste zu ersetzen. Kunden verwenden weiterhin dieselbe Schnittstelle und wissen nicht, dass eine Migration ausgeführt wird.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Das Strangler Fig-Muster bietet einen kontrollierten und phasenweisen Ansatz für die Modernisierung. Sie ermöglicht es der vorhandenen Anwendung, während des Modernisierungsaufwands weiter zu funktionieren. Eine Fassade (Proxy) fängt Anforderungen ab, die zum Back-End-Legacysystem gehen. Die Fassade leitet diese Anforderungen entweder an die Legacyanwendung oder an die neuen Dienste weiter.

Dieses Muster reduziert Risiken bei der Migration, indem Es Ihren Teams ermöglicht, in einem Tempo voranzukommen, das der Komplexität des Projekts entspricht. Während Sie die Funktionalität zum neuen System migrieren, wird das Legacysystem veraltet, und Sie setzen das Legacysystem außer Betrieb.

1. Das Strangler Fig-Muster beginnt mit der Einführung einer Fassade (Proxy) zwischen der Client-App, dem älteren System und dem neuen System. Die Fassade fungiert als Vermittler. Die Client-App kann mit dem älteren System und dem neuen System interagieren. Zunächst leitet die Fassade die meisten Anforderungen an das Legacysystem weiter.

2. Im Verlauf der Migration verschiebt die Fassade Anforderungen vom älteren System inkrementell in das neue System. Mit jeder Iteration implementieren Sie weitere Funktionen im neuen System.

   Dieser inkrementelle Ansatz reduziert die Zuständigkeiten des Legacysystems schrittweise und erweitert den Umfang des neuen Systems. Der Prozess ist iterativ. Es ermöglicht dem Team, Komplexitäten und Abhängigkeiten in verwaltbaren Phasen zu adressieren. Diese Stufen helfen, das System stabil und funktionsfähig zu bleiben.

3. Nachdem Sie alle Funktionen migriert haben und keine Abhängigkeiten vom älteren System bestehen, können Sie das Legacysystem außer Betrieb setzen. Die Fassade leitet alle Anforderungen ausschließlich an das neue System weiter.

4. Sie entfernen die Fassade und konfigurieren die Client-App so, dass sie direkt mit dem neuen System kommuniziert. In diesem Schritt wird der Abschluss der Migration markiert.

Probleme und Überlegungen

Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:

• Überlegen Sie, wie Dienste und Datenspeicher behandelt werden, die sowohl das neue System als auch das legacy-System verwenden können. Stellen Sie sicher, dass beide Systeme gleichzeitig auf diese Ressourcen zugreifen können.

• Strukturieren Sie neue Anwendungen und Dienste, damit Sie sie in zukünftigen Strangler-Migrationen problemlos abfangen und ersetzen können. Versuchen Sie beispielsweise, klare Abgrenzungen zwischen Teilen Ihrer Lösung zu haben, damit Sie die einzelnen Teile einzeln migrieren können.

• Nach Abschluss der Migration entfernen Sie in der Regel die Strangler-Fassade. Alternativ können Sie die Fassade als Adapter für ältere Clients verwalten, während Sie das Kernsystem für neuere Clients aktualisieren.

  Konzeptualisieren Sie dies als Übergangsarchitektur, und ausgleichen Sie die Risikominderungsvorteile dieser Architektur mit ihren temporären Infrastrukturkosten.

• Stellen Sie sicher, dass die Fassade mit der Migration Schritt hält.

• Stellen Sie sicher, dass die Fassade nicht zu einem einzigen Fehlerpunkt oder zu einem Leistungsengpässe wird.

• Planen Sie für systemübergreifende Abhängigkeiten. Während der Migration müssen beide Systeme koexistieren und kommunizieren. Beispielsweise muss das neue System möglicherweise nicht migrierte Funktionen aus dem älteren System aufrufen, und nicht migrierte Legacykomponenten müssen möglicherweise migrierte Funktionen aus dem neuen System aufrufen. Um diese Aufrufe zu verwalten, verwenden Sie das Muster „Antikorruptionsschicht“. Eine Antibeschädigungsschicht fungiert als Adapter, der Anforderungen zwischen den beiden Systemen übersetzt. Diese Ebene schützt den Entwurf des neuen Systems vor älteren Semantiken, sodass das Legacysystem neue Dienste ohne erhebliche Codeänderungen erreichen kann. Ohne diesen Adapter können systemübergreifende Abhängigkeiten Komponenten unterbrechen oder das neue System zwingen, Legacykonventionen zu übernehmen.

Wann dieses Muster verwendet werden soll

Verwenden Sie dieses Muster in folgenden Fällen:

• Sie migrieren schrittweise eine Back-End-Anwendung auf eine neue Architektur, was insbesondere beim Ersetzen von großen Systemen, wichtigen Komponenten oder komplexen Features zu Risiken führen kann.

• Das ursprüngliche System kann während des Migrationsaufwands für einen längeren Zeitraum weiterhin vorhanden sein.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Anfragen an das Back-End-System können nicht abgefangen werden.

• Sie können nicht auf den Quellcode des Legacysystems zugreifen. Um migrierte Features zu deaktivieren und interne Aufrufe umzuleiten, müssen Sie in der Lage sein, den Quellcode des älteren Systems zu ändern.

• Sie migrieren ein kleines System und ersetzen das gesamte System einfach.

• Sie müssen die ursprüngliche Lösung schnell vollständig außer Betrieb setzen.

Workloadentwurf

Bewerten Sie, wie Sie das Strangler Fig-Pattern bei der Gestaltung einer Workload anwenden, um den Anforderungen und Prinzipien der Azure Well-Architected Framework-Säulen gerecht zu werden. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Berücksichtigen Sie alle Kompromisse gegen die Ziele der anderen Säulen, die dieses Muster einführen könnte.

Beispiel

Legacysysteme sind in der Regel von einer zentralen monolithischen Datenbank abhängig, die mehreren Domänen dient. Im Laufe der Zeit wird diese freigegebene Datenbank aufgrund ihrer domänenübergreifenden Abhängigkeiten schwierig zu verwalten und zu verbessern. Um diese Herausforderung zu bewältigen, extrahiert das Strangler Fig-Muster inkrementell domänenspezifische Tabellen, gespeicherte Prozeduren und zugehörige Daten aus der monolithischen Datenbank in isolierte Domänendatenbanken. Jede Datenbank enthält nur eine Domäne. Wiederholen Sie den Extraktionsprozess, bis die monolithische Datenbank vollständig dekompiliert ist.

1. Stellen Sie einen neuen Systemdienst vor, der mit der Verwaltung von Anforderungen für seine Domäne beginnt. Der neue Systemdienst greift für die Tabellen seiner Domäne weiterhin lesend und schreibend auf die monolithische Datenbank zu. Das Legacysystem bedient weiterhin alle anderen Domänen.

2. Stellen Sie eine isolierte Domänendatenbank für das neue System vor. Migrieren Sie die relevanten Domänentabellen und deren verlaufsgeschichtliche Daten mithilfe eines Extrakt-, Transformations- und Ladeprozesses (ETL) in die neue Datenbank. Bei einem Änderungsdatenerfassungsprozess (Change Data Capture, CDC) werden die Domänendaten aus der monolithischen Datenbank mit der neuen Domänendatenbank synchronisiert. In dieser Phase liest das Legacysystem weiterhin aus und schreibt in die monolithische Datenbank, und das neue System schreibt in die neue Domänendatenbank. Überprüfen Sie die Konsistenz zwischen beiden Datenbanken vor der Übernahme.

3. Nach der Überprüfung ist die neue Domänendatenbank das System des Eintrags für diese Domäne. Das neue System führt alle Lese- und Schreibvorgänge für die Domänendatenbank aus. Entfernen Sie die entsprechenden Domänentabellen, gespeicherten Prozeduren und Abhängigkeiten aus der monolithischen Datenbank. Wiederholen Sie diesen Vorgang für jede Domäne, bis die monolithische Datenbank vollständig dekompiliert ist.

   Sie können in Phase 2 und zu Beginn der Phase 3 einen Rollback zur monolithischen Datenbank durchführen, wenn die Domänentabellen und Synchronisierungsprozesse noch in der monolithischen Datenbank vorhanden sind. Um ein Rollback auf die monolithische Datenbank durchzuführen, nachdem Sie die Domänentabellen, gespeicherten Prozeduren und Synchronisierungsprozesse aus der monolithischen Datenbank entfernt haben, müssen Sie diese Objekte wiederherstellen und Datenänderungen wiedergeben. Dieser Prozess erhöht jedoch den Aufwand und das Risiko erheblich. Behandeln Sie das Entfernen von Legacyobjekten als absichtlichen letzten Schritt für jede Domäne. Entfernen Sie Legacyobjekte erst, nachdem das neue System überprüft wurde.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

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

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächster Schritt

• Lesen Sie Martin Fowlers Blogbeitrag über Strangler Fig Pattern Application

Verwandte Ressourcen

• Messaging Bridge-Muster
• Planen Sie Ihre Workloadmigration von Amazon Web Services zu Azure