Wzorzec Dusiciela Figowego

Ten wzorzec stosuje przyrostową migrację starszego systemu, stopniowo zastępując określone elementy funkcjonalności nowymi aplikacjami i usługami. W miarę zastępowania funkcji ze starszego systemu nowy system ostatecznie obejmuje wszystkie funkcje starego systemu. Takie podejście pomija stary system, aby można było go zlikwidować.

Kontekst i problem

W miarę starzenia się systemów narzędzia programistyczne, technologia hostingu i architektury systemowe, na których są tworzone, mogą stać się przestarzałe. W miarę dodawania nowych funkcji i funkcji te aplikacje stają się bardziej złożone, co może utrudnić ich konserwację lub rozszerzanie.

Zastąpienie całego złożonego systemu jest ogromnym przedsięwzięciem. Zamiast tego wiele zespołów woli stopniowo migrować do nowego systemu i zachować stary system do obsługi niezamigyfikowanych funkcji. Jednak uruchomienie dwóch oddzielnych wersji aplikacji wymusza na klientach śledzenie wersji z poszczególnymi funkcjami. Za każdym razem, gdy zespoły migrują funkcję lub usługę, muszą kierować klientów do nowej lokalizacji. Aby przezwyciężyć te wyzwania, można zastosować podejście, które obsługuje migrację przyrostową i minimalizuje zakłócenia dla klientów.

Rozwiązanie

Użyj procesu przyrostowego, aby zastąpić określone elementy funkcjonalności nowymi aplikacjami i usługami. Klienci mogą nadal korzystać z tego samego interfejsu, nie wiedząc, że ta migracja odbywa się.

Wzorzec strangler figowy zapewnia kontrolowane i etapowe podejście do modernizacji. Dzięki niej istniejąca aplikacja będzie nadal działać podczas prac związanych z modernizacją. Fasada przechwytująca (serwer proxy) przechwytuje żądania kierowane do starszego systemu zaplecza. Fasada kieruje te żądania do starszej aplikacji lub do nowych usług.

Ten wzorzec zmniejsza ryzyko migracji, umożliwiając zespołom przechodzenie do przodu w tempie odpowiadającym złożoności projektu. Gdy migrujesz funkcje do nowego systemu, starszy system staje się przestarzały i likwidujesz starszy system.

1. Wzorzec strangler Fig zaczyna się od wprowadzenia fasady (proxy) między aplikacją kliencką, starszym systemem i nowym systemem. Fasada działa jako pośrednik. Umożliwia aplikacji klienckiej interakcję ze starszym systemem i nowym systemem. Początkowo interfejs kieruje większość żądań do starszego systemu.

2. W miarę postępu migracji interfejs stopniowo przenosi żądania z dotychczasowego systemu do docelowego systemu. W przypadku każdej iteracji implementujesz więcej funkcji w nowym systemie.

   Takie podejście przyrostowe stopniowo zmniejsza zakres obowiązków starszego systemu i rozszerza zakres nowego systemu. Proces jest iteracyjny. Umożliwia zespołowi rozwiązywanie problemów ze złożonością i zależnościami w możliwych do zarządzania etapach. Te etapy pomagają systemowi pozostać stabilnym i funkcjonalnym.

3. Po przeprowadzeniu migracji wszystkich funkcji i braku zależności od starszego systemu można zlikwidować starszy system. Fasada kieruje wszystkie żądania wyłącznie do nowego systemu.

4. Należy usunąć fasadę i ponownie skonfigurować aplikację kliencą w celu bezpośredniej komunikacji z nowym systemem. Ten krok oznacza ukończenie migracji.

Problemy i zagadnienia

Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:

• Zastanów się, jak obsługiwać usługi i magazyny danych, których może używać zarówno nowy system, jak i starszy system. Upewnij się, że oba systemy mogą jednocześnie uzyskiwać dostęp do tych zasobów.

• Strukturyzuj nowe aplikacje i usługi tak, aby można je było łatwo przechwycić i zastąpić w przyszłych migracjach typu fig strangler. Na przykład staraj się mieć wyraźne rozdzielenie między częściami rozwiązania, aby można było migrować poszczególne części osobno.

• Po zakończeniu migracji zazwyczaj usuwasz fasadę figowca dusiciela. Alternatywnie można zachować fasadę jako adapter dla starszych klientów do użycia podczas aktualizowania systemu podstawowego dla nowszych klientów.

• Upewnij się, że fasada nadąża za migracją.

• Upewnij się, że fasada nie staje się jedynym punktem podatnym na awarie ani wąskim gardłem dla wydajności.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

• Stopniowo migrujesz aplikację zaplecza do nowej architektury, szczególnie w przypadku zastępowania dużych systemów, kluczowych składników lub złożonych funkcji, co wiąże się z ryzykiem.

• Oryginalny system może nadal istnieć przez dłuższy czas podczas migracji.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

• Nie można przechwycić żądań do systemu back-end.

• Migrowanie małego systemu i zastąpienie całego systemu jest proste.

• Musisz szybko wycofać z użytku oryginalne rozwiązanie.

Projektowanie obciążenia

Oceń, jak używać wzorca figowego stranglera w projekcie obciążenia, aby sprostać celom i zasadom filarów platformy Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące tego, jak ten wzorzec obsługuje cele poszczególnych filarów.

Filar	Jak ten wzorzec obsługuje cele filaru
Decyzje projektowe dotyczące niezawodności pomagają obciążeniu stać się odporne na awarię i zapewnić, że zostanie przywrócony do w pełni funkcjonalnego stanu po wystąpieniu awarii.	Podejście przyrostowe tego wzorca może pomóc w ograniczeniu ryzyka podczas przejścia składnika w porównaniu z wprowadzaniem dużych zmian systemowych jednocześnie. - TESTOWANIE RE:08
Optymalizacja kosztów koncentruje się na utrzymaniu i poprawiezwrotu z inwestycji (ROI).	Celem tego podejścia jest maksymalizacja wykorzystania istniejących inwestycji w aktualnie uruchomiony system podczas modernizacji przyrostowej. Umożliwia wykonywanie wymian o wysokiej wartości ROI przed wymianami o niskiej wartości ROI. - KOSZT SKŁADNIKA CO:07 - CO:08 Koszty środowiska
Doskonałość operacyjna pomaga zapewnić jakość obciążeń dzięki ustandaryzowanym procesom i spójności zespołu.	Ten wzorzec zapewnia podejście do ciągłego ulepszania. Stopniowe zamiany, które z czasem wprowadzają niewielkie zmiany, są preferowane od dużych zmian systemowych, które są bardziej ryzykowne do wdrożenia. - OE:06 Łańcuch dostaw dla rozwoju procesów obciążeniowych - OE:11 Bezpieczne praktyki wdrażania

Rozważ wszelkie kompromisy w kontekście celów innych filarów, które może wprowadzić ten model.

Przykład

Starsze systemy zwykle zależą od scentralizowanej bazy danych. Z czasem scentralizowana baza danych może stać się trudna do zarządzania i rozwoju ze względu na wiele zależności. Aby sprostać tym wyzwaniom, różne wzorce baz danych mogą ułatwić przejście z takich starszych systemów. Wzorzec Fig stranglera jest jednym z tych wzorców. Wdrożenie wzorca Strangler Fig jako podejścia etapowego pozwala na stopniowe przechodzenie z systemu legacy do nowego systemu oraz minimalizowanie zakłóceń.

1. Wprowadzasz nowy system, a nowy system rozpoczyna obsługę niektórych żądań z aplikacji klienckiej. Jednak nowy system nadal zależy od starszej bazy danych dla wszystkich operacji odczytu i zapisu. Starszy system pozostaje operacyjny, co ułatwia bezproblemowe przejście bez natychmiastowych zmian strukturalnych.

2. W następnej fazie wprowadzisz nową bazę danych. Historię ładowania danych można migrować do nowej bazy danych przy użyciu procesu wyodrębniania, przekształcania i ładowania (ETL). Proces ETL synchronizuje nową bazę danych ze starszą bazą danych. W tej fazie nowy system wykonuje operacje zapisu w tle. Nowy system aktualizuje obie bazy danych równolegle. Nowy system nadal odczytuje ze starszej bazy danych, aby zweryfikować spójność.

3. Na koniec nowa baza danych staje się systemem rekordów. Nowa baza danych przejmuje wszystkie operacje odczytu i zapisu. Możesz rozpocząć wycofanie starszej bazy danych i starszego systemu. Po zweryfikowaniu nowej bazy danych możesz wycofać starszą bazę danych. To wycofanie kończy proces migracji z minimalnymi zakłóceniami.

Następny krok

Przeczytaj wpis na blogu Martina Fowlera na temat aplikacji deseń Strangler Fig.

Powiązany zasób

Wzorzec mostka obsługi komunikatów