როგორ მიგრირება მონოლიტი მიკროსერვისებზე strangler-fig ნიმუშის გამოყენებით?

Question

Accepted Answer

**Strangler-fig ნიმუში** მიგრირება ეტაპობრივად: თქვენ ახვევთ მონოლიტს მარშრუტირების ფენით, ამოიღეთ ერთი შესაძლებლობა ერთდროულად სერვისში, და გადამისამართეთ ტრაფიკი მასთან — სანამ მონოლიტი "გამჭიანი" უჯდებათ. **დიდი მასშტაბის გადაწერა არ არსებობს**.

## როგორ მუშაობს

```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
```

## საზიარი მონაცემების მართვა

დიდი პრობლემა არის მონაცემთა ბაზა. ამოიღეთ სერვის ცხრილები, შემდეგ გაწყვიტეთ საზიარი DB გაერთიანება ღონისძიებების ან ანტი-კორუფციის ფენის გამოყენებით, ხშირად **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 ფიგი ინარჩუნებს სისტემას ცოცხალ და გამოსაშვებ მდგომარეობაში მთელ დროს, აძლევთ გაჩერებას ან გადააპრიორიტიზებას ნებისმიერ დროს, და აკეთებთ თქვენ აღმოაჩინოს რეალური სერვის საზღვრები ფუნქციონირებული სისტემიდან და არა ჩათვალებული მათი.