كيف تهاجر من معمارية monolith إلى microservices باستخدام نمط strangler-fig؟

Question

IT Interview Practice · Accepted Answer

نمط **strangler-fig** يهاجر بشكل تدريجي: تقوم بتغليف monolith بطبقة توجيه، واستخراج إمكانية واحدة في كل مرة إلى خدمة، وإعادة توجيه حركة المرور إليها — حتى يتم "خنق" 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
```

## التعامل مع البيانات المشتركة

الجزء الصعب هو قاعدة البيانات. استخرج جداول الخدمة، ثم اكسر الربط المشترك بقاعدة البيانات باستخدام الأحداث أو طبقة anti-corruption، غالباً عبر تقنية **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
```

## لماذا يهم

إعادات الكتابة من نوع big-bang قد تفشل سابقاً — فهي تجمد العمل على الميزات لعدة أشهر وتطلق قطع غيار محفوفة بالمخاطر كل مرة.

نمط strangler-fig يحافظ على النظام حياً وقابلاً للإطلاق طوال الوقت، يتيح لك التوقف أو إعادة الأولويات في أي نقطة، ويجبرك على اكتشاف حدود الخدمة الفعلية من النظام قيد التشغيل بدلاً من تخمينها مقدماً.

كيف تعمل

اختيار ما يتم استخراجه أولاً

التعامل مع البيانات المشتركة

المقايضات

لماذا يهم

أسئلة ذات صلة