استراتيجيات مرنة في العالم الحقيقي لمشاريع التكنولوجيا المالية

تشير المرونة في البرمجيات إلى قدرة التطبيق على الاستمرار في العمل بسلاسة وموثوقية، حتى في مواجهة المشكلات أو الأعطال غير المتوقعة. في مشاريع التكنولوجيا المالية، تكون المرونة ذات أهمية خاصة بسبب عدة أسباب. أولاً، تلتزم الشركات بتلبية المتطلبات التنظيمية وتؤكد الهيئات التنظيمية المالية على المرونة التشغيلية للحفاظ على الاستقرار داخل النظام. علاوة على ذلك، فإن انتشار الأدوات الرقمية والاعتماد على مقدمي الخدمات من جهات خارجية يعرض شركات التكنولوجيا المالية لتهديدات أمنية متزايدة. تساعد المرونة أيضًا في التخفيف من مخاطر الانقطاعات الناجمة عن عوامل مختلفة مثل التهديدات الإلكترونية أو الأوبئة أو الأحداث الجيوسياسية، وحماية العمليات التجارية الأساسية والأصول الحيوية. من خلال أنماط المرونة، نفهم مجموعة من أفضل الممارسات والاستراتيجيات المصممة لضمان قدرة البرامج على تحمل الانقطاعات والحفاظ على عملياتها. تعمل هذه الأنماط كشبكات أمان، وتوفر آليات للتعامل مع الأخطاء وإدارة الحمل والتعافي من الأعطال، وبالتالي ضمان بقاء التطبيقات قوية وموثوقة في ظل الظروف المعاكسة. تتضمن استراتيجيات المرونة الأكثر شيوعًا الحاجز، والذاكرة المؤقتة، والبديل، وإعادة المحاولة، وقاطع الدائرة. في هذه المقالة، سأناقشها بمزيد من التفصيل، مع أمثلة للمشكلات التي يمكن أن تساعد في حلها. الحاجز دعنا نلقي نظرة على الإعداد أعلاه. لدينا تطبيق عادي للغاية به العديد من الواجهات الخلفية التي يمكننا الحصول منها على بعض البيانات. هناك العديد من عملاء HTTP المتصلين بهذه الواجهات الخلفية. اتضح أن جميعهم يشتركون في نفس مجموعة الاتصال! بالإضافة إلى موارد أخرى مثل وحدة المعالجة المركزية وذاكرة الوصول العشوائي. ماذا سيحدث إذا واجهت إحدى الواجهات الخلفية نوعًا من المشكلات التي تؤدي إلى ارتفاع زمن الاستجابة للطلبات؟ نظرًا لارتفاع وقت الاستجابة، ستصبح مجموعة الاتصال بالكامل مشغولة بالطلبات التي تنتظر ردودًا من الواجهة الخلفية 1. ونتيجة لذلك، لن تتمكن الطلبات المخصصة للواجهة الخلفية السليمة 2 والواجهة الخلفية 3 من المتابعة لأن المجموعة استنفدت. وهذا يعني أن الفشل في إحدى الواجهات الخلفية لدينا يمكن أن يتسبب في فشل في التطبيق بأكمله. من الناحية المثالية، نريد فقط أن تتعرض الوظائف المرتبطة بالواجهة الخلفية الفاشلة للتدهور، بينما يستمر باقي التطبيق في العمل بشكل طبيعي. ما هو نمط الحاجز؟ مصطلح "نمط الحاجز" مشتق من بناء السفن، ويتضمن إنشاء عدة حجرات معزولة داخل السفينة. إذا حدث تسرب في حجرة واحدة، فإنها تمتلئ بالماء، لكن الحجرات الأخرى تظل غير متأثرة. يمنع هذا العزل السفينة بأكملها من الغرق بسبب خرق واحد. كيف يمكننا استخدام نمط الحاجز لإصلاح هذه المشكلة؟ يمكن استخدام نمط Bulkhead لعزل أنواع مختلفة من الموارد داخل التطبيق، مما يمنع حدوث فشل في جزء واحد من النظام بأكمله. وفيما يلي كيفية تطبيقه على مشكلتنا: عزل مجموعات الاتصال يمكننا إنشاء مجموعات اتصال منفصلة لكل واجهة خلفية (الواجهة الخلفية 1، الواجهة الخلفية 2، الواجهة الخلفية 3). وهذا يضمن أنه إذا كانت الواجهة الخلفية 1 تعاني من أوقات استجابة عالية أو أعطال، فسيتم استنفاد مجموعة الاتصال الخاصة بها بشكل مستقل، مما يترك مجموعات الاتصال الخاصة بالواجهة الخلفية 2 والواجهة الخلفية 3 غير متأثرة. يسمح هذا العزل للواجهات الخلفية السليمة بمواصلة معالجة الطلبات بشكل طبيعي. تحديد الموارد للأنشطة الخلفية باستخدام Bulkheads، يمكننا تخصيص موارد محددة للأنشطة الخلفية، مثل المعالجة الدفعية أو المهام المجدولة. وهذا يمنع هذه الأنشطة من استهلاك الموارد اللازمة للعمليات في الوقت الفعلي. على سبيل المثال، يمكننا تقييد عدد الخيوط أو استخدام وحدة المعالجة المركزية المخصصة للمهام الخلفية، مما يضمن بقاء موارد كافية متاحة للتعامل مع الطلبات الواردة. يمكن أيضًا تطبيق Bulkheads للحد من عدد الطلبات الواردة إلى أجزاء مختلفة من التطبيق. على سبيل المثال، يمكننا تعيين حد أقصى لعدد الطلبات التي يمكن معالجتها في وقت واحد لكل خدمة أعلى. يمنع هذا أي واجهة خلفية واحدة من إرهاق النظام ويضمن أن الواجهات الخلفية الأخرى يمكنها الاستمرار في العمل حتى إذا كانت إحداها تحت حمل ثقيل. كيس لنفترض أن أنظمة الواجهة الخلفية لدينا لديها احتمال منخفض لمواجهة الأخطاء بشكل فردي. ومع ذلك، عندما تتضمن العملية استعلام كل هذه الأنظمة الخلفية بالتوازي، يمكن لكل منها إرجاع خطأ بشكل مستقل. ولأن هذه الأخطاء تحدث بشكل مستقل، فإن الاحتمال الإجمالي لحدوث خطأ في تطبيقنا أعلى من احتمال حدوث خطأ في أي نظام خلفي واحد. يمكن حساب احتمال الخطأ التراكمي باستخدام الصيغة P_total=1−(1−p)^n، حيث n هو عدد أنظمة الواجهة الخلفية. على سبيل المثال، إذا كان لدينا عشرة واجهات خلفية، كل منها باحتمال خطأ p=0.001 (يتوافق مع اتفاقية مستوى الخدمة بنسبة 99.9%)، فإن احتمال الخطأ الناتج هو: إجمالي القيمة = 1−(1−0.001)^10=0.009955 هذا يعني أن مستوى SLA المجمع لدينا ينخفض إلى حوالي 99%، مما يوضح كيف تنخفض الموثوقية الإجمالية عند الاستعلام عن العديد من الخوادم الخلفية بالتوازي. للتخفيف من هذه المشكلة، يمكننا تنفيذ ذاكرة تخزين مؤقتة في الذاكرة. كيف يمكننا حل هذه المشكلة باستخدام ذاكرة التخزين المؤقت في الذاكرة تعمل ذاكرة التخزين المؤقت في الذاكرة كمخزن بيانات عالي السرعة، حيث تخزن البيانات التي يتم الوصول إليها بشكل متكرر وتزيل الحاجة إلى جلبها من مصادر بطيئة محتملة في كل مرة. ونظرًا لأن ذاكرة التخزين المؤقت المخزنة في الذاكرة لديها فرصة 0% للخطأ مقارنة بجلب البيانات عبر الشبكة، فإنها تزيد بشكل كبير من موثوقية تطبيقنا. وعلاوة على ذلك، تعمل ذاكرة التخزين المؤقت على تقليل حركة المرور على الشبكة، مما يقلل بشكل أكبر من فرصة حدوث الأخطاء. وبالتالي، من خلال الاستفادة من ذاكرة التخزين المؤقت في الذاكرة، يمكننا تحقيق معدل خطأ أقل في تطبيقنا مقارنة بأنظمة الواجهة الخلفية لدينا. بالإضافة إلى ذلك، توفر ذاكرة التخزين المؤقت في الذاكرة استردادًا أسرع للبيانات من الجلب المستند إلى الشبكة، وبالتالي تقليل زمن انتقال التطبيق - وهي ميزة ملحوظة. ذاكرة التخزين المؤقت في الذاكرة: ذاكرة التخزين المؤقت المخصصة بالنسبة للبيانات الشخصية، مثل ملفات تعريف المستخدم أو التوصيات، يمكن أن يكون استخدام ذاكرة التخزين المؤقت في الذاكرة فعالاً للغاية أيضًا. ولكننا نحتاج إلى ضمان انتقال جميع الطلبات من المستخدم باستمرار إلى نفس مثيل التطبيق للاستفادة من البيانات المخزنة مؤقتًا لهم، الأمر الذي يتطلب جلسات ثابتة. قد يكون تنفيذ الجلسات الثابتة أمرًا صعبًا، ولكن في هذا السيناريو، لا نحتاج إلى آليات معقدة. إعادة التوازن الطفيف لحركة المرور مقبولة، لذا فإن خوارزمية موازنة الحمل المستقرة مثل التجزئة المتسقة ستكون كافية. علاوة على ذلك، في حالة فشل العقدة، تضمن التجزئة المتسقة أن يخضع فقط المستخدمون المرتبطون بالعقدة الفاشلة لإعادة التوازن، مما يقلل من تعطيل النظام. يعمل هذا النهج على تبسيط إدارة ذاكرة التخزين المؤقت المخصصة ويعزز الاستقرار والأداء العام لتطبيقنا. ذاكرة التخزين المؤقت في الذاكرة: تكرار البيانات المحلية إذا كانت البيانات التي نعتزم تخزينها مؤقتًا بالغة الأهمية وتُستخدم في كل طلب يتعامل معه نظامنا، مثل سياسات الوصول أو خطط الاشتراك أو الكيانات الحيوية الأخرى في مجالنا، فقد يشكل مصدر هذه البيانات نقطة فشل كبيرة في نظامنا. ولمعالجة هذا التحدي، فإن أحد الأساليب هو تكرار هذه البيانات بالكامل مباشرة في ذاكرة تطبيقنا. في هذا السيناريو، إذا كان حجم البيانات في المصدر قابلاً للإدارة، فيمكننا بدء العملية عن طريق تنزيل لقطة من هذه البيانات في بداية تطبيقنا. بعد ذلك، يمكننا تلقي أحداث التحديثات لضمان بقاء البيانات المخزنة مؤقتًا متزامنة مع المصدر. من خلال اعتماد هذه الطريقة، نعزز موثوقية الوصول إلى هذه البيانات الحاسمة، حيث يحدث كل استرجاع مباشرة من الذاكرة باحتمال خطأ 0%. بالإضافة إلى ذلك، فإن استرجاع البيانات من الذاكرة سريع بشكل استثنائي، وبالتالي تحسين أداء تطبيقنا. تعمل هذه الاستراتيجية بشكل فعال على تخفيف المخاطر المرتبطة بالاعتماد على مصدر بيانات خارجي، مما يضمن الوصول المتسق والموثوق به إلى المعلومات المهمة لتشغيل تطبيقنا. تكوين قابل لإعادة التحميل ومع ذلك، فإن الحاجة إلى تنزيل البيانات عند بدء تشغيل التطبيق، وبالتالي تأخير عملية بدء التشغيل، تنتهك أحد مبادئ "تطبيقات 12 عاملاً" التي تدعو إلى بدء تشغيل التطبيق بسرعة. ولكننا لا نريد أن نتخلى عن فوائد استخدام التخزين المؤقت. لمعالجة هذه المعضلة، دعنا نستكشف الحلول المحتملة. يعد التشغيل السريع أمرًا بالغ الأهمية، وخاصة بالنسبة للمنصات مثل Kubernetes، التي تعتمد على الترحيل السريع للتطبيقات إلى عقد مادية مختلفة. ولحسن الحظ، يمكن لـ Kubernetes إدارة التطبيقات البطيئة التشغيل باستخدام ميزات مثل مجسات بدء التشغيل. من التحديات الأخرى التي قد نواجهها تحديث التكوينات أثناء تشغيل التطبيق. غالبًا ما يكون تعديل أوقات التخزين المؤقت أو مهلة الطلب ضروريًا لحل مشكلات الإنتاج. حتى إذا كان بإمكاننا نشر ملفات التكوين المحدثة بسرعة على تطبيقنا، فإن تطبيق هذه التغييرات يتطلب عادةً إعادة التشغيل. مع إطالة وقت بدء تشغيل كل تطبيق، يمكن أن يؤدي إعادة التشغيل المتتالية إلى تأخير نشر الإصلاحات لمستخدمينا بشكل كبير. لمعالجة هذه المشكلة، هناك حل يتمثل في تخزين التكوينات في متغير متزامن وتحديثها بشكل دوري بواسطة خيط خلفي. ومع ذلك، قد تتطلب بعض المعلمات، مثل مهلة انتظار طلبات HTTP، إعادة تهيئة عملاء HTTP أو قاعدة البيانات عند تغير التكوين المقابل، مما يشكل تحديًا محتملًا. ومع ذلك، تدعم بعض العملاء، مثل برنامج تشغيل Cassandra لـ Java، إعادة تحميل التكوينات تلقائيًا، مما يبسط هذه العملية. إن تنفيذ تكوينات قابلة لإعادة التحميل يمكن أن يخفف من التأثير السلبي لأوقات بدء تشغيل التطبيق الطويلة ويقدم فوائد إضافية، مثل تسهيل تنفيذ أعلام الميزات. يتيح لنا هذا النهج الحفاظ على موثوقية التطبيق واستجابته مع إدارة تحديثات التكوين بكفاءة. العودة الآن دعنا نلقي نظرة على مشكلة أخرى: في نظامنا، عندما يتم تلقي طلب مستخدم ومعالجته عن طريق إرسال استعلام إلى خادم خلفي أو قاعدة بيانات، في بعض الأحيان، يتم تلقي استجابة خطأ بدلاً من البيانات المتوقعة. بعد ذلك، يستجيب نظامنا للمستخدم بـ "خطأ". ومع ذلك، في العديد من السيناريوهات، قد يكون من الأفضل عرض بيانات قديمة بعض الشيء مع رسالة تشير إلى وجود تأخير في تحديث البيانات، بدلاً من ترك المستخدم مع رسالة خطأ حمراء كبيرة. لمعالجة هذه المشكلة وتحسين سلوك نظامنا، يمكننا تنفيذ نمط "العودة إلى الحالة الأصلية". يتضمن المفهوم وراء هذا النمط وجود مصدر بيانات ثانوي، والذي قد يحتوي على بيانات ذات جودة أو حداثة أقل مقارنة بالمصدر الأساسي. إذا كان مصدر البيانات الأساسي غير متاح أو أرجع خطأ، يمكن للنظام الرجوع إلى استرداد البيانات من هذا المصدر الثانوي، مما يضمن تقديم بعض أشكال المعلومات للمستخدم بدلاً من عرض رسالة خطأ. إعادة المحاولة إذا نظرت إلى الصورة أعلاه، فسوف تلاحظ تشابهًا بين المشكلة التي نواجهها الآن والمشكلة التي واجهناها مع مثال ذاكرة التخزين المؤقت. لحل هذه المشكلة، يمكننا التفكير في تنفيذ نمط يُعرف باسم إعادة المحاولة. فبدلاً من الاعتماد على ذاكرات التخزين المؤقت، يمكن تصميم النظام لإعادة إرسال الطلب تلقائيًا في حالة حدوث خطأ. يوفر نمط إعادة المحاولة هذا بديلاً أبسط ويمكنه تقليل احتمالية حدوث أخطاء في تطبيقنا بشكل فعال. وعلى عكس التخزين المؤقت، الذي يتطلب غالبًا آليات إبطال ذاكرة التخزين المؤقت المعقدة للتعامل مع تغييرات البيانات، فإن إعادة محاولة الطلبات الفاشلة أمر بسيط نسبيًا في التنفيذ. ونظرًا لأن إبطال ذاكرة التخزين المؤقت يُنظر إليه على نطاق واسع على أنه أحد أكثر المهام تحديًا في هندسة البرمجيات، فإن تبني استراتيجية إعادة المحاولة يمكن أن يبسط التعامل مع الأخطاء ويحسن مرونة النظام. قاطع الدائرة ومع ذلك، فإن اعتماد استراتيجية إعادة المحاولة دون النظر في العواقب المحتملة يمكن أن يؤدي إلى المزيد من المضاعفات. لنتخيل أن أحد واجهاتنا الخلفية تعرض لفشل. في مثل هذا السيناريو، قد يؤدي بدء إعادة المحاولة إلى الواجهة الخلفية الفاشلة إلى زيادة كبيرة في حجم حركة المرور. وقد يؤدي هذا الارتفاع المفاجئ في حركة المرور إلى إرهاق الواجهة الخلفية، مما يؤدي إلى تفاقم الفشل وقد يتسبب في تأثير متتالي عبر النظام. وللتغلب على هذا التحدي، من المهم استكمال نمط إعادة المحاولة بنمط قاطع الدائرة. يعمل قاطع الدائرة كآلية حماية تراقب معدل الخطأ في الخدمات اللاحقة. وعندما يتجاوز معدل الخطأ عتبة محددة مسبقًا، يقاطع قاطع الدائرة الطلبات المقدمة إلى الخدمة المتأثرة لمدة محددة. وخلال هذه الفترة، يمتنع النظام عن إرسال طلبات إضافية للسماح بوقت الخدمة الفاشلة للتعافي. وبعد الفاصل الزمني المحدد، يسمح قاطع الدائرة بحذر لعدد محدود من الطلبات بالمرور، للتحقق مما إذا كانت الخدمة قد استقرت. وإذا تعافت الخدمة، يتم استعادة حركة المرور الطبيعية تدريجيًا؛ وإلا، تظل الدائرة مفتوحة، وتستمر في حظر الطلبات حتى تستأنف الخدمة التشغيل الطبيعي. ومن خلال دمج نمط قاطع الدائرة جنبًا إلى جنب مع منطق إعادة المحاولة، يمكننا إدارة مواقف الخطأ بشكل فعال ومنع التحميل الزائد للنظام أثناء حالات فشل الواجهة الخلفية. اختتام وفي الختام، من خلال تنفيذ أنماط المرونة هذه، يمكننا تعزيز تطبيقاتنا ضد حالات الطوارئ، والحفاظ على توافر عالٍ، وتقديم تجربة سلسة للمستخدمين. بالإضافة إلى ذلك، أود التأكيد على أن القياس عن بعد هو أداة أخرى لا ينبغي إغفالها عند توفير مرونة المشروع. يمكن للسجلات والمقاييس الجيدة أن تعزز بشكل كبير جودة الخدمات وتوفر رؤى قيمة حول أدائها، مما يساعد في اتخاذ قرارات مستنيرة لتحسينها بشكل أكبر.