Modello di fichi strangolatori - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Modello di fichi strangolatori

I modelli di progettazione discussi finora in questa guida si applicano alle applicazioni di decomposizione per progetti greenfield. Che dire dei progetti dismessi che coinvolgono grandi applicazioni monolitiche? Applicare i modelli di progettazione precedenti su di essi sarà difficile, perché suddividerli in pezzi più piccoli mentre vengono utilizzati attivamente è un compito arduo.

Il motivo del fico strangolatore è un popolare motivo di design introdotto da Martin Fowler, che si è ispirato a un certo tipo di fico che si semina nei rami superiori degli alberi. L'albero esistente diventa inizialmente una struttura di supporto per la nuova fig. Il fico poi affonda le sue radici a terra, avvolgendo gradualmente l'albero originario e lasciando al suo posto solo il nuovo fico autoportante.

Questo modello viene comunemente utilizzato per trasformare in modo incrementale un'applicazione monolitica in microservizi sostituendo una particolare funzionalità con un nuovo servizio. L'obiettivo è far coesistere le versioni precedenti e quelle nuove e modernizzate. Il nuovo sistema è inizialmente supportato dal sistema esistente e lo integra. Questo supporto dà al nuovo sistema il tempo di crescere e potenzialmente di sostituire completamente il vecchio sistema.

Il processo di transizione da un'applicazione monolitica ai microservizi implementando il pattern strangler fig consiste in tre fasi: trasformazione, coesistenza ed eliminazione:

  • Trasformazione: identifica e crea componenti modernizzati trasferendoli o riscrivendo parallel all'applicazione esistente.

  • Coesistete: conservate l'applicazione Monolith per il rollback. Intercetta le chiamate di sistema esterne incorporando un proxy HTTP (ad esempio Amazon API Gateway) nel perimetro del tuo monolite e reindirizza il traffico verso la versione modernizzata. Questo ti aiuta a implementare le funzionalità in modo incrementale.

  • Elimina: rimuove la vecchia funzionalità dal monolite man mano che il traffico viene reindirizzato dal monolite precedente al servizio modernizzato.

AWS Migration Hub Refactor Spacesè il punto di partenza per il refactoring incrementale delle applicazioni in microservizi attiviAWS. Refactor Spaces fornisce un'applicazione che modella il pattern strangler fig per il refactoring incrementale. Un'applicazione Refactor Spaces orchestra API Gateway, Network Load Balancer e policy basate sulle risorseAWS Identity and Access Management (IAM) in modo da poter aggiungere in modo trasparente nuovi servizi a un endpoint HTTP esterno.

La tabella seguente spiega i vantaggi e gli svantaggi dell'utilizzo del modello di fichi strangolatori.

Vantaggi Svantaggi

  • Consente una migrazione agevole da un servizio a uno o più servizi sostitutivi.

  • Mantiene attivi i vecchi servizi effettuando il refactoring alle versioni aggiornate.

  • Offre la possibilità di aggiungere nuovi servizi e funzionalità ristrutturando al contempo i servizi più vecchi.

  • Il pattern può essere utilizzato per il controllo delle versioni delle API.

  • Il modello può essere utilizzato per le interazioni esistenti per soluzioni che non sono o non verranno aggiornate.

  • Non è adatto per sistemi di piccole dimensioni in cui la complessità è bassa e le dimensioni sono ridotte.

  • Non può essere utilizzato in sistemi in cui le richieste al sistema backend non possono essere intercettate e indirizzate.

  • Il livello proxy o di facciata può diventare un singolo punto di errore o un ostacolo alle prestazioni se non è progettato correttamente.

  • Richiede un piano di rollback per ogni servizio rifattorizzato per ripristinare il vecchio modo di fare le cose in modo rapido e sicuro se le cose vanno male.

La figura seguente mostra come un monolite può essere suddiviso in microservizi applicando il pattern strangler fig all'architettura di un'applicazione. Entrambi i sistemi funzionano in parallel, ma inizierai a spostare le funzionalità al di fuori della base di codice monolitica e a migliorarle con nuove funzionalità. Queste nuove funzionalità ti offrono l'opportunità di progettare i microservizi nel modo più adatto alle tue esigenze. Continuerai a eliminare le funzionalità dal monolite fino a quando non sarà tutto sostituito dai microservizi. A questo punto, è possibile eliminare l'applicazione monolite. Il punto chiave da notare qui è che sia il monolite che i microservizi vivranno insieme per un periodo di tempo.

Scomposizione dei monoliti in microservizi utilizzando il modello strangler fig