لماذا يتأخر فتح منفذ Node.js؟ تصميم بدء تشغيل لا يحبس الموقع وراء قاعدة البيانات وال ـ Prewarm

بعض التطبيقات تكون online لكنها لا تفتح منفذ HTTP إلا بعد سلسلة طويلة من تهيئة قاعدة البيانات وال ـCache. النتيجة أن Nginx يعيد 502 رغم عمل مدير العمليات. يشرح هذا المقال كيفية فصل التهيئة الضرورية عن مهام التسخين المسبق وكيفية تعريف جاهزية صحيحة من دون التضحية بسلامة البيانات.

الفرق بين بدء العملية وجاهزية الخدمة

عندما يظهر Node.js في قائمة العمليات لا يعني ذلك أنه بدأ الاستماع إلى HTTP. ربما أنشأ التطبيق الكائنات والجداول أولًا ثم انتظر اتصال قاعدة البيانات أو تهيئة Cache أو فحص إضافات. طالما لم يصل التنفيذ إلى server.listen لا يستطيع Nginx إرسال الطلبات إليه، وقد يرى المستخدم 502 رغم أن مدير العمليات يسجل الحالة online. افصل في سجل الإقلاع بين وقت بدء العملية ووقت نجاح اتصال الاعتماديات ووقت فتح المنفذ ووقت إعلان الجاهزية.

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

ثلاث طبقات للصحة بدلاً من endpoint واحد

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

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

نمط الإقلاع الذي يحبس المنفذ

يظهر النمط المربك عندما ينفذ التطبيق await Promise.all([connectDatabase(),prewarmHome(),loadArticles()]) ثم ينادي server.listen. فشل أي خطوة أو تأخرها قد يمنع فتح المنفذ كله. إذا كانت بعض الأعمال تجميلية أو هدفها تسريع أول صفحة، فينبغي ألا تتحول إلى اعتماد ضروري لكل مسارات الموقع. فصل الأعمال إلى critical و noncritical يتيح للخدمة أن تبدأ بعد أدنى مجموعة ضرورية، وتستكمل التهيئة الثانوية في الخلفية مع سجل أخطاء مستقل.

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

تخطيط Cache و Prewarm بصورة آمنة

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

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

قاعدة البيانات وتجهيز Pool قبل الاستماع

افحص عدد اتصالات pool لكل عملية وعدد النسخ العاملة. توصيل عشر نسخ في الوقت نفسه قد يرفع عدد الاتصالات فجأة حتى لو كانت قاعدة البيانات سليمة قبل النشر. استعمل حدودًا معلنة و timeout للاتصال الأولي، وسجل وقت المحاولة وعدد الإخفاقات. لا ترفع max_connections بمجرد رؤية رسالة timeout؛ ربما المشكلة ازدحام CPU أو swap أو مسار شبكة أو سر اعتماد غير صحيح.

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

تشغيل متدرج دون التضحية بالتعافي

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

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

مؤشرات يجب جمعها في كل نشر

اجمع أربعة أوقات: من بداية العملية إلى أول استماع، ومن الاستماع إلى readiness، ومن بدء النشر إلى تحويل المرور، ومن التحويل إلى استقرار الأخطاء. أضف نسبة فشل الاتصال بقاعدة البيانات وعدد الطلبات التي واجهت 502 خلال الفترة. هذه المقاييس تجعل الفارق واضحًا بين إصلاح تهيئة حقيقية وبين إخفاء بطئها بمضاعفة المهلة.

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

جدول مفاضلة وخطة اختبار

الحالات الأربع: انتظار جميع الاعتماديات قبل listen بسيط لكنه قد يجعل الموقع 502 أثناء بطء اعتماد ثانوي؛ فتح المنفذ فورًا يجعل قبول TCP ممكنًا لكنه يحتاج readiness تمنع توجيه مستخدم قبل الجاهزية؛ Prewarm في الخلفية يقلل زمن الإقلاع لكن يتطلب مراقبة تحديث الكاش؛ التشغيل المتدرج يقلل خطر التغيير لكنه يتطلب موارد وسعة. اختر مزيجًا يحقق صحة البيانات دون ربط مصير الخدمة بمهمة غير حرجة.

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

خطوات تنفيذ متدرجة

الخطوة الأولى أضف سجلًا مفصلًا لمراحل الإقلاع مع أزمنة ونتائج من دون أسرار. الثانية صنف كل اعتماد إلى ضروري وغير ضروري. الثالثة افصل Prewarm الثانوية واضبط التزامن. الرابعة أضف readiness يعكس القدرة على خدمة المسارات المهمة. الخامسة اختبر التحويل التدريجي أو خطة رجوع. السادسة راقب أخطاء 502 ونسبة الجاهزية وزمن إقلاع النسخ بعد كل إصدار.

راجع إرشادات Kubernetes حول liveness/readiness/startup probes على kubernetes.io، وتوثيق PostgreSQL لاتصالات قاعدة البيانات على postgresql.org، ووثائق Node.js HTTP server حول listen و close على nodejs.org. لا تحتاج Kubernetes لتنفيذ المفهوم؛ يمكنك تطبيق فصل الحيوية والجاهزية داخل Node.js خلف Nginx. المهم أن تكون الشروط قابلة للقياس ومتسقة مع طبيعة الخدمة.