Strangler Fig: ترحيل نظام PHP تقليدي إلى Laravel دون تجميد الميزات

كل تطبيق PHP قديم يصل إلى نفس النقطة. قاعدة الكود عمرها عقد، لا أحد يريد لمس وحدة الطلب، الإطار المستخدم لم يصدر تحديثًا منذ 2019، ويُقترح إعادة كتابة. يقولون 18 شهرًا. تجميد الميزات أثناء التنفيذ.

هذا المشروع معروف بفشل متكرر، والسبب دائمًا نفسه: لا يمكن للأعمال التوقف فعليًا 18 شهرًا، فتُجرى تغييرات على النظام القديم، ويتأخر الجديد، ويصبح الترحيل هدفًا متحركًا دائمًا. بعد عامين لديك نظامان وأحدهما غير مكتمل.

نمط strangler fig يتجنب ذلك بعدم وجود انتقال كامل. تُبنى الوظائف الجديدة في Laravel، وتُنقل الوظائف القائمة مسارًا تلو الآخر، ويُوجّه المرور إلى النظام الذي يملك كل مسار حاليًا. يتقلص التطبيق القديم حتى يختفي.

حدود التوجيه

كل شيء يعتمد على القدرة على إرسال طلب إلى أي من التطبيقين دون علم المستخدم. ضع وكيل عكسي أمامهما ووجّه حسب المسار.

• اجعل كل شيء افتراضيًا إلى التطبيق القديم في اليوم الأول، بحيث يكون الوكيل بلا تأثير ويمكن نشره مستقلًا عن أي عمل ترحيل.
• انقل مسارًا واحدًا في كل مرة بإضافته إلى قائمة Laravel في الوكيل. هذه الآن آلية الترحيل الخاصة بك، وهي تغيير في التكوين.
• اجعل التراجع بسيطًا. إعادة مسار إلى النظام القديم يجب أن تكون تغييرًا في التكوين وإعادة تحميل، وليس نشرًا. ستحتاج هذا.
• لا توجه على أساس أي شيء معقد. بادئات المسار كافية. التوجيه حسب شريحة المستخدم أو علم الميزة يبدو جذابًا لكنه يضاعف الحالات التي يجب التفكير فيها.

هذه القطعة الواحدة من البنية التحتية تحول مقامرة 18 شهرًا إلى سلسلة قرارات أسبوعية.

الجلسات والمصادقة: حلّ هذا أولًا

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

1. انقل تخزين الجلسة إلى مكان يمكن للتطبيقين قراءته — Redis أو قاعدة البيانات — قبل ترحيل أي مسار.
2. اتفق على صيغة تسلسل. تطبيقا PHP بإصدارات إطار مختلفة لا يضمنان تسلسل الجلسة بنفس الطريقة. اختبر ذلك صراحة بدلاً من الافتراض.
3. شارك نطاق ومسار الكوكيز، ووافق على اسم الكوكيز.
4. اجعل نظامًا واحدًا مسؤولًا عن المصادقة. عادة Laravel، بعد ترحيل مسار تسجيل الدخول، مع قراءة التطبيق القديم للجلسة دون كتابتها.
5. اختبر انتهاء صلاحية الجلسة وتجديدها عبر الحدود. تسجيل الخروج من جهة والبقاء مسجلاً من جهة أخرى هو خلل أمني، وليس مجرد إزعاج.

حدود قاعدة البيانات

الإجابة العملية لمعظم الترحيلات: يشارك التطبيقان قاعدة بيانات واحدة، ولا تحاول إعادة تصميم المخطط أثناء الترحيل.

هذا يزعج البعض، وهو صحيح. ترحيل الكود والمخطط معًا يعني أن كل مشكلة لها سببان محتملان، ويزيل قدرتك على نقل مسار واحد بشكل مستقل. انتقل إلى Laravel أولًا؛ وحسّن المخطط لاحقًا، عندما يكون لديك قاعدة كود واحدة ويمكنك تغييره بثقة.

• ارسم مخطط النظام القديم باستخدام نماذج Eloquent كما هو، بما في ذلك أسماء الجداول التي لن تختارها أبدًا.
• اكتب إلى نفس الجداول بحيث يرى كلا النظامين الحقيقة نفسها دون وجود طبقة تزامن قد تتعرض للخطأ.
• كن حذرًا مع المشغلات والإجراءات المخزنة القديمة — فهي غالبًا منطق أعمال غير موثق قد يُفعّل أيضًا ضمن Laravel.
• أدخل الترحيلات للجداول الجديدة فقط. لا تسمح لنظام الترحيل في Laravel بالتحكم في المخطط القديم أثناء المشروع.
• راقب الكود القديم الذي يكتب الطوابع الزمنية أو المعرفات بطرق لا يتوقعها Eloquent. هذا مصدر شائع لأخطاء دقيقة.

ما الذي نهاجره أولًا؟

تسلسل التنفيذ أهم من السرعة.

1. ابدأ بشيء منخفض المخاطر ومرئي — صفحة ثابتة، نموذج اتصال، قسم مساعدة. الهدف هو إثبات عمل التوجيه، الجلسة وآلية النشر من البداية للنهاية، وليس تقديم قيمة.
2. الميزات الجديدة من الآن فصاعدًا. كل ما يُبنى بعد اليوم الأول يُدرج في Laravel. هذا ما يجعل الترحيل يمول نفسه: خارطة الطريق تمول نمو النظام الجديد.
3. المناطق ذات التغييرات العالية تلي ذلك. أي شيء يحرره الفريق بشكل متكرر يستفيد أكثر من وجوده في قاعدة الكود القابلة للصيانة، والجهد يعود بالنفع فورًا.
4. صفحات العملاء التي تعتمد على القراءة بشكل كبير حيث تحقق مكاسب في الأداء وتحسين محركات البحث إلى جانب الترحيل.
5. الدفع، إتمام الطلبات والمعالجة أخيرًا. أعلى المخاطر، وأعلى تكلفة للخطأ، وبحلول ذلك الوقت يكون فريقك قد هاجر عدة أشياء أبسط.
6. الإدارة والمكاتب الخلفية أخيرًا، إلا إذا كانت تعيق العمل فعليًا. المستخدمون الداخليون يتسامحون مع القبح؛ العملاء لا.

الغرائز تدفعك لبدء أسوأ وحدة. قاوم ذلك. البدء بالأصعب يعني أن أول ترحيل لك هو أيضًا أول مواجهة لكل مشاكل البنية التحتية دفعة واحدة.

إبقاء خارطة الطريق قيد التقدّم

هذا هو الهدف كله، ويحتاج إلى حماية متعمدة.

• حدد تقسيمًا ثابتًا — مثلاً 70% لخارطة الطريق، 30% للترحيل — والتزم به. الترحيل الذي يستهلك كل السعة يصبح مشكلة تجارية خلال ربع سنة، والمشاكل التجارية تُلغى.
• اجعل كل مسار يتم ترحيله يقدم شيئًا. أصلح خطأ معروفًا، حسّن الصفحة، أضف ميزة صغيرة. الترحيل الذي لا يقدم قيمة مرئية لمدة ستة أشهر يفقد راعيه.
• أبلغ عن التقدم بعدد المسارات التي تم ترحيلها والملفات القديمة التي حُذفت. حذف الكود هو الدليل الواضح الوحيد على نجاح ترحيل strangler-fig.
• لا تلمس الكود القديم إلا لإصلاح الأخطاء. كل تحسين على نظام أنت بصدد إزالته هو هدر للمال.

أنماط الفشل

1. التوقف عند 60%. تم إنجاز المسارات السهلة، وبقيت الصعبة، وتناقص الألم بما يكفي ليختفي الإلحاح. الآن تحافظ على نظامين إلى الأبد، وهذا أسوأ من أي منهما. اتفق مسبقًا على ما يحفز إتمام المهمة.
2. بناء طبقة تجريد بين النظامين. يبدو كمهارة هندسية جيدة لكنه نظام ثالث يجب صيانته، وسيعيش بعد الترحيل الذي خُصص له.
3. ترحيل المخطط في نفس الوقت. يضاعف المتغيرات في كل حادث.
4. عدم وجود انضباط في الحذف. إذا لم يُحذف الكود القديم مع ترحيل المسارات، فأنت لا تهاجر، بل تكرر.
5. التقليل من قيمة غير الموثق. مهام كرون، نقاط نهاية webhook، تقارير مالية شهرية، تكامل لا يتذكره أحد. قم بجردها قبل البدء؛ إذا وجدتها في الإنتاج، ستجدك أولاً.

متى لا يجب القيام بذلك

لا يعتبر strangler-fig صحيحًا دائمًا. لا تستخدمه إذا كان التطبيق القديم صغيرًا حقًا — أقل من بضعة آلاف سطر، إعادة كتابة مباشرة أسرع والآليات المتوازية عبء لا تحتاجه. لا تستخدمه إذا كان النظام القديم يُستبدل كليًا وليس يُعاد تصميمه. ولا تستخدمه إذا كان منطق الأعمال نفسه يحتاج إلى تغيير؛ ترحيل منطق تنوي التخلص منه هو عمل مزدوج.

هذا هو النمط وراء معظم أعمال تطوير Laravel على الأنظمة الموروثة، ويقترن بخطوة التقييم التي نصفها في وراثة قاعدة كود PHP قديمة. تغطي ممارستنا في منصة Laravel وتحديث PHP المخصص كلا جانبي المشكلة.

اطلب مراجعة التسلسل

تحدد قرارات التوجيه، الجلسة والتسلسل ما إذا كان هذا سينجح. سنراجع قراراتك قبل أن تلتزم بها هندسيًا. تحدث إلى فريقنا؛ نرد خلال يوم عمل.