Anmerkung
Der Zugriff auf diese Seite erfordert eine Genehmigung. Du kannst versuchen, dich anzumelden oder die Verzeichnisse zu wechseln.
Der Zugriff auf diese Seite erfordert eine Genehmigung. Du kannst versuchen , die Verzeichnisse zu wechseln.
Dieses Muster migriert schrittweise ein Altsystem, indem spezifische Funktionalitäten durch neue Anwendungen und Dienste ersetzt werden. 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.
Das Ersetzen eines gesamten komplexen Systems ist ein großes Unternehmen. Stattdessen bevorzugen viele Teams die Schrittweise Migration zu einem neuen System und halten das alte System, um nicht migrierte Features zu verarbeiten. Das Ausführen von zwei separaten Versionen einer Anwendung zwingt Clients jedoch, nachzuverfolgen, welche Version über einzelne Features verfügt. Jedes Mal, wenn Teams ein Feature oder einen Dienst migrieren, müssen sie Clients an den neuen Speicherort weiterleiten. Um diese Herausforderungen zu überwinden, können Sie einen Ansatz einführen, der die inkrementelle Migration unterstützt und Unterbrechungen für Clients minimiert.
Lösung
Verwenden Sie einen inkrementellen Prozess, um bestimmte Funktionen durch neue Anwendungen und Dienste zu ersetzen. Kunden können weiterhin dieselbe Schnittstelle verwenden, und nicht wissen, dass diese Migration stattfindet.
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.
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.
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.
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.
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.
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.
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 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.
| Säule | So unterstützt dieses Muster die Säulenziele |
|---|---|
| Zuverlässigkeitsdesignentscheidungen tragen dazu bei, dass Ihre Workload ausfallsicher wird und dass sie nach einem Ausfall wieder in einen voll funktionsfähigen Zustand zurückkehrt. | Der inkrementelle Ansatz dieses Musters kann dazu beitragen, Risiken während eines Komponentenübergangs zu minimieren, verglichen mit großen systemischen Änderungen auf einmal. - RE:08 Prüfung |
| Die Kostenoptimierung konzentriert sich auf die Erhaltung und Verbesserung der Rendite des Workloads (ROI). | Ziel dieses Ansatzes ist es, die Nutzung bestehender Investitionen im derzeit ausgeführten System zu maximieren und gleichzeitig inkrementell zu modernisieren. Es ermöglicht Ihnen, hohe ROI-Ersetzungen vor Ersetzungen mit geringem ROI durchzuführen. - CO:07 Komponentenkosten - CO:08 Umweltkosten |
| Operational Excellence hilft, Arbeitsauslastungsqualität durch standardisierte Prozesse und Teamzusammenhalt zu liefern. | Dieses Muster bietet einen kontinuierlichen Verbesserungsansatz. Inkrementelle Ersetzungen, die im Laufe der Zeit kleine Änderungen vornehmen, sind großen systemischen Änderungen vorzuziehen, die riskanter zu implementieren sind. - OE:06 Lieferkette für die Arbeitslastentwicklung - OE:11 Sichere Bereitstellungsmethoden |
Berücksichtigen Sie alle Kompromisse gegen die Ziele der anderen Säulen, die dieses Muster einführen könnte.
Beispiel
Ältere Systeme sind in der Regel von einer zentralisierten Datenbank abhängig. Im Laufe der Zeit kann eine zentralisierte Datenbank aufgrund ihrer vielen Abhängigkeiten schwierig zu verwalten und weiterentwickelt werden. Um diese Herausforderungen zu bewältigen, können verschiedene Datenbankmuster den Übergang von solchen Legacysystemen erleichtern. Das Strangler Fig-Muster ist eines dieser Muster. Wenden Sie das Strangler Fig-Muster als phasenweisen Ansatz an, um schrittweise von einem älteren System zu einem neuen System zu wechseln und Unterbrechungen zu minimieren.
Sie führen ein neues System ein, und das neue System beginnt mit der Behandlung einiger Anforderungen von der Client-App. Das neue System hängt jedoch weiterhin von der Legacydatenbank für alle Lese- und Schreibvorgänge ab. Das alte System bleibt betriebsbereit, was einen reibungslosen Übergang ohne sofortige Strukturelle Veränderungen ermöglicht.
In der nächsten Phase führen Sie eine neue Datenbank ein. Sie migrieren den Datenladeverlauf mithilfe eines Extrakt-, Transformations- und Ladeprozesses (ETL) in die neue Datenbank. Der ETL-Prozess synchronisiert die neue Datenbank mit der Legacydatenbank. Während dieser Phase führt das neue System Schattenschreibvorgänge durch. Das neue System aktualisiert beide Datenbanken parallel. Das neue System liest weiterhin aus der Legacydatenbank, um die Konsistenz zu überprüfen.
Schließlich wird die neue Datenbank zum Referenzsystem. Die neue Datenbank übernimmt alle Lese- und Schreibvorgänge. Sie können mit der Stilllegung der Altdatenbank und des Altsystems beginnen. Nachdem Sie die neue Datenbank überprüft haben, können Sie die Legacydatenbank zurückziehen. Diese Einstellung schließt den Migrationsprozess mit minimalen Unterbrechungen ab.
Nächster Schritt
Lesen Sie Martin Fowlers Blogbeitrag über die Anwendung des Strangler-Musters.