هل ستكون Node.js دائمًا أبطأ من Golang؟

هناك شعور بأنه حرفيًا كل أسبوع يظهر "إطار عمل ويب" جديد لـ Node.js ، والذي يسمى شيئًا يعمل بشكل أسرع من كل ما سبقه. يعلم الجميع أن Express بطيء ، ولكن هل الإطار التالي قادر على تحسين أداء النظام الفرعي I / O Node.js؟ الشيء الوحيد الذي يمكنها فعله هو التخلص من الحمل الزائد على النظام الذي أنشأته Express. لا يوجد حديث عن تحسين شيء أساسي. في الواقع ، من أجل تحسين الوضع بشكل جذري ، تحتاج إلى العمل على مستوى أعمق ، وعدم إضافة تجريدات جديدة على رأس Node.js.



ما الذي يتطلبه الأمر لإنشاء تطبيقات خادم على النظام الأساسي Node.js التي تعمل بشكل أسرع بكثير من كل ما هو اليوم؟

تحليل الموقف

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

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


عدد طلبات HTTP التي تتم معالجتها بواسطة خوادم مختلفة في الثانية

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

لحسن الحظ ، يدعم Node.js الوظائف الإضافية لـ C ++ ، ومجلدات Google V8 ، والتي تتيح لك ربط JavaScript و C ++ ، وتسمح لك بالاتصال بأي آليات من JavaScript ، حتى لو توفرت هذه الآليات بواسطة شيء آخر غير النظام الأساسي Node.js.

هذا يجعل من الممكن توسيع وتحسين قدرات تطبيقات JavaScript ، مما يتيح لك الوصول إلى مستويات جديدة من الأداء. يسمح هذا لبرامج JavaScript بالضغط على كل شيء ممكن من محرك Google V8 ، وليس مقصوراً على ما وجده مطورو Node.js كافيين.

حول ebWebSockets.js

في وقت سابق من هذا الشهر ، قمت بإصدار مشروع جديد - µWebSockets.js . يستخدم GitHub كمضيف لرمزه ، وليس npm ، ولكن يمكنك تثبيته على Node.js باستخدام npm مثل هذا:

npm install uNetworking/uWebSockets.js#v15.0.0 

للعمل مع ebWebSockets.js ، لا تحتاج إلى برنامج التحويل البرمجي. يتم دعم Linux و macOS و Windows. الإصدار الأولي للنظام هو 15.0.0 ، ويتم ترقيم الإصدار وفقًا لقواعد الإصدار الدلالية.

µWebSockets.js هو خادم ويب بديل للتطبيقات الخلفية المكتوبة في JS. يتكون من حوالي 6 آلاف سطر من كود C و C ++ ويتفوق بشكل كبير على أفضل الحلول المكتوبة بلغة Golang. لذلك ، قام موقع bitfinex.com بتحويل كل من واجهات برمجة التطبيقات التجارية (REST و WebSocket) إلى µWebSockets.js ويقوم بإدخالها تدريجياً في الإنتاج. يلاحظ باولو Ardoino من Bitfinex أن هذا مشروع رائع. أود أن أقول إن حقيقة أنني أتيحت لي الفرصة لإصدار µWebSockets.js تعود بالكامل إلى الدعم الذي قدمته لي BitMEX و Bitfinex و Coinbase.

ميزات ebWebSockets.js

µWebSockets.js هو مشروع جديد تم إصداره بموجب ترخيص Apache 2.0 ، وهو استمرار لما يُعرف باسم "uws". هذا المشروع عبارة عن مكدس كامل لـ Google V8 ، بدءًا من مستوى kernel في نظام التشغيل ، واستبدالًا تامًا للميزات القياسية لـ Node.js ويمثل نظام دخل / إخراج مستقر وآمن ومتوافق مع المعايير وسريع وخفيف الوزن لـ Node.js. إليك ما يشبه تفاعل تطبيق JS مع نظام التشغيل باستخدام µWebSockets.js.


تفاعل تطبيق JS مع نظام التشغيل باستخدام µWebSockets.js

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

تجدر الإشارة إلى أن طبقة " µSockets نفسها تتكون من ثلاثة طبقات فرعية ، وهي آليات للعمل مع الأحداث ومع الشبكة ، وكذلك أدوات لحماية البيانات. يسمح هذا ، إذا لزم الأمر ، باستبدال أجزاء من الحل ، بإضافة تطبيقات بديلة لبعض الميزات إلى النظام ، دون مواجهة الحاجة إلى تغيير الكود على مستوى أعلى.

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


ockets مآخذ الطبقات الفرعية الداخلية

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

حول تطوير µWebSockets.js

فيما يلي مثال مبسط ومختصر للغاية للعمل مع µWebSockets.js ، وتتمثل مهمتها الرئيسية في إظهار القدرات الأساسية للنظام.

 /* SSL-   */ uWS.SSLApp({   key_file_name: 'misc/key.pem',   cert_file_name: 'misc/cert.pem',   passphrase: '1234' }).get('/hello', (res, req) => {   /*    */   res.end('Hello World!'); }).ws('/*', {   open: (ws, req) => {       console.log('A WebSocket connected via URL: ' + req.getUrl() + '!');   },   message: (ws, message, isBinary) => {       /* OK   false          *     */       let ok = ws.send(message, isBinary);   },   drain: (ws) => {       console.log('WebSocket backpressure: ' + ws.getBufferedAmount());   },   close: (ws, code, message) => {       console.log('WebSocket closed');   } }).listen(port, (token) => {   if (token) {       console.log('Listening to port ' + port);   } }); 

بمعنى ما ، يمكننا القول أن µWebSockets.js باستخدام طبقة المقابس الآمنة (SSL) يمكنها تجاوز Gorilla WebSocket ، وهو تطبيق لبروتوكول WebSocket على الذهاب ، بدون طبقة المقابس الآمنة. بمعنى ، اتضح أن كود JS يمكنه تبادل الرسائل باستخدام طبقة المقابس الآمنة بشكل أسرع من الشفرة المكتوبة في Go بدون طبقة مآخذ توصيل آمنة (SSL) في ظروف معينة. أعتقد أن هذه نتيجة ممتازة.

تنفيذ بروتوكول WebSocket سريع

Socket.IO ، في نواح كثيرة ، يمكن اعتبار مكافئ Express في الوقت الحقيقي. ظهر كلا المشروعين منذ فترة طويلة ، من السهل العمل معهم ، إنهما مشهوران. لكنها ، من بين أمور أخرى ، بطيئة أيضا.


تطبيقات WebSocket المختلفة

يتم تقليل المهام التي يساعد مطور Socket.IO في حلها إلى تنفيذ وظيفة نشر الرسائل والاشتراك فيها ، إلى القدرة على إرسال واستقبال الرسائل.

في الوقت نفسه ، تجدر الإشارة إلى استخدام بعض آليات الغيار للعمل مع بروتوكول WebSocket ، لأن المتصفحات تدعم هذه التكنولوجيا لفترة طويلة. لا يمكن تفسير حركة مرور طبقة المقابس الآمنة بواسطة وكلاء الشركة ، فهي تمر عبرها بنفس الطريقة مثل أي حركة مرور HTTP ، ونتيجة لذلك ، فإن استخدام بروتوكول WebSocket عبر طبقة المقابس الآمنة لا يحظر حركة المرور المقابلة. يمكن توفير آليات احتياطية لدعم WebSocket ، لكن لا فائدة من استخدامها. إنها تزيد فقط من تعقيد القرارات.

أحد أهداف µWebSockets.js هو إعطاء ميزات للمطورين مماثلة لتلك الموجودة في Socket.IO بحيث يمكن لـ µWebSockets.js استبدال Socket.IO بالكامل دون الحاجة إلى أي مغلفات ذات مستوى أعلى . يكون ذلك ممكنًا إذا لم يتم استخدام بروتوكول خاص غير قياسي.

تواجه العديد من الشركات مشاكل في النشر والاشتراك في الرسائل أثناء العمل مع WebSocket. تجدر الإشارة إلى أنه في الإصدار الموصوف من ebWebSockets.js لم يتم إيلاء الكثير من الاهتمام لهذه الميزات ، ولكن الآن يجري العمل الجاد بشأنها. ستكون النتيجة سريعة جدًا (توضح الاختبارات أن µWebSockets.js أسرع بالفعل من Redis). لذلك ترقبوا.

ملخص

حاليًا µWebSockets.js قيد التطوير ، تتم إضافة ميزات جديدة إلى المشروع ، ويتم إصلاح الأخطاء. سوف يستغرق الأمر بعض الوقت للتخلص من تلك العيوب البسيطة التي تميز الإصدارات الأولى من البرامج الجديدة. ضع في اعتبارك أن هذا مشروع كبير يتكون من عدة آلاف من سطور التعليمات البرمجية المكتوبة في C و C ++ ، والتي يتم تخزينها في ثلاثة مستودعات. هنا يكمن برنامج التفاف JavaScript - uWebSockets.js. هنا خادم ويب مكتوب في C ++ - uWebSockets. وها هي المكتبة الأساسية المكتوبة بلغة سي.

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

أعزائي القراء! هل تخطط لاستخدام ebWebSockets.js في مشاريعك؟