Il motivo del fico strangolatore - 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à.

Il motivo del fico strangolatore

Il modello del fico strangolatore è stato introdotto da Martin Fowler per gestire il rischio durante la modernizzazione o la riscrittura di sistemi monolitici di grandi dimensioni. Lo schema è un'analogia per un tipo di pianta che inizia la vita come una vite che cresce accanto a un albero più vecchio e consolidato. Man mano che la vite cresce, si diffonde fino a consumare completamente e alla fine sostituire l'albero ospite, lasciando al suo posto un nuovo fico più strangolante. Nel contesto della modernizzazione dei servizi Web ASP.NET, questo modello sostituisce in modo incrementale la funzionalità del sistema stabilendo proxy in cui altri sistemi dipendono dai servizi Web. Inizialmente, è possibile considerare questi proxy con un comportamento pass-through, poiché la loro implementazione è soddisfatta dal servizio applicativo monolitico esistente. In analogia naturale, questo è il momento in cui il fico strangolatore invia inizialmente una vite sul tronco dell'albero ospite. Quindi, viene creato un nuovo servizio, disaccoppiato dal monolite, e l'implementazione del proxy viene rimandata a quel nuovo servizio. In analogia naturale, questo è il momento in cui il fico strangolatore avvolge uno dei rami dell'albero e lo supera. Questo modello di proxy e quindi sostituzione dell'implementazione del proxy con un nuovo servizio continua fino a quando tutte le funzioni del sistema legacy non vengono migrate su nuovi servizi. A questo punto, il fico strangolatore consuma completamente l'albero e il sistema esistente può essere smantellato.

Segui queste best practice quando usi il pattern strangler fig, in modo da poter scalare e distribuire la tua applicazione in modo indipendente in modo più fluido:

  • Seleziona un componente che abbia una buona copertura dei test e meno debiti tecnici ad esso associati. Iniziare con questo componente può dare ai team molta fiducia durante il processo di modernizzazione.

  • Seleziona i componenti che hanno requisiti di scalabilità e inizia con uno di questi componenti.

  • Seleziona un componente che presenta frequenti modifiche ai requisiti aziendali e implementazioni frequenti.

  • Per implementare questo modello su larga scalaAWS, distribuisci i servizi ASMX refattorizzati in un contenitore Windows in esecuzione in Amazon Elastic Container Service (Amazon ECS) e pubblica la tua API REST modernizzata utilizzando Amazon API Gateway.