توسيع النطاق والتوسع التلقائي لتطبيق Node.js

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

مكان وجود التوسع في KPanel

1. سجّل الدخول إلى KPanel.
2. انقر على Websites في الشريط الجانبي الأيسر، ثم انقر على الموقع.
3. في شريط علامات التبويب الخاص بالموقع، افتح Advanced، ثم Scaling.

العنوان المباشر هو /websites/<site-id>/autoscale. العنوان الأقدم /websites/<site-id>/scaling لا يزال يعمل ويوجهك إلى نفس المكان.

علامة تبويب واحدة، إعداد واحد

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

كيفية عمله

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

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

قراءة الحالة الحية

بطاقة الحالة تظهر ثلاثة أشياء:

• Instances: كم عدد الحالات التي تعمل الآن.
• Avg CPU: متوسط CPU عبر تلك الحالات.
• Cluster: ما إذا كان التطبيق في وضع المجموعة. إذا قال لا، فإن تفعيل التوسع التلقائي سيحوله.

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

تظهر علامة التبويب أيضًا Last scale، وقت حدث التوسع الأخير، أو never.

الإعدادات

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

قيم البدء المعقولة:

• Min instances 1 أو 2. اثنان إذا لم تتمكن من تحمل إعادة تشغيل حالة واحدة وضع التطبيق في وضع عدم الاتصال.
• Max instances على ما أنت على استعداد لدفعه في الذروة، وليس في الحد الأقصى.
• Scale up حول 70 في المئة. عالي بما يكفي بحيث لا تدفع مقابل المساحة الفارغة التي لا تستخدمها أبدًا، منخفض بما يكفي بحيث يكون هناك وقت لإضافة السعة قبل أن تبدأ الطلبات في الانتظار.
• Scale down حول 30 في المئة. اترك فجوة واسعة بين الحدين.
• Cooldown لبضع دقائق. هذا هو الإعداد الأكثر تقليلاً للتقدير.

أحداث التوسع

تسرد علامة التبويب أحداث التوسع الأخيرة، الأحدث أولاً، كل منها يظهر الاتجاه وعدد الحالات قبل وبعد وقراءة CPU التي أثارتها والوقت.

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

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

الحالات فوق تخصيص الخطة الأساسي تُقاس وتُفوَّت بالثانية. تظهر علامة التبويب للفترة الحالية:

• Instance-time used، بالساعات والدقائق، مع ثوان الحالات الخام تحتها.
• Spent so far في هذه الفترة.
• Projected month-end، مستقرأ من الاستخدام حتى الآن.
• Tracking، كم عدد نوافذ الاستخدام التي تمت فوترتها من إجمالي المسجلة.
• Period progress، الأيام المنقضية من أيام في الشهر.

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

خفض إلى الحد الأدنى يوقف القياس. إذا أيقفت التوسع التلقائي تماماً، يبقى التطبيق على أي عدد حالات لديه حاليًا، لذلك أسقطها إلى الحد الأدنى أولاً إذا كانت التكلفة هي السبب في الذي تُطفئه.

جعل تطبيق آمن للتوسع

تحمل الصفحة تحذيرًا، وهو الشيء الأكثر أهمية عليها: تطبيق Node.js الخاص بك يجب أن يكون آمنًا للمجموعة للتوسع بشكل نظيف عبر الحالات.

من الناحية العملية هذا يعني:

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

لا ذاكرة تخزين مؤقت في الذاكرة تعتمد عليها للصحة. كل حالة لها خاصة بها. ذاكرة تخزين مؤقت يجب أن تكون متسقة يجب أن تكون مشتركة.

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

لا عمل مجدول غير محمي. إذا كان موقت يعمل داخل التطبيق، كل حالة تعمله، لذلك وظيفة ليلية على أربع حالات تعمل أربع مرات. انقل العمل المجدول إلى وظيفة cron أو احمِ به بحفل. انظر Cron Jobs.

لا افتراض بأن عدد الحالات مستقر. أي شيء يقسم العمل حسب فهرس الحالة ينقطع لحظة تتغير العداد.

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

استكشاف الأخطاء وإصلاحها

الزر لن يتفعل. التفعيل يحتاج إلى إذن كتابة الموقع. مع دور القراءة فقط تكون الضوابط معطلة.

تم إعادة تشغيل التطبيق عندما قمت بتفعيل التوسع التلقائي. متوقع. التبديل إلى وضع المجموعة يتطلب إعادة تشغيل، وهي تحدث مرة واحدة.

المستخدمون يتم تسجيل خروجهم عشوائيًا. أعراض كلاسيكية غير آمنة للمجموعة. الجلسات في الذاكرة والطلبات تهبط على حالات مختلفة.

الحالات توسعت ولم تعد أبدًا. إما أن الحمل بقي فوق حد scale-down أو شيء ما يرفع CPU بشكل مستقل عن حركة المرور. تحقق من قائمة الأحداث وانظر إلى ما يفعله التطبيق بالفعل.

وظيفة مجدولة أعدمت عدة مرات. كل حالة أعدمتها. انقلها إلى وظيفة cron أو أضف قفل.

لا شيء يتوسع. تأكد من أن الزر قيد التشغيل والتطبيق يعمل ووضع المجموعة ممكّن. ثم تحقق ما إذا عبر CPU بالفعل حد scale-up في قائمة الأحداث.

التكلفة أعلى من المتوقع. انظر إلى قائمة الأحداث للبحث عن flapping، ثم قلل عدد الحالات الأقصى.

الصفحات ذات الصلة

• Site Performance and APM لمعرفة ما إذا كان CPU هو اختناق حقيقي.
• Site Uptime Monitoring لتأكيد أن التوسع يحسن القدرة فعلاً.
• Cron Jobs للعمل المجدول الذي يجب أن ينفذ مرة واحدة بالضبط.
• Resizing a Cloud Server إذا كنت بحاجة إلى جهاز أكبر بدلاً من المزيد من الحالات.