كيفية تحسين البنية التحتية لإنتاج Node.js: أفضل الممارسات في 2025

أفضل ممارسات نشر إنتاج Node.js من البنية الأساسية التي تم اختبارها والتي تتعامل مع ملايين الطلبات يوميًا.

Forward Email الفريق
كتب بواسطة
Forward Email الفريقVerified
نشرت
6/1/25
وقت القراءة
أقل من 5 دقائق

في Forward Email، أمضينا سنوات في إتقان إعداد بيئة إنتاج Node.js. يستعرض هذا الدليل الشامل أفضل ممارساتنا المجربة لنشر Node.js في بيئة الإنتاج، مع التركيز على تحسين الأداء والمراقبة والدروس المستفادة من توسيع نطاق تطبيقات Node.js للتعامل مع ملايين المعاملات اليومية.

ثورة تحسين أداء النواة الواحدة بنسبة 573%

عندما انتقلنا من معالجات Intel إلى معالجات AMD Ryzen، حققنا تحسن الأداء بنسبة 573% في تطبيقات Node.js الخاصة بنا. لم يكن هذا مجرد تحسين بسيط، بل غيّر جذريًا أداء تطبيقات Node.js في الإنتاج، ويُظهر أهمية تحسين أداء النواة الواحدة لأي تطبيق Node.js.

[!TIP]

لأفضل ممارسات نشر Node.js في بيئة الإنتاج، يُعد اختيار الأجهزة أمرًا بالغ الأهمية. اخترنا تحديدًا استضافة DataPacket لمعالجات AMD Ryzen المتوفرة لدينا، لأن أداء النواة الواحدة أساسي لتطبيقات Node.js، نظرًا لأن تنفيذ JavaScript يتم عبر خيط واحد.

لماذا يُعد تحسين أداء النواة الفردية أمرًا مهمًا بالنسبة إلى Node.js

لقد أدى انتقالنا من Intel إلى AMD Ryzen إلى:

  • تحسن الأداء بنسبة 573% في معالجة الطلب (موثق في صفحة حالتنا على GitHub العدد #1519)
  • تم القضاء على تأخيرات المعالجة إلى استجابات شبه فورية (مذكورة في إصدار GitHub رقم 298)
  • نسبة سعر إلى أداء أفضل لبيئات إنتاج Node.js
  • تحسين أوقات الاستجابة عبر جميع نقاط نهاية تطبيقاتنا

كان تعزيز الأداء كبيرًا جدًا لدرجة أننا نعتبر الآن معالجات AMD Ryzen ضرورية لأي نشر إنتاجي جاد لـ Node.js، سواء كنت تقوم بتشغيل تطبيقات الويب أو واجهات برمجة التطبيقات أو الخدمات المصغرة أو أي عبء عمل آخر لـ Node.js.

محتوى ذو صلة

لمزيد من التفاصيل حول خيارات البنية التحتية لدينا، راجع:

إعداد بيئة إنتاج Node.js: مجموعة التكنولوجيا الخاصة بنا

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

مدير الحزم: pnpm لكفاءة الإنتاج

ما نستخدمه: pnpm (النسخة المثبتة)

لقد اخترنا pnpm بدلاً من npm وyarn لإعداد بيئة إنتاج Node.js الخاصة بنا للأسباب التالية:

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

[!NOTE] كجزء من أفضل ممارساتنا لنشر Node.js في الإنتاج، نُثبّت إصدارات دقيقة من الأدوات المهمة مثل pnpm لضمان اتساق الأداء في جميع البيئات وأجهزة أعضاء الفريق.

تفاصيل التنفيذ:

إطار عمل الويب: Koa لإنتاج Node.js الحديث

ما نستخدمه:

اخترنا Koa بدلاً من Express لبنية Node.js الإنتاجية بفضل دعمه الحديث لـ async/await وتركيبته الأنظف للبرامج الوسيطة. ساهم مؤسسنا، نيك باو، في كلٍّ من Express وKoa، مما منحنا فهمًا عميقًا لكلا الإطارين للاستخدام الإنتاجي.

تنطبق هذه الأنماط سواء كنت تقوم ببناء واجهات برمجة تطبيقات REST، أو خوادم GraphQL، أو تطبيقات الويب، أو الخدمات المصغرة.

أمثلة التنفيذ لدينا:

معالجة الوظائف الخلفية: Bree لضمان موثوقية الإنتاج

ما نستخدمه: bree المجدول

لقد أنشأنا Bree وصيانته لأن مُجدولات المهام الحالية لم تُلبِّ احتياجاتنا لدعم خيوط العمل وميزات JavaScript الحديثة في بيئات Node.js الإنتاجية. ينطبق هذا على أي تطبيق Node.js يحتاج إلى معالجة خلفية، أو مهام مجدولة، أو خيوط عمل.

أمثلة التنفيذ لدينا:

معالجة الأخطاء: @hapi/boom لموثوقية الإنتاج

ما نستخدمه: @hapi/boom

نستخدم @hapi/boom لاستجابات منظمة للأخطاء في جميع تطبيقات Node.js الإنتاجية. ينطبق هذا النمط على أي تطبيق Node.js يتطلب معالجة متسقة للأخطاء.

أمثلة التنفيذ لدينا:

كيفية مراقبة تطبيقات Node.js في الإنتاج

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

مراقبة إنتاج Node.js على مستوى النظام

تنفيذنا الأساسي: helpers/monitor-server.js

ما نستخدمه: node-os-utils

عتبات مراقبة الإنتاج لدينا (من رمز الإنتاج الفعلي لدينا):

  • حد حجم الكومة 2 جيجابايت مع التنبيهات التلقائية
  • 25% من استخدام الذاكرة عتبة التحذير
  • 80% من استخدام وحدة المعالجة المركزية عتبة التنبيه
  • 75% من استخدام القرص عتبة التحذير

[!تحذير] تتناسب هذه الحدود مع إعدادات أجهزتنا المحددة. عند تنفيذ مراقبة إنتاج Node.js، يُرجى مراجعة تنفيذ monitor-server.js لفهم المنطق الدقيق وتعديل القيم بما يتناسب مع إعداداتك.

مراقبة مستوى التطبيق لإنتاج Node.js

تصنيف الخطأ لدينا: helpers/is-code-bug.js

يميز هذا المساعد بين:

  • أخطاء الكود الفعلية التي تتطلب اهتماما فوريا
  • أخطاء المستخدم وهذا هو السلوك المتوقع
  • فشل الخدمة الخارجية أننا لا نستطيع السيطرة عليها

ينطبق هذا النمط على أي تطبيق Node.js - تطبيقات الويب، أو واجهات برمجة التطبيقات، أو الخدمات المصغرة، أو الخدمات الخلفية.

تنفيذ التسجيل لدينا: helpers/logger.js

نحن ننفذ عملية تحرير شاملة للحقول لحماية المعلومات الحساسة مع الحفاظ على قدرات التصحيح المفيدة في بيئة إنتاج Node.js الخاصة بنا.

مراقبة خاصة بالتطبيق

تنفيذات الخادم لدينا:

مراقبة قائمة الانتظار: نُطبّق حدودًا لطوابير الانتظار تبلغ 5 جيجابايت، وفترة انتظار مدتها 180 ثانية لمعالجة الطلبات، وذلك لمنع استنفاد الموارد. تُطبّق هذه الأنماط على أي تطبيق Node.js يحتوي على طوابير انتظار أو معالجة خلفية.

مراقبة إنتاج Node.js باستخدام فحوصات صحة PM2

لقد حسّنا بيئة إنتاج Node.js لدينا باستخدام PM2 على مر سنوات من الخبرة في الإنتاج. تُعد فحوصات PM2 الخاصة بنا ضرورية للحفاظ على موثوقية أي تطبيق Node.js.

نظام فحص صحة PM2 الخاص بنا

تنفيذنا الأساسي: jobs/check-pm2.js

تتضمن مراقبة إنتاج Node.js لدينا مع فحوصات صحة PM2 ما يلي:

  • يتم تشغيله كل 20 دقيقة عبر جدولة cron
  • يتطلب الحد الأدنى من وقت التشغيل 15 دقيقة قبل النظر في عملية صحية
  • التحقق من صحة حالة العملية واستخدام الذاكرة
  • إعادة تشغيل العمليات الفاشلة تلقائيًا
  • يمنع حلقات إعادة التشغيل من خلال الفحص الصحي الذكي

[!CAUTION] For Node.js production deployment best practices, we require 15+ minutes uptime before considering a process healthy to avoid restart loops. This prevents cascading failures when processes are struggling with memory or other issues.

تكوين إنتاج PM2 الخاص بنا

إعداد النظام البيئي الخاص بنا: قم بدراسة ملفات بدء تشغيل الخادم الخاصة بنا لإعداد بيئة إنتاج Node.js:

تنطبق هذه الأنماط سواء كنت تقوم بتشغيل تطبيقات Express أو خوادم Koa أو واجهات برمجة تطبيقات GraphQL أو أي تطبيق Node.js آخر.

النشر الآلي لـ PM2

نشر PM2: ansible/playbooks/node.yml

نحن نقوم بأتمتة عملية إعداد PM2 بالكامل من خلال Ansible لضمان نشر إنتاج Node.js بشكل متسق عبر جميع خوادمنا.

نظام معالجة أخطاء الإنتاج وتصنيفها

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

تنفيذنا لـ isCodeBug للإنتاج

مصدر: helpers/is-code-bug.js

يوفر هذا المساعد تصنيفًا ذكيًا للأخطاء لتطبيقات Node.js في الإنتاج من أجل:

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

ينطبق هذا النمط على أي تطبيق Node.js - سواء كنت تقوم ببناء مواقع التجارة الإلكترونية أو منصات SaaS أو واجهات برمجة التطبيقات أو الخدمات المصغرة.

التكامل مع تسجيل الإنتاج لدينا

تكامل المسجل لدينا: helpers/logger.js

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

محتوى ذو صلة

تعرف على المزيد حول أنماط معالجة الأخطاء لدينا:

تصحيح أخطاء الأداء المتقدم باستخدام v8-profiler-next وcpupro

نستخدم أدوات تحليل بيانات متقدمة لتحليل لقطات الكومة وتصحيح مشاكل نفاد الذاكرة (OOM)، واختناقات الأداء، ومشاكل ذاكرة Node.js في بيئة الإنتاج لدينا. تُعد هذه الأدوات أساسية لأي تطبيق Node.js يواجه تسريبات في الذاكرة أو مشاكل في الأداء.

نهجنا في إنشاء ملفات تعريف لإنتاج Node.js

الأدوات التي نوصي بها:

  • v8-profiler-next - لإنشاء لقطات الكومة وملفات تعريف وحدة المعالجة المركزية
  • cpupro - لتحليل ملفات تعريف وحدة المعالجة المركزية ولقطات الكومة

[نصيحة!] نستخدم v8-profiler-next وcpupro معًا لإنشاء سير عمل متكامل لتصحيح أخطاء الأداء لتطبيقات Node.js. يساعدنا هذا المزيج في تحديد تسريبات الذاكرة، واختناقات الأداء، وتحسين شيفرة الإنتاج.

كيفية تنفيذ تحليل لقطة الكومة

تنفيذ المراقبة لدينا: helpers/monitor-server.js

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

أنماط التنفيذ الرئيسية:

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

سير عمل تصحيح أخطاء الأداء

دراسة تنفيذنا الفعلي:

لتحليل لقطة الكومة:

  1. تثبيت v8-profiler-next لتوليد اللقطات
  2. استخدم cpupro لتحليل اللقطات المولدة
  3. تنفيذ عتبات المراقبة مشابه لـ monitor-server.js الخاص بنا
  4. إعداد التنظيف التلقائي لإدارة تخزين اللقطات
  5. إنشاء معالجات الإشارة لإنشاء ملفات تعريف حسب الطلب في الإنتاج

لإعداد ملف تعريف وحدة المعالجة المركزية:

  1. إنشاء ملفات تعريف وحدة المعالجة المركزية خلال فترات التحميل العالي
  2. تحليل باستخدام cpupro لتحديد الاختناقات
  3. التركيز على المسارات الساخنة وفرص التحسين
  4. مراقبة قبل/بعد تحسينات الأداء

[!تحذير] قد يؤثر إنشاء لقطات كومة الذاكرة المؤقتة وملفات تعريف وحدة المعالجة المركزية (CPU) على الأداء. نوصي بتطبيق نظام تقييد السرعة وتفعيل ملفات التعريف فقط عند التحقق من مشاكل محددة أو أثناء فترات الصيانة.

التكامل مع مراقبة الإنتاج لدينا

تتكامل أدوات تحديد الملفات الشخصية لدينا مع استراتيجية المراقبة الأوسع نطاقًا لدينا:

  • التشغيل التلقائي بناءً على عتبات الذاكرة/وحدة المعالجة المركزية
  • تكامل التنبيهات عندما يتم اكتشاف مشاكل في الأداء
  • التحليل التاريخي لتتبع اتجاهات الأداء بمرور الوقت
  • الارتباط بمقاييس التطبيق للتصحيح الشامل

لقد ساعدنا هذا النهج في تحديد تسريبات الذاكرة وحلها، وتحسين مسارات التعليمات البرمجية الساخنة، والحفاظ على الأداء المستقر في بيئة إنتاج Node.js الخاصة بنا.

أمان البنية التحتية لإنتاج Node.js

نُطبّق أمانًا شاملًا لبنية إنتاج Node.js التحتية من خلال أتمتة Ansible. تُطبّق هذه الممارسات على أي تطبيق Node.js:

الأمان على مستوى النظام لإنتاج Node.js

تنفيذنا لـ Ansible: ansible/playbooks/security.yml

إجراءاتنا الأمنية الرئيسية لبيئات إنتاج Node.js:

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

[!تحذير] عند تطبيق أفضل ممارسات نشر Node.js في بيئة الإنتاج، قد يؤدي تعطيل التبديل إلى إيقاف تشغيل التطبيقات بسبب نفاد الذاكرة إذا تجاوز تطبيقك سعة ذاكرة الوصول العشوائي (RAM) المتاحة. نراقب استخدام الذاكرة بعناية ونحدد حجم خوادمنا بشكل مناسب.

أمان التطبيقات لتطبيقات Node.js

تحرير حقل السجل الخاص بنا: helpers/logger.js

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

أتمتة أمن البنية التحتية

إعدادنا الكامل لـ Ansible لإنتاج Node.js:

محتوى الأمان الخاص بنا

تعرف على المزيد حول نهجنا الأمني:

هندسة قواعد البيانات لتطبيقات Node.js

نستخدم نهج قاعدة بيانات هجينة مُحسّن لتطبيقات Node.js. يمكن تكييف هذه الأنماط مع أي تطبيق Node.js:

تنفيذ SQLite لإنتاج Node.js

ما نستخدمه:

تكويننا: ansible/playbooks/sqlite.yml

نحن نستخدم SQLite للبيانات الخاصة بالمستخدم في تطبيقات Node.js الخاصة بنا لأنه يوفر:

  • عزل البيانات لكل مستخدم/مستأجر
  • أداء أفضل لاستعلامات المستخدم الفردي
  • النسخ الاحتياطي المبسط والهجرة
  • تقليل التعقيد مقارنة بقواعد البيانات المشتركة

يعمل هذا النمط بشكل جيد لتطبيقات SaaS أو الأنظمة متعددة المستأجرين أو أي تطبيق Node.js يحتاج إلى عزل البيانات.

تنفيذ MongoDB لإنتاج Node.js

ما نستخدمه:

تنفيذ الإعداد لدينا: helpers/setup-mongoose.js

تكويننا: config/mongoose.js

نحن نستخدم MongoDB لبيانات التطبيق في بيئة إنتاج Node.js الخاصة بنا لأنها توفر:

  • مخطط مرن لتطوير هياكل البيانات
  • أداء أفضل للاستعلامات المعقدة
  • القياس الأفقي القدرات
  • لغة الاستعلام الغنية

[ملاحظة!] نهجنا الهجين يُحسّن استخدامنا المُحدد. ادرس أنماط استخدام قاعدة البيانات الفعلية في قاعدة الكود لفهم ما إذا كان هذا النهج يُناسب احتياجات تطبيق Node.js الخاص بك.

معالجة وظيفة الخلفية الإنتاجية في Node.js

لقد بنينا بنية وظائف الخلفية لدينا حول Bree لضمان نشر Node.js الإنتاجي بشكل موثوق. ينطبق هذا على أي تطبيق Node.js يحتاج إلى معالجة خلفية:

إعداد خادم Bree الخاص بنا للإنتاج

تنفيذنا الرئيسي: bree.js

نشر Ansible الخاص بنا: ansible/playbooks/bree.yml

أمثلة على وظائف الإنتاج

مراقبة الصحة: jobs/check-pm2.js

أتمتة التنظيف: jobs/cleanup-tmp.js

جميع وظائفنا: تصفح دليل الوظائف الكامل لدينا

تنطبق هذه الأنماط على أي تطبيق Node.js يحتاج إلى:

  • المهام المجدولة (معالجة البيانات، التقارير، التنظيف)
  • معالجة الخلفية (تغيير حجم الصورة، إرسال البريد الإلكتروني، استيراد البيانات)
  • مراقبة الصحة وصيانتها
  • استخدام خيط العامل للمهام التي تتطلب وحدة معالجة مركزية مكثفة

أنماط جدولة الوظائف الخاصة بنا لإنتاج Node.js

قم بدراسة أنماط جدولة الوظائف الفعلية لدينا في دليل الوظائف الخاص بنا لفهم:

  • كيف ننفذ جدولة شبيهة بـ cron في إنتاج Node.js
  • منطق معالجة الأخطاء وإعادة المحاولة لدينا
  • كيف نستخدم خيوط العمل للمهام التي تتطلب وحدة معالجة مركزية مكثفة

الصيانة الآلية لتطبيقات Node.js الإنتاجية

نطبق صيانة استباقية لمنع مشاكل إنتاج Node.js الشائعة. تنطبق هذه الأنماط على أي تطبيق Node.js:

تنفيذ عملية التنظيف لدينا

مصدر: jobs/cleanup-tmp.js

تستهدف صيانتنا الآلية لتطبيقات إنتاج Node.js ما يلي:

  • الملفات المؤقتة أكبر من 24 ساعة
  • ملفات السجل خارج حدود الاحتفاظ
  • ملفات التخزين المؤقت والبيانات المؤقتة
  • الملفات التي تم تحميلها التي لم تعد هناك حاجة إليها
  • لقطات الكومة من تصحيح الأداء

تنطبق هذه الأنماط على أي تطبيق Node.js يقوم بإنشاء ملفات مؤقتة أو سجلات أو بيانات مخزنة مؤقتًا.

إدارة مساحة القرص لإنتاج Node.js

عتبات المراقبة لدينا: helpers/monitor-server.js

  • حدود قائمة الانتظار لمعالجة الخلفية
  • 75% من استخدام القرص عتبة التحذير
  • التنظيف التلقائي عندما يتم تجاوز الحدود

أتمتة صيانة البنية التحتية

أتمتة Ansible الخاصة بنا لإنتاج Node.js:

دليل تنفيذ نشر Node.js الإنتاجي

قم بدراسة الكود الفعلي الخاص بنا للحصول على أفضل ممارسات الإنتاج

ابدأ بهذه الملفات الرئيسية لإعداد بيئة إنتاج Node.js:

  1. إعدادات: config/index.js
  2. يراقب: helpers/monitor-server.js
  3. معالجة الأخطاء: helpers/is-code-bug.js
  4. التسجيل: helpers/logger.js
  5. صحة العملية: jobs/check-pm2.js

تعلم من منشورات مدونتنا

أدلة التنفيذ الفنية الخاصة بنا لإنتاج Node.js:

أتمتة البنية التحتية لإنتاج Node.js

كتيبات Ansible التي يجب دراستها لنشر Node.js في الإنتاج:

دراسات الحالة الخاصة بنا

تنفيذات مؤسستنا:

الاستنتاج: أفضل ممارسات نشر إنتاج Node.js

تُظهر البنية الأساسية لإنتاج Node.js أن تطبيقات Node.js يمكنها تحقيق موثوقية على مستوى المؤسسة من خلال:

  • اختيارات الأجهزة المثبتة (AMD Ryzen لتحسين أداء النواة الواحدة بنسبة 573٪)
  • مراقبة إنتاج Node.js التي تم اختبارها في المعركة مع عتبات محددة واستجابات آلية
  • تصنيف الأخطاء الذكية لتحسين الاستجابة للحوادث في بيئات الإنتاج
  • تصحيح أخطاء الأداء المتقدم مع v8-profiler-next وcpupro لمنع OOM
  • تعزيز الأمن الشامل من خلال أتمتة Ansible
  • هندسة قاعدة البيانات الهجينة مُحسّن لتلبية احتياجات التطبيق
  • الصيانة الآلية لمنع مشاكل إنتاج Node.js الشائعة

النقطة الرئيسية: ادرس ملفات التنفيذ الفعلية ومنشورات مدونتنا بدلاً من اتباع أفضل الممارسات العامة. توفر قاعدة بياناتنا أنماطًا عملية لنشر Node.js في بيئة الإنتاج، قابلة للتكيف مع أي تطبيق Node.js - تطبيقات الويب، واجهات برمجة التطبيقات، الخدمات المصغرة، أو الخدمات الخلفية.

قائمة الموارد الكاملة لإنتاج Node.js

ملفات التنفيذ الأساسية لدينا

تنفيذات الخادم لدينا

أتمتة البنية التحتية لدينا

منشورات مدونتنا التقنية

دراسات الحالة الخاصة بمؤسستنا