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

دليل تحسين أداء Node.js

مقدمة

في 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 إلى:

كان تعزيز الأداء كبيرًا لدرجة أننا نعتبر الآن معالجات 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/router
  • @koa/multer
  • @ladjs/koa-simple-ratelimit اخترنا Koa بدلاً من Express لبنية الإنتاج الخاصة بنا في Node.js بسبب دعمه الحديث لـ async/await وتركيبه الأنظف للوسائط الوسيطة. ساهم مؤسسنا Nick Baugh في كل من Express و Koa، مما منحنا فهماً عميقاً لكلتا الإطارات لاستخدامها في الإنتاج.

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

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

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

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

أنشأنا ونحافظ على Bree لأن مجدولات الوظائف الموجودة لم تلبي احتياجاتنا لدعم خيوط العمل وميزات جافاسكريبت الحديثة في بيئات 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

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

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

Warning

تعمل هذه العوائق مع تكوين الأجهزة الخاص بنا. عند تنفيذ مراقبة Node.js في الإنتاج، راجع تنفيذ monitor-server.js لفهم المنطق الدقيق وتكييف القيم حسب إعدادك.

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

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

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

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

ينطبق هذا النمط على أي تطبيق Node.js - تطبيقات ويب، APIs، خدمات مصغرة، أو خدمات خلفية. تنفيذ التسجيل الخاص بنا: 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

لأفضل ممارسات نشر إنتاج Node.js، نطلب وقت تشغيل يزيد عن 15 دقيقة قبل اعتبار العملية صحية لتجنب حلقات إعادة التشغيل. هذا يمنع الفشل المتسلسل عندما تواجه العمليات مشاكل في الذاكرة أو غيرها.

تكوين إنتاج 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

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

نهجنا في التحليل لتطبيقات Node.js في الإنتاج

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

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

Tip

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

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

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

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

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

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

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

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

لتحليل لقطات الذاكرة المؤقتة:

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

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

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

Warning

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

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

تتكامل أدوات التحليل لدينا مع استراتيجيتنا الأوسع للمراقبة:

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

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

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

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

تنفيذ Ansible الخاص بنا: ansible/playbooks/security.yml

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

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

Warning

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

أمان التطبيق لتطبيقات 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

ما نستخدمه:

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

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

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

Note

نهجنا الهجين يُحسّن لحالة الاستخدام الخاصة بنا. ادرس أنماط استخدام قاعدة البيانات الفعلية في قاعدة الشيفرة لفهم ما إذا كان هذا النهج يناسب احتياجات تطبيق 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

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

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

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

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

دراسات حالة المؤسسات لدينا