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

لكن ما هي قابلية التوسع فى البرمجيات؟

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

إذن ، كيف يمكننا بناء تطبيقات عالية الأداء؟

يعد التفكير في الأداء منذ البداية طريقة رائعة للتأكد من أنك لا تجد نفسك في منتصف الطريق الصعب. بعض الأسئلة التي يجب أن تطرحها في هذه المرحلة هي:

1) ما هو مقدار الجهد الذي تريد أن تبذله لتحسين الأداء؟

2) ما هي الوظائف الأكثر استخدامًا؟

3) ما هي أكثر المهام كثافة في استخدام الموارد؟

هذه هى بعض الأجراءات التى نتبعها لمراقبه الأداء و تحسينه

التخزين المؤقت أو الكاش

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

يمكن أن يؤدي تنفيذ ذاكرة التخزين المؤقت إلى تقليل الحمل على قاعدة البيانات بشكل كبير ، إذا كان التطبيق يقوم بنفس الاستعلامات مرارًا وتكرارًا. هناك أنواع مختلفة من ذاكرات التخزين المؤقت ، على سبيل المثال ، يمكن استخدام ذاكرة تخزين مؤقت وكيل وخدمة طلبات HTTP الشائعة حتى بدون لمس خادم التطبيق أصلا.

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

أثناء العمل على CMS مخصص لموقع ويب حصل على أكثر من مليون زائر يوميًا ،يمكن لذاكرة تخزين مؤقتة بسيطة للوكيل خفض حمل وحدة المعالجة المركزية من 70٪ إلى 10٪. لذا ، فكر في خطة التخزين المؤقت أثناء تصميم التطبيق وسترى بالتأكيد الكثير من التحسينات.

الأعمال الغير متزامنه و الأعمال فى الخلفية .

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

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

بناء معماري منفصل

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

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

بناء خدمات مستقله

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

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

بناء أنظمة تتسامح مع الأخطاء

نعلم أن  الأمور قد تسوء. من المهم الاعتقاد بأن كل جزء من النظام قد  يفشل . هذا ه يجبرنا على التفكير في الخطوات التي يمكن اتخاذها للتخفيف من المشكلة قدر الإمكان. نحن نسأل أنفسنا :

ما مقدار وقت التعطل الذي يمكن للتطبيق تحمله؟

سيكون هذا مختلفًا لكل تطبيق. يمكن لنظام مثل cloudflare الذي يجلس أمام ملايين التطبيقات أن يتحمل القليل جدًا (إن وجد) من وقت التوقف ، ومن ناحية أخرى ، يمكن للمدونة تحمل الكثير.

ما الأضرار الخطيره التى يمكن أن تحدث؟

ماذا يحدث إذا فشلت قاعدة البيانات الخاصة ؟ هل توجد نسخ احتياطية؟ كم عدد النسخ؟ متى تم أخذ آخر نسخة احتياطية؟ هل يمكنك تحمل فقدان البيانات التي تم إنشاؤها / تحديثها بعد تلك النقطة؟ ماذا يحدث إذا فشل خادم النسخ الاحتياطي؟ هل توجد نسخ احتياطية على خوادم متعددة؟

التسامح مع الخطأ له ثمن. علينا أن تقرر مقدار التكلفة التي يمكنك تحملها بناءً على القيمة. 

هذه ليست بأي حال من الأحوال قائمة كاملة. و لكنها تبين لك الخطوات المنهجيه المتبعه لبناء نظم قابله للتوسع و التطور.

إلى أي مدى تريد أن يكون النظام قابلاً للتطوير؟

قابلية التوسع لها ثمن ، فهي تستغرق وقتًا وجهدًا. إذا كنت تقوم فقط ببناء نموذج أولي ، فليس هناك (على الأرجح) أي جدوى من جعله قابلاً للتطوير حتى مليون مستخدم. مثلا تمت إعادة كتابة معظم التطبيقات مثل facebook أو twitter عدة مرات.

 عنجما نبنى نظام لعميل و فى حاله كان هذا ضروريا فنحن نخبره أن هذا سيضاف إلى تكلفة المشروع.  دائما هناك فرق كبير في تكلفة النظام الذي يمكن أن يخدم 100 مستخدم في الوقت الفعلي مقابل واحد يمكن أن يخدم مليون مستخدم.

النظام القابل للتطوير هو النظام الذي يحافظ على الأداء الجيد حتى مع زيادة عدد المستخدمين. قد يتضمن ذلك إضافة / إزالة الخوادم بناءً على حركة المرور. الخطوة الأولى لذلك هي معرفة متى يتم القياس.

بناء أبراج مراقبة

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

استخدام موازين التحميل

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

تكلفة قابلية التوسع

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

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