كيفية تحسين البنية التحتية لإنتاج 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 إلى:

  • تحسّن الأداء بنسبة ٥٧٣٪ في معالجة الطلبات (موثّق في صفحة حالة 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
  • كفاءة مساحة القرص من خلال الربط الثابت
  • حل دقيق للتبعيات يمنع التبعيات الوهمية
  • أداء أفضل في عمليات النشر الإنتاجية

كجزء من أفضل ممارسات نشر 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

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

  • حد أقصى لحجم الكومة ٢ غيغابايت مع تنبيهات تلقائية
  • حد تحذير استخدام الذاكرة ٢٥٪
  • حد تحذير استخدام وحدة المعالجة المركزية ٨٠٪
  • حد تحذير استخدام القرص ٧٥٪

Warning

تعمل هذه الحدود مع إعدادات أجهزتنا المحددة. عند تنفيذ مراقبة إنتاج 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 ما يلي:

  • يعمل كل ٢٠ دقيقة عبر جدولة المهام الدورية
  • يتطلب ١٥ دقيقة تشغيل كحد أدنى قبل اعتبار العملية سليمة
  • يتحقق من حالة العملية واستخدام الذاكرة
  • يعيد تشغيل العمليات الفاشلة تلقائيًا
  • يمنع تكرار إعادة التشغيل من خلال فحص الحالة الذكي

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

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

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

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

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

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

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

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

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

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

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

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

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

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

١. تثبيت v8-profiler-next لإنشاء اللقطات. ٢. استخدام cpupro لتحليل اللقطات المُولّدة. ٣. تنفيذ عتبات مراقبة مشابهة لملف monitor-server.js. ٤. إعداد التنظيف التلقائي لإدارة تخزين اللقطات. ٥. إنشاء معالجات إشارات لإنشاء ملفات تعريف عند الطلب في بيئة الإنتاج.

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

١. إنشاء ملفات تعريف وحدة المعالجة المركزية خلال فترات التحميل العالي ٢. التحليل باستخدام cpupro لتحديد الاختناقات ٣. التركيز على المسارات الساخنة وفرص التحسين ٤. مراقبة تحسينات الأداء قبل/بعد

Warning

قد يؤثر إنشاء لقطات كومة الذاكرة المؤقتة وملفات تعريف وحدة المعالجة المركزية (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 الخاصة بنا لأنها توفر:

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

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
  • منطق معالجة الأخطاء وإعادة المحاولة
  • كيف نستخدم خيوط العمل العاملة للمهام التي تتطلب الكثير من وحدة المعالجة المركزية (CPU)

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

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

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

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

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

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

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

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

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

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

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

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

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

دراسة الكود الفعلي لدينا لأفضل ممارسات الإنتاج

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

١. التكوين: config/index.js ٢. المراقبة: helpers/monitor-server.js ٣. معالجة الأخطاء: helpers/is-code-bug.js ٤. التسجيل: helpers/logger.js ٥. حالة العملية: 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

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

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

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

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

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