تعمل Node.js بالفعل بنجاح على نطاق عالمي ، كما يتضح من التطبيقات المنشورة عليها لشركات مثل Netflix و Reddit و Walmart و Ebay. ومع ذلك ، لديها مجموعة من المشاكل الخاصة بها عند القياس ؛ من وجهة نظر الأشخاص الذين يعملون على أساس كود واحد ، لذلك من وجهة نظر التحجيم الرأسي والأفقي في السحابة. بالإضافة إلى تجربتي الشخصية مع توسيع Node.js لشركات مثل Reddit و Netflix ، تحدثت مع بعض الخبراء في Microsoft Azure وخرجت ببعض النصائح لك حول توسيع Node.js لشركتك.
اكتب Node.js عالي الجودة
كلما بدأت استخدام أدوات التنظيف وتنسيق واكتشاف النوع في التعليمات البرمجية ، كلما كان ذلك أفضل.
يمكن أن تكون هذه الأشياء صعبة في تقديمها في منتصف المشروع نظرًا لكمية كبيرة محتملة من إعادة الهيكلة التي قد تكون مطلوبة ، ويمكن أيضًا تلويث سجل git الخاص بك ، ولكن في النهاية ستساعدك هذه الأدوات في جعل الشفرة قابلة للقراءة.
إذا كنت لا تزال لا تستخدمها ،
فقم بتوجيه عينيك على
الفور إلى
ESLint و
Prettier . سيحمي ESLint التعليمات البرمجية الخاصة بك من الأنماط السيئة ، وسوف يساعدك Prettier تلقائيًا في تنسيق التعليمات البرمجية قبل طلب السحب.
الحل الأكثر جوهرية هو إضافة أدوات مثل Flow أو TypeScript إلى قاعدة التعليمات البرمجية الخاصة بك. تسمح لك هذه الأدوات بالقبض على أخطاء أكثر دقة ، مثل استدعاء دالة بمعلمة رقمية بدلاً من سلسلة أو استدعاء أسلوب
.filter على الكائنات بدلاً من الصفيف. على الرغم من التعقيد والحاجة إلى تدريب فريقك ، فإن هذه الأدوات تستحق انتباهك: يمكنها تسريع التطوير باستخدام Intellisense ومنع أخطاء وقت التشغيل مع حماية النوع.
كتابة الاختبارات
لطالما كانت الاختبارات مشكلة صعبة للمطورين. يؤمن البعض بشدة بالتطوير القائم على الاختبار ، بينما نادرًا ما يكتب الآخرون الاختبارات على الإطلاق. ولكن هناك حل وسط:
- حدد الوحدات الأساسية واكتب اختبارات الوحدة الشاملة لها. انتبه بشكل خاص إلى "الرحلات السعيدة": الحالات والسيناريوهات التي يمكن أن تحدث فيها أخطاء. بالنسبة للوحدات الأخرى ، اكتب اختبارًا واحدًا أو اثنين للاختبارات التي تغطي "المسارات السعيدة" وربما الحالات الشائعة التي قد تكون اكتشفتها
- اختبار الحد الأدنى لواجهة المستخدم . تتغير واجهة المستخدم باستمرار وغالبًا ما يكون من غير العملي قضاء الكثير من الوقت في إجراء اختبارات الشفرة التي ستتغير بشكل متكرر.
- كتابة الاختبارات للكشف عن الأخطاء . كلما عثرت على خطأ في الكود وأصلحته ، اكتب اختبار الوحدة الذي سيصطاد هذا الخطأ في المستقبل.
- اكتب بعض اختبارات التكامل للتأكد من تطابق جميع الأجزاء مع بعضها البعض.
- اكتب عددًا أقل من الاختبارات الشاملة . قم بتغطية المسارات الرئيسية على موقعك ، على سبيل المثال ، إذا كنت تقوم بإنشاء موقع للتجارة الإلكترونية ، فقد يكون من المفيد كتابة اختبار لدخول الموقع وإضافته إلى السلة والتحقق من قائمة المنتجات. هذه الاختبارات مكلفة للحفاظ عليها ، لذا ضع في اعتبارك الاحتفاظ بنواة صغيرة من الاختبارات التي يمكنك تحفيزها للحفاظ عليها.
نقطة البداية لكتابة الاختبارات هي القدرة على نشر كود جديد بثقة. اكتب العديد من الاختبارات بحيث لا تقل عن ما تشعر به بنفسك ، ولكن حاول ألا تكتب أكثر من القائمة أعلاه.
تصميم عديم الجنسية
المفتاح عند كتابة Node.js القابل للتطوير هو أن الخوادم الخاصة بك لا تحتاج إلى تخزين الحالات لشخص أو شيء ما. سيمنع هذا التحجيم الأفقي. انقل الحالة إلى تطبيق آخر وحل المشكلة في مكان آخر (مثل Redis ، Etcd ، ...). يجب أن تفكر في هذا مسبقا. ثم سيكون من الصعب للغاية الكشف إذا لم تكن قد فعلت ذلك من قبل. سيساعدك أيضًا إذا قررت في أي وقت أن تتحلل الأحجام المتراصة إلى خدمات دقيقة.
الإحصائيات: من أجل التنمية - Node.js للإنتاج - CDN
كيف أود أن ترى الشركات خطأ في هذا الخطأ. تعتبر خدمة الأصول الثابتة من تطبيق الويب الخاص بك (على وجه الخصوص من خلال شيء مثل webpack-dev-server أو خادم تطوير Parsel) تجربة مطورة ممتازة لأنها تقصر دورة المقدمة عند كتابة التعليمات البرمجية. ومع ذلك ، لا يجب عليك أبدًا عرض إحصاءاتك من خلال Node.js. يجب شحنه بشكل منفصل من خلال CDN ، مثل Azure CDN.
تكون عمليات الإرجاع الثابتة مع Node.js بطيئة بشكل غير ضروري لأن شبكات CDN مشتتة أكثر وبالتالي أقرب ماديًا إلى المستخدم النهائي ، كما أن خوادم CDN مُحسّنة للغاية للموارد الصغيرة. يعد الحفاظ على الإحصائيات باستخدام Node أيضًا تكلفة غير معقولة ، حيث أن وقت خادم Node.js أغلى بكثير من وقت خادم CDN.
ابدأ النشر مبكرًا ، وانشر عددًا أكبر من المرات
أنا لا أعرفك ، ولكن عندما أقوم بإلغاء حظر شيء ما لأول مرة ، فإنه لا يعمل أبدًا. هذا عادةً لأنني نسيت إرسال المفاتيح الخاصة الصحيحة أو تشفير المسار إلى المضيف المحلي. المشاكل الصغيرة التي تعمل محليًا عن بعد ترفض القيام بذلك. يمكن أن تتراكم هذه المشاكل ، وما يمكن إصلاحه بسهولة من قبل ، إذا كان من المبكر جدًا العثور عليه بالطبع ، يمكن أن يتحول إلى مجموعة كبيرة من الأخطاء غير المفهومة التي لا يمكن ببساطة اكتشافها بشكل طبيعي.
بالمناسبة ،
يسمح لك Visual Studio Code بحل هذا النوع من المشاكل . يسمح لك بنشر التطبيق الخاص بك مباشرة إلى Azure بنقرة واحدة. هذه طريقة بسيطة بما يكفي للتحقق من عدم وجود مشاكل في النشر في بيئة أخرى.
نشر خادمين في وقت واحد
تأتي هذه النصيحة من معرفتي التي اكتسبتها بشق الأنفس وبحر من وجع القلب. جوهر النصيحة هو أن هناك اختلافات قليلة بين نشر خادمين وعشرة خوادم ، ولا يوجد فرق كبير بين نشر عشرة خوادم ومائة خادم. ومع ذلك ، هناك ببساطة اختلاف كبير بين نشر خادم واحد وخادمين.
على غرار مسألة نشر خوادم عديمة الحالة ، بدءًا بخادمين ، يمكنك التغلب بسرعة على مشاكل التحجيم الأفقي بحيث عندما تكون هناك زيادة حادة في حركة المرور ، تكون مستعدًا للتوسع.
لا تخف من الخطوط
تتعامل قواعد البيانات الحديثة مع قدر معين من القراءة والكتابة من تلقاء نفسها ، دون مساعدتك. عندما تختبر فكرتك ، لا تتردد في الاعتماد على قاعدة البيانات الخاصة بك للتعامل مع أعباء العمل الصغيرة والمتوسطة الحجم.
من المرجح أن يقتلك التحجيم المبكر قبل أن ينقذك. ولكن ، في مرحلة ما ، سينمو تطبيقك بحيث لن تتمكن من كتابة كل شيء إلى قاعدة البيانات أيضًا ، في مواجهة مشاكل في قراءة وكتابة النطاق الترددي. بالنسبة لبعض التطبيقات التي لها سجل خفيف الوزن ، أو إذا قمت بتحديد قاعدة بيانات مثل كاساندرا ، والتي تتعامل مع النطاق الضخم بمفردها ، فستكون هذه مشكلة في وقت لاحق ، وبالنسبة لغيرها فستكون سابقة.
إذا كانت لديك مثل هذه المشكلة أو ستواجهها قريبًا ، فسيكون لديك خيارات لاختيار التقنيات التي ستذهب بها إلى أبعد من ذلك. قد تكون قائمة انتظار الرسائل إحدى هذه التقنيات. المعيار الفعلي في الوقت الحالي هو Apache Kafka ، والذي يسمح لك بتنظيم رسائلك في الموضوعات ، ثم التطبيقات للاشتراك في هذا الموضوع. لذلك ، على سبيل المثال ، يمكنك تجميع الرسائل في التطبيق ، والاستماع إلى موضوع معين ، ثم كتابة البيانات دفعة واحدة إلى قاعدة البيانات الخاصة بك بحيث لا تسد طوال الوقت.
بالإضافة إلى ذلك ، يعمل كافكا بسهولة على Azure .
الخدمات الدقيقة للتحجيم
مع نمو تطبيقك ، تبدأ الانقسامات المنطقية الطبيعية في الظهور. يمكن لجزء واحد من التطبيق معالجة الدفعات ، بينما سيخدم الجزء الآخر واجهة برمجة التطبيقات للواجهة الأمامية. عند عمل التقسيمات المنطقية ، ضع في اعتبارك أن تجعلها خدمات دقيقة. ولكن كن حذرا ، حيث أن إدخال الخدمات الدقيقة محفوف أيضا بتعقيد كبير. لكن الأمر يستحق ذلك. لذا ، على سبيل المثال ، يمكن أن يكون لكل خدمة مايكرو مقياس خاص بها. من خلال تقييمها ، يمكنك قياسها بشكل مستقل.
استخدم الحاويات
قد يعمل تطبيقك جيدًا محليًا ، ولكن قد تكون هناك مشكلات خطيرة في محاولة النشر. ستعمل أدوات مثل Docker و Kubernetes على تجنب هذه المشكلة. Docker ، الذي يمكنك تخيله كمثيل صغير (حاوية) لنظام التشغيل Linux أو Windows ، حيث يمكنك تشغيل التطبيق ؛ و Kubernetes كأداة تربط جميع حاوياتك معًا في السحابة.
قد يكون Kubernetes وحشًا معقدًا ، ولكنه وحش يحل مشكلة معقدة. إذا كنت ساحر DevOps قليل الخبرة ، فقد تواجه صعوبة ، لذلك أوصي بالبدء
بمسودة . إذا كنت معتادًا على
يومان لمشاريع جافا سكريبت ، فيمكنك تقييم المسودة كأداة مماثلة ، ولكن بالنسبة لمشاريع Kubernetes: أداة تنشئ إطارًا سلكيًا لمشروعك. من هناك ، يمكنك استخدام أداة
Helm لتثبيت قطع إضافية من الهندسة المعمارية التي تحتاج إلى إنشائها (على سبيل المثال nginx ، والمزيد من Node.js ، MongoDB ، خوادم كافكا ، إلخ) ، مثل
npm لـ Kubernetes تقريبًا.
بمجرد أن تفهم النظام البيئي Kubernetes ، من الآن فصاعدًا ، سيصبح النشر في السحابة لعبة أطفال.
اجمع المقاييس
إذا كنت لا تعرف كيفية الإجابة على السؤال "كيف يعمل طلبي؟" ، فستواجه مشاكل أو ستحدث قريبًا. بعد كل شيء ، ستساعدك أنواع مختلفة من المؤشرات بمرور الوقت على تحسين حالة تطبيقك باستمرار. من وجهة نظر تكاليف المستقبل ، ومن وجهة نظر راحة المستخدم من حيث تحسين وقت الاستجابة. يجب عليك بالتأكيد تتبع المقاييس مثل المسارات البطيئة ، ومشاهدات الصفحة ، ووقت الجلسة ، والمقاييس الرئيسية الأخرى المهمة لنشاطك التجاري.
هناك طرق عديدة لجمع هذه المؤشرات. ستزودك خدمات مثل New Relic و AppDynamics بمعلومات لا تقدر بثمن حول كيفية تحسين تطبيقك.
إذا كنت تعمل مع Azure ، تتوافق Application Insights أيضًا مع هذه الحاجة ، ومن السهل أيضًا توصيل أدوات أخرى مثل CI / CD.
سيخلصك CI / CD من الكثير من الألم
كم عدد المرات التي أفسدت فيها عملية النشر أثناء FTP وأزالت خادمك لعدة دقائق؟ كان معي. لا يجب أن تثق بنفسك أبدًا في نشر كود الإنتاج. كيفية القيام بذلك باستخدام Visual Studio Code رائع جدًا ، ولكنه مخصص أساسًا لأغراض التطوير أو العرض. عندما تكون مستعدًا لإنشاء نظام مستوى الإنتاج ، يجب عليك استخدام التكامل المستمر والنشر المستمر (غالبًا ما يكون اختصارًا CI / CD - التكامل المستمر والنشر المستمر).
التكامل المستمر هو ممارسة تطوير البرمجيات ، والتي تتكون من دمج نسخ العمل في فرع رئيسي مشترك من التطوير عدة مرات في اليوم وأداء التجميعات الآلية المتكررة للمشروع لتحديد العيوب المحتملة بسرعة وحل مشاكل التكامل.
يعتني النشر المستمر بأخذ التعليمات البرمجية التي اجتازت CI ، وتنفيذ الخطوات اللازمة لإنشاءها أو وضعها في عبوات أو تغليفها وإرسالها إلى الخادم. من الجيد أن يكون لديك عدة مستويات للاختبار. يمكنك أولاً الذهاب إلى خادم ديف الداخلي لرؤيته في بيئة منخفضة المخاطر أولاً. يمكنك اختباره أولاً قبل إرساله إلى بيئة ضمان الجودة حيث سيؤكد مهندسو ضمان الجودة أو خدمة خارجية أن كل شيء يعمل كما هو متوقع. من هناك ، يمكنك الانتقال إلى بيئة وسيطة حيث لا يزال تطبيقك داخليًا فقط ، ولكنه يعمل باستخدام بيانات الإنتاج والإعدادات ، بحيث يمكنك اختباره في بيئة الإنتاج نفسها قبل إرساله مباشرة إلى الإنتاج. يمكنك أيضًا تحديد مجموعة صغيرة من الخوادم للتحقق من الرمز الجديد: أنت وتوجه نسبة صغيرة فقط من حركة المرور الحقيقية إلى هذه الخوادم للتأكد من عدم حدوث أي انقطاع عند العمل مع مستخدمين حقيقيين. إذا انكسر ، فأنت تعرف أين تبحث عن المشكلة. إذا لم يكن كذلك ، يمكنك الانتقال من مجموعة صغيرة من المستخدمين إلى الجميع.
العديد من البائعين والمشاريع مفتوحة المصدر تلبي هذه الاحتياجات. Jenkins و Travis و CircleCI هي خيارات رائعة لـ CI. لدى Azure خدمة CI / CD خاصة بها تسمى Azure Pipelines ، وهي بديهية جدًا للاستخدام ، ومرة أخرى ، تتصل بسهولة بنظام Azure البيئي المتكامل.
احتفظ بالأسرار
أي تطبيق لا محالة لديه بعض الأسرار. يمكن أن تكون مفاتيح وخطوطًا سرية من بيانات الاعتماد وقواعد البيانات والمزيد. سيكون الأمر سيئًا جدًا إذا تحولوا إلى أيدي خاطئة. ومع ذلك ، فهي ضرورية لتشغيل التطبيق. إذن ماذا نفعل؟ عادة في التطوير سنستخدم أدوات مثل
dotenv لحفظ ملف التكوين محليًا وقادرًا على قراءته من خلال process.env في Node.js. هذا أمر عظيم للمطورين ، ولكنه رهيب للإنتاج.
بدلاً من ذلك ، من المفيد استخدام نوع من أداة الإدارة السرية. لحسن الحظ ،
تمتلك Kubernetes نظامًا مدمجًا وسهل الاستخدام. أنت تقدم أسرار Kubernetes على جانب الحاوية ، ومن ثم ستوفرها لتطبيقك كبيئة تعقّد الهجوم بشكل كبير.
أداة أخرى تستحق انتباهك هي Azure
Key Vault . ما هو رائع في Key Vault ، على الرغم من أن Microsoft لا يمكنها قراءة مفاتيحك (فقط يمكنك فك تشفيرها) ، فإن Azure سوف يتتبع سجلاتك ويتابع أي استخدامات مشكوك فيها لمفاتيحك لتنبيهك إلى أي تنازلات.
الخلاصة
يجب تحجيم Node.js ، مثل أي نظام أساسي آخر. ومثل أي منصة أخرى ، لديها مهامها الخاصة وخصوصية التوسع ، والتي تستحق المعرفة والتي يجب أخذها في الاعتبار عند تصميم المشاريع الكبيرة.
المقال الأصلي: "أحد عشر نصيحة لقياس النطاق Node.js" (
بالإنكليزية ).
أقترح في التعليقات لمشاركة النصائح التي يمكنك تقديمها حول توسيع Node.js. سيكون من المثير للاهتمام أن نسمع.