يستبدل نمط Strangler Fig النظام القديم تدريجيًا بدل إعادة كتابته دفعة واحدة. تضع طبقة توجيه أمام النظام القديم، وتتولى مكوّنات جديدة قدرةً تلو أخرى، ويعمل القديم والجديد جنبًا إلى جنب حتى تتمكن من إيقاف كل جزء قديم. وصف النمط سهل، لكن المشاريع تنجح أو تتعثر عند ثلاثة قرارات: ماذا نوجّه، ومن يملك كل مجموعة بيانات خلال الانتقال، وكيف ننتقل بخطوات يمكن التراجع عنها.
تصف إرشادات AWS Prescriptive Guidance النمط بأنه استبدال تدريجي: واجهة وسيطة (Facade) تعترض الطلبات المتجهة إلى النظام القديم وتوجّه كل طلب إما إلى التطبيق القديم أو إلى خدمة جديدة، فيتعايش الاثنان بينما تنتقل الوظائف. أما الاسم، الذي صاغه Martin Fowler، فمأخوذ من نبات التين الخانق الذي ينمو حول شجرة مضيفة حتى يستغني عنها.
ميزة النمط هي التحكم في المخاطر: تسهّل الخطوات الصغيرة الاختبار والمراقبة والاستعادة، وتستمر القدرات غير المتأثرة على النظام القديم. لكن عليك أن تصمّم مسار التراجع بنفسك، خصوصًا بعد تغيّر البيانات أو تنفيذ إجراءات خارجية. وثمن ذلك فترة يعمل فيها نظامان، إضافة إلى أعمال التوجيه والمزامنة التي يتطلبها التعايش.
ويناسب النمط الأنظمة التي يمكن اعتراض واجهاتها، مثل نقاط HTTP وواجهات API والطوابير وتبادل الملفات، والتي يمكن فصل قدراتها. ولا يناسب كثيرًا نظامًا يجري كل شيء فيه داخل قاعدة بيانات واحدة عبر إجراءات مخزنة مشتركة بلا نقاط فصل، أو نظامًا صغيرًا يكون استبداله بعناية أبسط. وإن كان هدفك إضافة ميزات ذكاء اصطناعي إلى النظام القديم لا استبداله، فدليلنا عن دمج نماذج اللغة في البرمجيات القديمة يتناول هذه المهمة الأضيق.
الجزء قدرة أعمال واحدة لها مدخلاتها ومخرجاتها وبياناتها، مثل نقاط الولاء أو عروض أسعار التوصيل أو إشعارات العملاء. والجزء الأول الجيد:
- له حدود واضحة يمكن وصفها في جملة واحدة؛
- يمكن حصر كل من يستدعيه من السجلات أو رصد حركة الطلبات، لا من الذاكرة؛
- مهم بما يكفي لإثبات القيمة، لكنه ليس القدرة التي يكون تعطلها الأشد ضررًا؛
- يملك بيانات لا تكتب إليها وحدات أخرى كثيرة.
ارسم خريطة المستدعين والبيانات قبل كتابة كود جديد. فالمستهلكون الخفيون، مثل تقرير ليلي يقرأ جدولًا مباشرة، سبب شائع لأن تكسر قدرةٌ منقولة شيئًا لم يتوقعه فريقك.
أدخل طبقة التوجيه قبل نقل أي شيء. في البداية تمرر كل طلب إلى النظام القديم دون تغيير، وحين تعمل في الإنتاج بسجلاتها ومقاييسها يصبح لديك مكان واحد تُجري فيه كل تغيير لاحق.
يمكن أن تطابق قواعد التوجيه مسارًا أو عملية أو مجموعة عملاء أو مفتاح ميزة، وأن تنقل حصة من الطلبات تدريجيًا. احفظ القواعد في نظام إدارة الإصدارات، وراجعها كما تراجع الكود، وتأكد من إمكانية تتبّع كل استجابة إلى المكوّن الذي أنتجها. وقد تكون طبقة التوجيه بوابة API أو وكيلًا عكسيًا أو وحدة داخل التطبيق نفسه؛ وما يهم أن تكون موثوقة وقابلة للمراقبة وسهلة التعديل أكثر مما يهم نوعها.
شكل 1: وجّه الطلبات بحسب القدرة. حافظ على حدود ملكية واضحة.
البيانات أصعب ما في التعايش. وقاعدتنا أن لكل مجموعة بيانات في أي لحظة جهة كتابة معتمدة واحدة فقط.
- قبل الانتقال، يملك النظام القديم البيانات. يقرأ المكوّن الجديد نسخة متزامنة، من أحداث التغيير أو التصديرات المجدولة مثلًا، ولا يقبل كتابات إنتاجية معتمدة.
- عند الانتقال، تنتقل الملكية. أوقف جهة الكتابة القديمة، وأنهِ العمليات الجارية، وألحق التغييرات بالنسخة الجديدة وطابِقها، ثم فعّل جهة الكتابة الجديدة. وتعود التغييرات إلى القاعدة القديمة فقط من أجل المستهلكين الذين ما زالوا يحتاجونها.
- بعد الإيقاف، أزل المزامنة مع الكود القديم الذي كان يعتمد عليها.
تجنّب الكتابة المزدوجة المفتوحة، أي أن يكتب كود التطبيق كل تغيير في النظامين معًا؛ فحين تنجح كتابة وتفشل الأخرى يتباعد النظامان بصمت. وإن لزم تحديث النظامين، فأبقِ مالكًا واحدًا ومسار مزامنة واحدًا، وطابِق بينهما بانتظام، وحدد موعدًا للانتهاء. سجّل التغييرات بطريقة دائمة، وأعد المحاولة بأمان دون تكرار أثر العملية، وراعِ ترتيب الأحداث والحذف وإصدارات المخطط. واحتفظ من اليوم الأول بجدول يربط معرّفات النظام القديم بمعرّفات الجديد، فستحتاجه للمطابقة واستفسارات الدعم والتراجع.
شكل 2: جهة كتابة معتمدة واحدة. انقل الملكية بعد مطابقة البيانات.
خطط لكل جزء عبر تسلسل له شروط استعادة صريحة:
- المقارنة. انسخ طلبات القراءة، أو حاكِ الكتابات في بيئة معزولة تعطّل الآثار الخارجية. قارن المخرجات دون تكرار دفعات مالية أو رسائل أو تعديلات مخزون.
- نقل القراءات. قدّم القراءات من المكوّن الجديد بينما يبقى النظام القديم هو المالك.
- نقل الكتابات. حافظ على جهة كتابة معتمدة واحدة. لا يصلح التدرّج إلا بين أجزاء يمكن فصل ملكيتها بأمان بمفتاح ثابت للعميل أو الكيان. لا توزّع كتابات البيانات نفسها عشوائيًا بين النظامين؛ وإن تعذّر فصل الملكية، فانقل القدرة وحدةً واحدة.
- الإيقاف. أزل المسار القديم والمزامنة بعد تحقق معايير الخروج وفحوص الاستعادة. احفظ ما يلزم للتعافي قبل حذف أجزاء المخطط؛ فقد يصعب عكس الإيقاف نفسه.
اكتب خطة التراجع قبل كل خطوة: الإشارات التي تستدعيه، ومن يقرره، وكيف يعود التوجيه. وبعد انتقال الكتابات، طابِق التغييرات مع حالة قديمة متوافقة، وامنع جهة الكتابة الجديدة من العمل قبل إعادة السلطة للقديمة. فتحويل المسار وحده قد يعرض بيانات متقادمة، ولا يلغي الآثار الخارجية. تدرّب على تسليم البيانات والإجراءات التصحيحية اللازمة، لا على تحويل المسار فقط.
هذا مثال توضيحي، لا حالة عميل حقيقية. يدير نظام ERP لدى شركة تجزئة الطلبات والمخزون ونقاط الولاء. ولقدرة الولاء مدخلات واضحة هي الطلبات المكتملة والمرتجعات، ومخرجات واضحة هي الأرصدة المعروضة عند الدفع وفي التطبيق، فيختارها الفريق جزءًا أول.
يضع الفريق طبقة التوجيه أمام نقاط نهاية الولاء في ERP ويتركها تمرر كل شيء دون تغيير. ثم يبني خدمة الولاء الجديدة ويغذّيها بأحداث الطلبات، ويتركها تحسب الأرصدة بالتوازي لفترة حتى يقارنها بأرصدة ERP. وحين تتطابق المقارنات، ينقل قراءات الأرصدة إلى الخدمة الجديدة. بعدها تصبح الخدمة مالكة معاملات الولاء، وتُبقي مزامنةٌ باتجاه واحد جدولَ الولاء في ERP محدّثًا من أجل تقرير مالي ما زال يقرؤه. وحين يعيد الفريق بناء ذلك التقرير على الخدمة الجديدة، يزيل المزامنة ووحدة الولاء القديمة.
ومن المخاطر أيضًا ترحيل لا يكتمل، فيبقى نظامان يعملان إلى أجل غير مسمى. احتفظ بخريطة من صفحة واحدة توضح القدرات القديمة والمنقولة وتلك التي في منتصف الانتقال، وحدد معايير خروج لكل جزء، وتابع عمليات الإيقاف بالعناية التي تتابع بها الإطلاقات.
وراجع التصميم المستهدف دوريًا وفق الركائز الست في إطار AWS Well-Architected: التميز التشغيلي، والأمان، والموثوقية، وكفاءة الأداء، وتحسين التكلفة، والاستدامة. والإطار هيكل للمراجعة، واستخدامه لا يتطلب خدمات AWS. والعادات نفسها، من حدود واضحة وملكية بيانات صريحة ومراقبة، تنطبق على المنتجات الجديدة كما يوضح دليلنا عن قرارات المعمارية من المنتج الأولي إلى التوسع. وإن كان دافع التحديث إصدارًا غير مدعوم من إطار عمل، فقارن الترقية في المكان بنقل الأجزاء؛ ويناقش مقالنا عن Laravel وNode.js لواجهات API المؤسسية هذا الاختيار.
وإن كان النظام الذي تحدّثه يشغّل موقعًا أو بوابة للعملاء، فيمكن لفريق خدمة تصميم وتطوير المواقع أن يساعدك في تخطيط الجزء الأول وتوجيهه.
- Amazon Web Services. Strangler fig pattern، ضمن AWS Prescriptive Guidance: الاستبدال التدريجي خلف واجهة وسيطة، مع تعايش المكوّنات القديمة والجديدة أثناء الترحيل.
- Amazon Web Services. AWS Well-Architected Framework: الركائز الست المستخدمة في مراجعات المعمارية.
توصيات ملكية البيانات والانتقال والتراجع في هذا المقال إرشادات هندسية من تكنوستاك، لا متطلبات من AWS.
