يا أهلاً وسهلاً فيكم. اسمحولي أحكيلكم قصة صارت معي قبل كم سنة. كنت بشتغل مع شركة عندها نظام “خُتْيار”، نظام إدارة محتوى وتجارة إلكترونية ضخم، عمره فوق العشر سنين. هاد النظام كان هو الدجاجة اللي بتبيض ذهب للشركة، بس بنفس الوقت كان زي البيت القديم اللي كل ما تصلّح فيه إشي بتخرب عشرة.
الفريق كان مرعوب منه، أي تعديل بسيط كان بده أسابيع من الاختبارات والخوف من إنه “يضرب” النظام كله. الإدارة، كالعادة، بدها ميزات جديدة وسريعة عشان تنافس بالسوق. الشباب كانوا محبوسين بين مطرقة الإدارة وسندان هاد الكود القديم. كانوا مخنوقين بمعنى الكلمة.
في اجتماع من الاجتماعات، الكل كان بقترح “الحل السحري”: نعيد كتابة كل شي من الصفر! مشروع ضخم، بياخد سنتين، وبنرمي النظام القديم. أنا وقتها صفنت شوي، وتذكرت وثائقي عن الطبيعة شفته مرة عن شجرة اسمها “التينة الخانقة” (Strangler Fig). هاي الشجرة بتنمو فوق شجرة تانية كبيرة وقديمة، بتلف حواليها شوي شوي، وبتاخد منها الشمس والمي، ومع السنين، الشجرة القديمة بتموت وبتتحلل، وبتضل التينة الخانقة مكانها، قوية وشامخة.
وقفت وقلتلهم: “يا جماعة، ليش ما نعمل زي التينة الخانقة؟ ليش ما نخنق الـ’خُتْيار’ هاد شوي شوي، على رواق، وبدون ما حدا يحس؟”. ومن هداك اليوم، بدأت رحلتنا مع نمط معمارية البرمجيات اللي بنسميه “نمط الخانق”.
ما هو المونوليث (Monolith)؟ أو “الخُتْيار” العنيد
قبل ما نغوص في الحل، خلينا نفهم المشكلة. المونوليث (Monolith) هو مصطلح بنطلقه على التطبيق اللي كل أجزائه مرتبطة ببعضها في كتلة برمجية واحدة. كل شي في مكان واحد: واجهة المستخدم، منطق العمل (Business Logic)، التعامل مع قاعدة البيانات، كله في مشروع واحد، يتم نشره (deploy) كوحدة واحدة.
في بداياته، المونوليث بكون ممتاز وسريع في التطوير. لكن مع الوقت والنجاح، بيكبر وبيكبر، وبصير زي “الخُتْيار” اللي حكينا عنه:
- صعب التعديل: أي تغيير صغير في مكان ممكن يأثر على كل النظام.
- بطيء في النشر: لازم تختبر وتنشر كل التطبيق الضخم عشان تعديل بسيط.
- التقنيات القديمة: بكون محبوس بتقنيات قديمة وصعب تتبنى أي شي جديد.
- عقبة في وجه التوسع (Scalability): إذا جزء واحد عليه ضغط، لازم تعمل نسخة من كل التطبيق الضخم عشان تتحمل الضغط، وهذا إهدار للموارد.
فخ إعادة الكتابة من الصفر (The “Big Bang” Rewrite)
أول فكرة بتخطر على بال أي فريق محبط هي “يلا نهدم كل شي ونبني من جديد”. هاي الفكرة جذابة، لكنها فخ خطير جداً. ليش؟
- مخاطرة عالية: أنت بتراهن بمستقبل الشركة على مشروع واحد ضخم. لو فشل، راحت عليك.
- وقت طويل للقيمة: ما رح تشوف أي فائدة أو ميزة جديدة إلا بعد انتهاء المشروع بالكامل، ممكن بعد سنة أو سنتين. خلال هاد الوقت، المنافسين بكونوا طلعوا ميزات جديدة.
- النظام القديم لا يتوقف: خلال فترة إعادة الكتابة، فريق الصيانة رح يضل يضيف تعديلات وإصلاحات على النظام القديم. يعني الهدف اللي بتحاول توصله (النظام الجديد) قاعد ببعد عنك كل يوم.
- إرهاق الفريق: المشاريع الطويلة والمجهولة النتائج بتقتل معنويات الفريق وبتحسسهم بالضغط والإحباط. حرفياً بتخنقهم.
وهون بيجي دور بطل قصتنا…
نمط الخانق (The Strangler Fig Pattern): الحل الطبيعي
مارتن فاولر، واحد من حكماء البرمجة، هو اللي أعطى هاد النمط اسمه المستوحى من الطبيعة. الفكرة بسيطة وعبقرية: بدلاً من استبدال المونوليث دفعة واحدة، أنت تبني نظاماً جديداً حوله، وتجعله يعترض الطلبات (Requests) تدريجياً.
مع مرور الوقت، النظام الجديد “يخنق” المونوليث القديم، حيث يتم تحويل المزيد والمزيد من الوظائف إليه، حتى يصبح المونوليث في النهاية مجرد قشرة فارغة يمكن إزالتها بأمان.
خطوات تطبيق نمط الخانق عملياً
هاد الحكي النظري حلو، بس كيف بنطبقه على أرض الواقع؟ “كيف بنبلش يا أبو عمر؟”. ركزوا معي يا خوال، الشغل النظيف بيجي خطوة خطوة.
الخطوة الأولى: تحديد “خطوط التماس” (Identify the Seams)
أول شي، بدك تلاقي منطقة في المونوليث بنقدر “نفصلها” بسهولة. دور على وحدة (Module) مستقلة نسبياً أو عليها طلب كبير للتعديل. أمثلة ممتازة للبداية:
- نظام إدارة المستخدمين والمصادقة (Authentication).
- صفحات عرض المنتجات في متجر إلكتروني.
- نظام الإشعارات.
- صفحة المدونة أو المقالات.
الفكرة هي أن تبدأ بشيء له حدود واضحة ويعطي قيمة سريعة عند تحديثه.
الخطوة الثانية: بناء الواجهة الخانقة (The Strangler Facade)
هذا هو أهم جزء في النمط. الواجهة دي هي عبارة عن طبقة (غالبًا Reverse Proxy) بتقعد بين المستخدم والمونوليث. كل الطلبات من الإنترنت بتمر من خلالها.
هاي الواجهة هي اللي بتقرر: هل أرسل هذا الطلب إلى المونوليث القديم، أم إلى الخدمة الجديدة اللي بنيناها؟ في البداية، كل الطلبات (100%) رح تروح للمونوليث.
الخطوة الثالثة: بناء الخدمة الجديدة (Implement the New Service)
هون بتبلش المتعة. بتاخد الوحدة اللي اخترتها في الخطوة الأولى، وبتبنيها كخدمة مصغرة (Microservice) مستقلة، باستخدام أحدث التقنيات اللي بتحبها (Node.js, Go, Python, Rust… إلخ). هاي فرصتك للتخلص من الديون التقنية وبناء شي نظيف.
الخطوة الرابعة: التحويل التدريجي (Intercept and Redirect)
بعد ما خدمتك الجديدة تصير جاهزة، بترجع للواجهة الخانقة (Strangler Facade) وبتعمل تعديل بسيط في إعداداتها. مثلاً، بتقولها:
“يا واجهة، أي طلب بيجي على المسار
/api/users، لا تبعتيه للمونوليث، ابعتيه للخدمة الجديدة تبعت المستخدمين. باقي الطلبات، خليها تروح للمونوليث كالعادة”.
وهيك بتكون أول غصن من التينة الخانقة لف حوالين الشجرة القديمة.
الخطوة الخامسة: كرر العملية يا خال (Rinse and Repeat)
الآن، بتكرر العملية. بتختار وحدة تانية من المونوليث، بتبنيها كخدمة جديدة، وبتعدّل الواجهة عشان تحوّل الطلبات إلها. ومع كل تكرار، المونوليث بصغر دوره، والخدمات الجديدة بتكبر وبتسيطر.
مثال كود بسيط لواجهة خانقة باستخدام Express.js
لنفترض أن المونوليث يعمل على http://localhost:8000 والخدمة الجديدة للمستخدمين تعمل على http://localhost:3000. يمكن بناء الواجهة باستخدام Node.js و Express كالتالي:
const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
// عنوان المونوليث القديم
const monolithApi = 'http://localhost:8000';
// عنوان الخدمة الجديدة للمستخدمين
const usersServiceApi = 'http://localhost:3000';
// أي طلب يبدأ بـ /api/v2/users اذهب إلى الخدمة الجديدة
app.use('/api/v2/users', createProxyMiddleware({
target: usersServiceApi,
changeOrigin: true,
// يمكنك إعادة كتابة المسار إذا لزم الأمر
pathRewrite: { '^/api/v2/users': '/users' },
}));
// أي طلب آخر، اذهب إلى المونوليث القديم
app.use('/', createProxyMiddleware({
target: monolithApi,
changeOrigin: true
}));
app.listen(5000, () => {
console.log('Strangler Facade is running on port 5000');
});
هذا الكود البسيط هو قلب نمط الخانق. هو “المحوّل” الذكي اللي بيسمح للنظامين بالتعايش بسلام خلال الفترة الانتقالية.
نصائح من خبرة أبو عمر
هاد النمط مش وردي بالكامل، وفي مطبات ممكن توقع فيها. خذوا هالنصايح من الآخر:
- مزامنة البيانات هي التحدي الأكبر: كيف رح تتعامل مع البيانات المشتركة بين النظام القديم والجديد؟ ممكن تحتاج تعمل كتابة مزدوجة (Dual Writes) لفترة، أو تستخدم نمط اسمه (Event Sourcing) عشان تخلي الأنظمة متزامنة. خطط لهي النقطة منيح.
- لا تجعل الواجهة الخانقة مونوليث جديد: حافظ على الواجهة (Facade) بسيطة ومختصة بالتحويل فقط. لا تضع فيها أي منطق عمل (Business Logic).
- المراقبة والتوثيق: من أول يوم، لازم يكون عندك نظام مراقبة (Monitoring) قوي عشان تعرف شو اللي بصير بالضبط. أي خدمة بتفشل؟ كم طلب بروح لهون وكم لهون؟ وثّق كل قرار بتاخده.
- احصل على دعم الإدارة: اشرحلهم الاستراتيجية. قولهم إنها رح تاخد وقت، لكنها بتقلل المخاطر وبتعطي قيمة بشكل مستمر. لما يشوفوا ميزات جديدة بتنزل كل فترة قصيرة، رح يتحمسوا ويدعموكم.
الخلاصة: خنق تدريجي، نجاح مؤكد
تحديث الأنظمة القديمة هو من أصعب التحديات اللي بتواجه أي فريق برمجي. إعادة الكتابة من الصفر مغرية لكنها انتحار بطيء في معظم الحالات. نمط الخانق بيعطينا طريق ثالث: طريق الصبر والحكمة، طريق النمو الطبيعي والتدريجي.
إنه يسمح لك بتقديم قيمة لعملك بسرعة، واستخدام أحدث التقنيات، ورفع معنويات فريقك بإعطائهم انتصارات صغيرة ومستمرة. أنت لا تهدم الماضي، بل تبني المستقبل حوله حتى يصبح الماضي مجرد ذكرى.
فالمرة الجاي لما تلاقي حالك قدام نظام “خُتْيار” عنيد، تذكر قصة التينة الخانقة، وبلّش ازرع أول غصن. بالتوفيق يا أبطال! 😉
