ترحيل نظام قديم تدريجياً عن طريق استبدال أجزاء معينة من الوظائف بالتطبيقات والخدمات الجديدة تدريجياً. مع استبدال ميزات من النظام القديم، يستبدل النظام الجديد في النهاية جميع ميزات النظام القديم، ويتخلص من النظام القديم ويسمح لك بإيقاف تشغيله.
السياق والمشكلة
مع تقدم عمر الأنظمة، يمكن أن تصبح أدوات التطوير وتقنية الاستضافة وحتى بنى النظام التي تم بناؤها عليها بالية بشكل متزايد. مع إضافة ميزات ووظائف جديدة، يمكن أن يزداد تعقيد هذه التطبيقات بشكل كبير، ما يجعل من الصعب صيانتها أو إضافة ميزات جديدة إليها.
يمكن أن يكون استبدال نظام معقد بالكامل مهمة ضخمة. غالباً، ستحتاج إلى ترحيل تدريجي إلى نظام جديد، مع الاحتفاظ بالنظام القديم للتعامل مع الميزات التي لم يتم ترحيلها بعد. ومع ذلك، فإن تشغيل نسختين منفصلتين من التطبيق يعني أنه يتعين على العملاء معرفة مكان وجود ميزات معينة. في كل مرة يتم فيها ترحيل ميزة أو خدمة، يحتاج العملاء إلى التحديث للإشارة إلى الموقع الجديد.
حل
يمكنك تدريجياً استبدال أجزاء معينة من الوظائف بالتطبيقات والخدمات الجديدة. قم بإنشاء واجهة تعترض الطلبات التي تنتقل إلى النظام القديم للواجهة الخلفية. تقوم الواجهة بتوجيه هذه الطلبات إما إلى التطبيق القديم أو إلى الخدمات الجديدة. يمكن ترحيل الميزات الحالية إلى النظام الجديد تدريجياً، ويمكن للمستهلكين الاستمرار في استخدام نفس الواجهة، غير مدركين حدوث أي عملية ترحيل.
يساعد هذا النمط على تقليل المخاطر الناتجة عن الترحيل، ونشر جهود التطوير بمرور الوقت. من خلال الواجهة التي توجه المستخدمين بأمان إلى التطبيق الصحيح، يمكنك إضافة وظائف إلى النظام الجديد بأي وتيرة تريدها، مع ضمان استمرار عمل التطبيق القديم. بمرور الوقت، حيث يتم ترحيل الميزات إلى النظام الجديد، يتم التخلص من النظام القديم في النهاية فلا يعود ضرورياً. بمجرد اكتمال هذه العملية، يمكن إيقاف النظام القديم بأمان.
المسائل والاعتبارات
- ضع في اعتبارك كيفية التعامل مع الخدمات ومخازن البيانات التي من المحتمل أن تستخدمها الأنظمة الجديدة والقديمة. تأكد من أن كليهما يمكنه الوصول إلى هذه الموارد جنباً إلى جنب.
- قم ببناء التطبيقات والخدمات الجديدة بطريقة يمكن بسهولة اعتراضها واستبدالها في عمليات الترحيل المستقبلية.
- في مرحلة ما، عند اكتمال الترحيل، ستختفي واجهة التين الخانقة أو تتطور إلى محول للعملاء القدامى.
- تأكد من أن الواجهة تواكب الترحيل.
- تأكد من عدم تحول الواجهة إلى نقطة فشل واحدة أو ازدحام في الأداء.
موعد استخدام النمط
استخدم هذا النمط عند ترحيل تطبيق الواجهة الخلفية تدريجياً إلى بنية جديدة.
قد لا يكون هذا النمط مناسبًا:
- عندما لا يمكن اعتراض الطلبات إلى النظام الخلفي.
- بالنسبة للأنظمة الأصغر حيث يكون تعقيد استبدال الجملة منخفضاً.
تصميم حمل العمل
يجب على المهندس المعماري تقييم كيفية استخدام نمط Strangler Fig في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:
| الركيزة | كيف يدعم هذا النمط أهداف الركيزة |
|---|---|
| تساعد قرارات تصميم الموثوقية حمل العمل الخاص بك على الصمودفي وجه الخلل وضمان استرداده إلى حالة تعمل بشكل كامل بعد حدوث فشل. | يمكن أن يساعد النهج التزايدي لهذا النمط في التخفيف من المخاطر أثناء انتقال المكون مقابل التغييرات النظامية الكبيرة. - اختبار RE:08 |
| يركز تحسين التكلفة على الحفاظ على عائد حمل العمل على الاستثمار وتحسينه. | الهدف من هذا النهج هو زيادة استخدام الاستثمارات الحالية في النظام قيد التشغيل حاليا مع التحديث بشكل متزايد، على هذا النحو يمكنك من إجراء عمليات استبدال عائد الاستثمار العالية قبل عمليات الاستبدال منخفضة العائد على الاستثمار. - تكاليف مكون CO:07 - تكاليف البيئة CO:08 |
| يساعد التميز التشغيلي على تقديم جودة حمل العمل من خلال العمليات الموحدة وتماسك الفريق. | يوفر هذا النمط نهج التحسين المستمر، حيث يفضل الاستبدال التزايدي بالتغييرات الصغيرة بمرور الوقت بدلا من التغييرات النظامية الكبيرة الأكثر خطورة لتنفيذها. - OE:06 تطوير حمل العمل - OE:11 خزينة ممارسات النشر |
كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.
الخطوات التالية
- منشور مدونة مارتن فاولر عن StranglerFigApplication