Modello Fig strangler

Questo modello esegue la migrazione incrementale di un sistema legacy sostituendo gradualmente parti specifiche di funzionalità con nuove applicazioni e servizi. Quando si sostituiscono le funzionalità del sistema legacy, il nuovo sistema alla fine comprende tutte le funzionalità del sistema precedente. Questo approccio elimina il vecchio sistema in modo da poterlo rimuovere.

Contesto e problema

Con l'età dei sistemi, gli strumenti di sviluppo, la tecnologia di hosting e le architetture di sistema su cui sono basate possono diventare obsoleti. Man mano che vengono aggiunte nuove funzionalità, queste applicazioni diventano più complesse, che possono renderle più difficili da gestire o estendere.

È difficile sostituire un intero sistema complesso. È invece possibile eseguire la migrazione a un nuovo sistema gradualmente e usare il vecchio sistema per le funzionalità non supportate. Tuttavia, se si eseguono versioni parallele di un'applicazione, i client devono tenere traccia della versione che contiene ogni funzionalità. Quando si esegue la migrazione di una funzionalità o di un servizio, è necessario indirizzare i client alla nuova posizione. Per risolvere questi problemi, adottare un approccio che supporta la migrazione incrementale e riduce al minimo le interruzioni ai client.

Soluzione

Dopo aver identificato i nuovi limiti del servizio, usare un processo incrementale per sostituire parti specifiche di funzionalità con nuove applicazioni e servizi. I clienti continuano a usare la stessa interfaccia e non sanno che è in corso una migrazione.

Diagrammi che mostrano il modello Strangler Fig.

Scaricare un file di Visio di questa architettura.

Il modello Strangler Fig fornisce un approccio controllato e graduale alla modernizzazione. Consente all'applicazione esistente di continuare a funzionare durante lo sforzo di modernizzazione. Una facciata (proxy) intercetta le richieste che passano al sistema legacy back-end. La facciata indirizza queste richieste all'applicazione legacy o ai nuovi servizi.

Questo modello riduce i rischi nella migrazione consentendo ai team di procedere a un ritmo adatto alla complessità del progetto. Quando si esegue la migrazione delle funzionalità al nuovo sistema, il sistema legacy diventa obsoleto e si ritira il sistema legacy.

  1. Il modello Strangler Fig inizia introducendo una facciata (proxy) tra l'app client, il sistema legacy e il nuovo sistema. La facciata funge da intermediario. Consente all'app client di interagire con il sistema legacy e il nuovo sistema. Inizialmente, la facciata instrada la maggior parte delle richieste al sistema legacy.

  2. Man mano che la migrazione procede, la facciata sposta in modo incrementale le richieste dal sistema legacy al nuovo sistema. Con ogni iterazione, si implementano più funzionalità nel nuovo sistema.

    Questo approccio incrementale riduce gradualmente le responsabilità del sistema legacy ed espande l'ambito del nuovo sistema. Il processo è iterativo. Consente al team di affrontare complessità e dipendenze in fasi gestibili. Queste fasi aiutano il sistema a rimanere stabili e funzionali.

  3. Dopo aver eseguito la migrazione di tutte le funzionalità e non esistono dipendenze dal sistema legacy, è possibile rimuovere le autorizzazioni del sistema legacy. La facciata instrada tutte le richieste esclusivamente al nuovo sistema.

  4. Rimuovere la facciata e riconfigurare l'app client per comunicare direttamente con il nuovo sistema. Questo passaggio contrassegna il completamento della migrazione.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

  • Si consideri come gestire i servizi e gli archivi dati che possono essere usati sia dal nuovo sistema che dal sistema legacy. Assicurarsi che entrambi i sistemi possano accedere contemporaneamente a queste risorse.

  • Strutturare nuove applicazioni e servizi in modo che sia possibile intercettarli e sostituirli in future migrazioni fig. Ad esempio, cercare di avere delimitazioni chiare tra parti della soluzione in modo da poter eseguire la migrazione di ogni parte singolarmente.

  • Al termine della migrazione, in genere si rimuove il rivestimento di fico strangolatore. In alternativa, è possibile mantenere la facciata come adattatore per i client legacy da usare durante l'aggiornamento del sistema principale per i client più recenti.

    Concettualizzare questo concetto come architettura transitoria e bilanciare i vantaggi della mitigazione dei rischi di questa architettura rispetto ai costi temporaneo dell'infrastruttura.

  • Assicurarsi che la facciata continui con la migrazione.

  • Assicurarsi che la facciata non diventi un singolo punto di guasto o un collo di bottiglia delle prestazioni.

  • Pianificare le dipendenze tra sistemi. Durante la migrazione, entrambi i sistemi devono coesistere e comunicare. Ad esempio, il nuovo sistema potrebbe dover richiamare funzionalità non migrate dal sistema legacy e i componenti legacy non migrati potrebbero dover richiamare la funzionalità migrata dal nuovo sistema. Per gestire queste chiamate, usare il modello Livello anti-danneggiamento. Un livello anti-danneggiamento funge da adattatore che converte le richieste tra i due sistemi. Questo livello protegge la progettazione del nuovo sistema dalla semantica legacy in modo che il sistema legacy possa raggiungere nuovi servizi senza modifiche significative al codice. Senza questo adattatore, le dipendenze tra sistemi possono compromettere i componenti o costringere il nuovo sistema ad adottare convenzioni legacy.

Quando usare questo modello

Usare questo modello quando:

  • Si esegue gradualmente la migrazione di un'applicazione back-end a una nuova architettura, soprattutto quando si sostituiscono sistemi di grandi dimensioni, componenti chiave o funzionalità complesse comportano rischi.

  • Il sistema originale può continuare a esistere per un lungo periodo di tempo durante il lavoro di migrazione.

Questo modello potrebbe non essere adatto quando:

  • Le richieste al sistema back-end non possono essere intercettate.

  • Non è possibile accedere al codice sorgente del sistema legacy. Per disabilitare le funzionalità migrate e reindirizzare le chiamate interne, è necessario essere in grado di modificare il codice sorgente del sistema legacy.

  • È possibile eseguire la migrazione di un piccolo sistema e sostituire l'intero sistema è semplice.

  • È necessario rimuovere completamente la soluzione originale rapidamente.

Progettazione del carico di lavoro

Valutare come usare il modello Strangler Fig nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi dei pilastri di Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.

Pilastro Come questo modello supporta gli obiettivi di pilastro
Le decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resilienti a malfunzionamenti e di assicurarsi che venga ripristinato in uno stato completamente funzionante dopo che si verifica un errore. Questo approccio incrementale di questo modello può contribuire a ridurre i rischi durante una transizione dei componenti rispetto all'esecuzione di modifiche sistemiche di grandi dimensioni contemporaneamente.

- RE:08 Test
L'ottimizzazione dei costi è incentrata sul mantenimento e sul miglioramento del ritorno del carico di lavoro sugli investimenti (ROI). L'obiettivo di questo approccio è ottimizzare l'uso degli investimenti esistenti nel sistema attualmente in esecuzione durante la modernizzazione incrementale. Consente di eseguire sostituzioni con ROI alto prima delle sostituzioni a basso ROI.

- Costi dei componenti CO:07
- Costi dell'ambiente CO:08
L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. Questo modello offre un approccio di miglioramento continuo. Le sostituzioni incrementali che apportano piccole modifiche nel tempo sono preferibili a modifiche sistemiche di grandi dimensioni che sono più rischiose da implementare.

- OE:06 Catena di fornitura per lo sviluppo di carichi di lavoro
- OE:11 Pratiche di distribuzione sicura

Prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che questo modello potrebbe introdurre.

Esempio

I sistemi legacy dipendono in genere da un database monolitico centralizzato che gestisce più domini. Nel corso del tempo, questo database condiviso diventa difficile da gestire e migliorare a causa delle relative dipendenze tra domini. Per risolvere questa sfida, il modello Strangler Fig estrae in modo incrementale tabelle, stored procedure e dati correlati specifici del dominio dal database monolitico in database di dominio isolati. Ogni database contiene un solo dominio. Ripetere il processo di estrazione fino a quando il database monolitico non viene completamente scomposto.

Diagrammi che mostrano il modello Strangler Fig applicato a un database.

  1. Introdurre un nuovo servizio di sistema, che inizia a gestire le richieste per il dominio. Il nuovo servizio di sistema continua a leggere e scrivere nel database monolitico per le proprie tabelle di dominio. Il sistema legacy continua a servire tutti gli altri domini.

  2. Introdurre un database di dominio isolato per il nuovo sistema. Eseguire la migrazione delle tabelle di dominio pertinenti e dei relativi dati cronologici al nuovo database usando un processo di estrazione, trasformazione e caricamento (ETL). Un processo di Change Data Capture (CDC) sincronizza i dati di dominio dal database monolitico al nuovo database di dominio. Durante questa fase, il sistema legacy continua a leggere e scrivere nel database monolitico e il nuovo sistema scrive nel nuovo database di dominio. Convalidare la coerenza tra entrambi i database prima del cutover.

  3. Dopo la convalida, il nuovo database di dominio è il sistema di record per tale dominio. Il nuovo sistema esegue tutte le operazioni di lettura e scrittura sul database di dominio. Rimuovere le tabelle di dominio, le stored procedure e le dipendenze corrispondenti dal database monolitico. Ripetere questo processo per ogni dominio fino a quando il database monolitico non viene completamente scomposto.

    È possibile eseguire il rollback al database monolitico durante la fase 2 e all'inizio della fase 3, quando le tabelle di dominio e i processi di sincronizzazione sono ancora presenti nel database monolitico. Per eseguire il rollback al database monolitico dopo aver rimosso le tabelle di dominio, le stored procedure e i processi di sincronizzazione dal database monolitico, è necessario ripristinare tali oggetti e riprodurre le modifiche dei dati. Tuttavia, questo processo aumenta significativamente lo sforzo e il rischio. Considerare la rimozione di oggetti legacy come passaggio finale intenzionale per ogni dominio. Rimuovere gli oggetti legacy solo dopo la convalida del nuovo sistema.

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggio successivo

  • Last updated on