Strangler Fig
نمط Strangler Fig — الترحيل التدريجي Strangler Fig
يهاجر من Monolith إلى مايكروسيرفيس تدريجياً عبر واجهة (Façade) توجّه كل طلب إما للنظام القديم أو لخدمة جديدة، بدل إعادة كتابة كاملة دفعة واحدة.
إعادة كتابة نظام قديم بالكامل دفعة واحدة (Big Bang Rewrite) مخاطرة عالية تفشل غالباً في المشاريع الكبيرة. Strangler Fig (نسبة لنبتة التين الخانق التي تنمو حول شجرة وتحل محلها تدريجياً) يضع Façade أمام النظام القديم، ثم ينقل الوظائف واحدة تلو الأخرى لخدمات جديدة، بينما الـ Façade يوجّه كل طلب حسب المسار — إما للـ Monolith أو للخدمة الجديدة — دون أن يلاحظ العميل أي فرق.
كل خطوة صغيرة وقابلة للتراجع بسهولة، وقيمة النظام الجديد تظهر تدريجياً بدل انتظار سنة أو أكثر لرؤية أي نتيجة.
الصياغة
Façade: /migrated-feature → new-service /* → legacy-monolith (يتقلّص تدريجياً)
📄 مثال
app.use('/products', (req, res) => proxyTo('product-service', req, res)); // ✅ رُحّلت
app.use('/orders', (req, res) => proxyTo('order-service', req, res)); // ✅ رُحّلت
app.use('/', (req, res) => proxyTo('legacy-monolith', req, res)); // الباقي — لم يُرحَّل بعدأهم النقاط
| العنصر | الوظيفة |
|---|---|
| Façade | نقطة توجيه واحدة تقرر لكل طلب هل يذهب للنظام القديم أو الجديد |
| ترحيل تدريجي | وظيفة واحدة في كل مرة، قابلة للتراجع الفوري عند ظهور مشكلة |
💡 نصائح عملية
- ابدأ بوظيفة محدودة النطاق وواضحة الحدود لأول خطوة ترحيل، لا بأكثر جزء معقّد بالنظام
- خطّط لمشاركة البيانات بين النظام القديم والجديد أثناء فترة الهجرة — غالباً التحدي الأكبر وليس نقل الكود
⚠️ أخطاء شائعة
- محاولة Big Bang Rewrite بدل الترحيل التدريجي في مشروع كبير قائم
- ترك الـ Façade نقطة فشل واحدة بلا تكرار طوال فترة الهجرة الطويلة
خصائص ذات صلة
🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار MICROSERVICES الكامل بالعربي.