Πώς μεταναστεύετε ένα monolith σε microservices χρησιμοποιώντας το σχέδιο strangler-fig;

Question

Accepted Answer

Το σχέδιο **strangler-fig** μεταναστεύει σταδιακά: περιβάλλετε το monolith με ένα επίπεδο δρομολόγησης, εξάγετε μία δυνατότητα τη φορά σε ένα service και ανακατευθύνετε την κίνηση σε αυτό — έως ότου το monolith να "πνιγεί". Δεν υπάρχει **μεγάλη επανεγγραφή σε ένα άλμα**.

## Πώς λειτουργεί

```text
Step 1: route all traffic through a facade/proxy to the monolith
Step 2: extract ONE capability → new service
Step 3: route just that path to the new service
Step 4: repeat; delete that code from the monolith

Client ─▶ [ Proxy ] ─┬─▶ /orders  ─▶ NEW Orders service
                       └─▶ everything else ─▶ Monolith
```

## Επιλογή τι να εξάγετε πρώτα

```text
✓ A bounded context with clear boundaries
✓ Something that needs independent scaling or deploys
✓ A part with few inbound dependencies (low risk)
✗ Don't start with the tangled core
```

## Διαχείριση κοινών δεδομένων

Το δύσκολο μέρος είναι η βάση δεδομένων. Εξάγετε τους πίνακες του service, στη συνέχεια διακόψτε την κοινή σύζευξη DB χρησιμοποιώντας συμβάντα ή ένα anti-corruption layer, συχνά μέσω της τεχνικής **branch-by-abstraction** ενώ και τα δύο τρέχουν.

## Αντιστάθμιση

```text
✓ Low risk — small, reversible steps, always shippable
✓ Value early, learn the seams as you go
✗ Slow; you run a hybrid system for a long time
✗ Temporary duplication and routing complexity
```

## Γιατί έχει σημασία

Οι μεγάλες επανεγγραφές σε ένα άλμα είναι διάσημες που αποτυγχάνουν — παγώνουν τη δουλειά χαρακτηριστικών για μήνες και επιστρέφουν μια επικίνδυνη αλλαγή όλα-ταυτόχρονα.

Το σχέδιο strangler-fig κρατάει το σύστημα ζωντανό και απελευθερώσιμο όλη την ώρα, σας επιτρέπει να σταματήσετε ή να αλλάξετε προτεραιότητες σε οποιοδήποτε σημείο, και σας αναγκάζει να ανακαλύψετε τα πραγματικά όρια υπηρεσιών από το τρέχον σύστημα αντί να τα μαντέψετε εκ των προτέρων.