ناقشت أنا وزملائي مؤخرًا شعبية بعض التقنيات - خاصة Java و node.js. بعد تصفح الإنترنت القصير ، تبين أن هذه التقنيات هي التي يستخدمها العديد من عمالقة المعلومات لتطوير مواقعهم على الشبكة وصيانتها. أدناه ، سأقدم فقط جزء صغير.
الشركات التي تستخدم جافا:
الشركات التي تستخدم node.js:
كما أنه من الأقل إثارة للاهتمام أنه وفقًا للبحث الذي
أجري على في
الواقع (
06/28/2019 ) بناءً على طلب Java Developer (30272 وظيفة شاغرة) ومطور node.js (7401 وظيفة شاغرة) ، فإن المتخصصين في هذه التقنيات مطلوبون للغاية.

ولكن كل هذا هو مجرد معلومات عامة بشأن شعبية. المعلومات التي دفعتني إلى الخوض في الموضوع بشكل أعمق والتأمل في موضوع الميزات التقنية ، مما أدى إلى كتابة هذه المقالة.
لماذا تستحق المقارنة؟
Java هي لغة ، node.js يمكن أن يطلق عليها نظام إيكولوجي مبني على أساس JS ، وقبل كل شيء ، يعتمد على V8 - محرك من Google.
ومع ذلك ، عندما نتحدث عن Java ، فإننا لا نتحدث فقط عن اللغة ، ولكن عن الجهاز الظاهري لـ Java ، وكذلك عن النظام البيئي والبنية التحتية بأكملها المبنية حول هذا الجهاز. كحد أدنى ، يمكن مقارنتها على هذا الأساس - ونتيجة لذلك ،
في كلتا الحالتين ، لدينا وقت تشغيل . في حالة جافا ، إنه جهاز افتراضي. في حالة node.js ، يعد محرك V8 متاحًا في معظم أنظمة التشغيل ، مثل Windows و Linux و MacOS وأقلها شهرة.
يمكن للمطورين كتابة التعليمات البرمجية باستخدام نفس اللغة ، وسيعمل هذا بطريقة أو بأخرى بالطريقة نفسها على أنظمة تشغيل مختلفة نظرًا لوجود وقت تشغيل. تؤثر بيئة وقت التشغيل على كيفية حدوث التفاعل مع نظام التشغيل. بالإضافة إلى ذلك ، يمكن مقارنتها منذ ذلك الحين يتم
استخدامها لحل مجموعة مماثلة من المشاكل .
V8 و JVM
عندما يصل رمز JS إلى الإصدار 8 ، يتم تنفيذ رمز JS في الوقت المناسب ، ويتم تجميع رمز البايت المستخدم في الجهاز الظاهري بشكل أسرع وأسرع.
تعتبر شفرة البايت لغة وسيطة عالية المستوى ، لذلك في جهاز Java الافتراضي ، لا يكتبون فقط في Java ، ولكن أيضًا في Scala و Kotlin.
هناك متطلبات أساسية في المستقبل القريب لـ V8 سيكون من الممكن استخدام JS ليس فقط ولكن أيضًا TypeScript أو غيرها. في الوقت الحالي ، هناك تحول بين هذه اللغات في JS. في المستقبل ، من المحتمل أن يتم دعمهم خارج الصندوق ، وسيعمل كل شيء بشكل أسرع.
الآن هناك تطور مستمر لـ V8 ، وبشكل عام ، يرتبط ظهور إصدارات جديدة من node.js مع ظهور إصدار جديد من محرك V8. مترابطة مباشرة.
Node.js: مزايا وعيوب
تم إنشاء Node.js بواسطة Ryan Dahl في عام 2009.
Node.js نفسه يتضمن العديد من المكونات الرئيسية:
- محرك V8
- مكتبة libuv ، المسؤولة عن الجزء المركزي من العقدة - حلقة حدث ، والتي تتفاعل مع نظام التشغيل ، وكذلك عن الإدخال / الإخراج غير المتزامن (I / O) ؛
- من مجموعة من مكتبات JS المختلفة ومباشرة من لغة JS نفسها.
دعنا ننتقل إلى إيجابيات وسلبيات.
الايجابيات:- سهولة وسرعة الكتابة
- خفة
- البساطة النسبية (مقارنة بجافا)
- npm (مدير حزمة العقدة (عدد كبير من المكتبات التي يمكن تثبيتها على سطر واحد)
- كل مكتبة تقع في شجرة التبعية وهذا كله يتم بسهولة
- التطوير المستمر (يتم تطوير TypeScript بنشاط (والذي يجلب الكتابة ، والديكور إلى JS ويستخدم ، على سبيل المثال ، للزاوي)
سلبيات:- المرونة والتطور السريع يولد أيضا عيوب تحتاج إلى مراقبة التحديثات باستمرار ، فبعض الأشياء لا يتم اختبارها بشكل كافٍ ؛
- حدثت حالة عندما قام أحد مطوري البرامج بإزالة مكتبته من NPM وتوقفت العديد من التطبيقات التي تستخدمها عن العمل ؛
مزايا وعيوب جافا
في المقابل ، فكر على الفور في السمات الرئيسية لجافا.
الايجابيات:- سرعة العمل
- انتشار (في جامعات العديد من البلدان التي يدرسون جافا ، كما أنها مريحة لدراسة OOP في جافا) ،
- مجموعة ضخمة من المكتبات.
سلبيات:- ثقل،
- تم إنشاء بعض نماذج Java لفترة طويلة وقد عفا عليها الزمن بالفعل ،
- JDK ملكية خاصة ، لذلك فإن Java تتطور ببطء.
في الآونة الأخيرة ، بدأت JS في تجاوز Java (والأبعد ، والمزيد).
تغادر Java أيضًا عالم Android ، حيث يتم استبداله بـ Kotlin التي ، على الرغم من أنها تستخدم JVM ، لا تزال لغة مختلفة.
أوراكل وجوجل الصراع

تم إنشاء Java بواسطة Sun ، والتي استحوذت عليها Oracle في وقت لاحق وما زالت مملوكة لها. لهذا السبب ، فإن العديد من الشركات التي تستخدم جافا تخلق بعض المشاكل.
واجهت Google مشكلات عندما بدأت Oracle دعوى قضائية معهم لاستخدام Java في Android. لهذا السبب ، اعتمدت جوجل بنشاط كبير Kotlin ، والتي ظهرت بشكل مستقل. جافا هي الملكية. ولكن هناك جهاز Oracle ظاهريًا ، بالإضافة إلى جهاز Java ظاهري مفتوح (JVM مفتوح) ، يُستخدم في Linux ومكتوب في مصدر مفتوح. في بعض الأحيان يكون هناك بعض التعارضات ، لكنها في الآونة الأخيرة أقل وأقل.
بالمناسبة ، لم تتمكن Google من التخلي عن Java تمامًا. في Dalvik ، الذي يستخدم كجهاز أساسي في Android ، فإن JVM مضمن. ربما سيتركون هذا ، لكن سيكون من الصعب جدًا القيام بذلك لأنه تم بناء نظام Android بالكامل تقريبًا على Java - بشكل أساسي على استخدام JVM المحدث. وهذا ، في مرحلة ما ، كان أيضًا سبب التعارض بين Oracle و Google ، لأن Oracle يحظر تحديث JVM فقط. هذا هو الجزء الأكثر أهمية في جافا. واللغة نفسها يمكن استخدامها دون أي قيود تقريبا.
Java vs node.js: الأداء واستهلاك الموارد
بادئ ذي بدء ، تجدر الإشارة إلى أن أداء Java أعلى بكثير من أداء JS ، وبالتالي ، node.js.
Node.js وأداء جافاإذا قمت ببعض المهام البسيطة ، مثل التربيع ، فيمكن أن تختلف المؤشرات في الاختبارات حتى 10 مرات. إذا قمت بتشغيل حلقات بملايين مهام الحساب ، فستتجاوز Java دائمًا العقدة. بالإضافة إلى ذلك ، فإن الفارق الكبير بين Java و node.js هو أن العقدة مترابطة ، وهي ميزة وعيوب في نفس الوقت.
يمكن أن يعمل Java مع التدفقات المدعومة على مستوى نظام التشغيل ، وتبين أن البرنامج المكتوب بلغة Java يستفيد إلى أقصى حد من إمكانيات نظام التشغيل. وإذا كنت بحاجة إلى كتابة تطبيق محمّل بدرجة عالية يستخدم عددًا كبيرًا من العمليات الحسابية ، فستكون Java بالتأكيد أفضل لهذا الغرض. المشكلة هي أنه حتى الخادم الصغير المكتوب بلغة جافا سيشغل الكثير من الذاكرة - سواء على القرص أو عبر الإنترنت.
Node.js خفيفة الوزن بسبب بنيتها المبنية على الأحداث. تم تصميمه للعمل كخادم ويب ويقوم بعمل جيد جدًا لخدمة المهام خفيفة الوزن. على سبيل المثال ، يحدث استعلام بسيط مثل حساب شيء ما ، أو الكتابة إلى قاعدة بيانات ، بسرعة كبيرة. وإذا كان هناك الكثير من الطلبات ونريد توسيع نطاق النظام في العقدة ، يمكنك استخدام خادم الويب Nginx أو Apache. يمكن أن يكون لديك العديد من مثيلات العقدة متطابقة. ثم سيتم توزيع كل شيء من خلال موازنة التحميل المستديرة. إذا قمنا بتشغيل 8 مثيلات عقدة على 16 مركزًا ، على التوالي ، فسيقوم نظام التشغيل نفسه بتوزيع المثيلات بين النواة. العقدة لا تتحكم في هذا ، سيكون لها خيط واحد.
التحكم في التدفق في Java و node.js
في Java ، يمكننا إنشاء تطبيق وتشغيل 8 مؤشرات ترابط فيه. نظرًا لوجود تفاعل أوثق مع نظام التشغيل ، يمكنك توزيع الحمل.
كما تعلم ، فإن أحد خوادم الويب المكتوبة بلغة جافا هو tomcat. هناك يمكنك أن ترى بوضوح أنه عندما يقدم المستخدم طلبًا ، يتم تشغيل سلاسل رسائل إضافية. وعندما يأتي الطلب إلى العقدة ، ستتم معالجة حلقة الحدث وإرسالها مرة أخرى ، ثم يأتي الطلب التالي. ونظرًا لحقيقة أننا لا نتوقع نتائج الأول ، سيتم التقاطها أيضًا. بينما الطلبات خفيفة الوزن ، كل شيء على ما يرام. ومع ذلك ، عند إجراء عملية حسابية ثقيلة ، في حالة وجود مثيل واحد ، تتوقف العقدة وتحدث مهلة.
إدارة خيط جافاعلى العقدة ، يمكنك كتابة بضعة أسطر من التعليمات البرمجية والحصول على أبسط خادم ويب. بطبيعة الحال ، للحصول على وظائف أوسع ، حيث سيكون هناك إخطارات وتراخيص وتسجيل ، إلخ. من الصعب تطبيقه ، ولكن هناك أطر تسمح لك بحل هذه المشكلات.
التحكم في التدفق في node.jsيحتوي Java على واجهة برمجة تطبيقات متزامنة API ، والتي تتيح لك العمل مع مؤشرات ترابط تنافسية. ولكن في الوقت نفسه ، هذه واحدة من المشاكل منذ ذلك الحين التنافسية شيء معقد للغاية وليس كل مطور على دراية جيدة بهذا.
الويب ، واجهة برمجة تطبيقات REST هي عنصر العقدة ، وأحيانًا يستخدمونها. ولكن إذا كنا نتعامل مع حسابات معقدة ، فلا يزال من الأفضل استخدام Java.
مشروعي جافا
في Java ، كان لديّ مشروع مثير للاهتمام - تطبيق موزع ، تتمثل مهمته الرئيسية في معالجة كميات كبيرة من المعلومات الرسومية لاستخدامها مرة أخرى في الدلائل. عند إنشاء كتالوج ، ستحتاج إلى إعداد مجموعات من عدد كبير من الصور ذات الدقة المختلفة التي سيتم استخدامها لإنشاء الكتالوج. ببساطة ، هذا هو تطبيق لأتمتة إعداد كتالوج ما قبل الطباعة.
اعتاد المصورون القيام بكل شيء يدويًا. أولاً ، كان عليك استخدام بعض التطبيقات الصغيرة من أجل تحميل صورك. علاوة على ذلك ، كان على المتخصص الذي ينشئ الدليل تطوير بنية الدليل من خلال تطبيق آخر. بعد ذلك ، في تطبيق آخر ، تم إنشاء سير عمل ألقى الصور في الهيكل الذي تم إنشاؤه. بشكل عام ، كانت العملية صعبة للغاية. يستخدم ImageMagick على لينكس ، ويندوز ، ماك. كنا نتعامل مع Linux.
على سبيل المثال ، تم تحميل صورة .tiff بحجم 200-300 ميغابايت في التطبيق ، وكان من الضروري إنشاء صور بدقة مختلفة ، أو قص شيء ما ، أو تكوين طبقة أساسية.
تعذر على الإصدار الأول من التطبيق التعامل مع الحمل الثقيل ، حتى الخادم الذي يحتوي على 16 معالجات أساسية كان مفقودًا. لقد قمنا بتحسين بنية التطبيق لاستخدام عدة مثيلات في نفس الوقت حتى لا نقوم بتغيير التطبيق بشكل جذري. تم إطلاق العديد من الحالات التي تفاعلت مع بعضها البعض وعالج كل منها جزءًا من المهمة. كان الأمر صعبًا ، لكننا تمكنا من تنفيذ كل شيء بنجاح في غضون شهرين فقط. والنظام لا يزال يعمل. في هذه العملية ، كان علينا التعامل مع المنافسة والجوانب المختلفة للتفاعل.
لا يزال من الممكن نقل شيء من هذا المشروع إلى العقدة ، ولكن لا يزال يتعين القيام ببعض الأشياء في Java ، لأن كان هناك العديد من الحسابات المختلفة. في الأساس ، يمكن أن نصنع أجزاء على العقدة تستدعي أجزاء معينة في Java وتستخدم بنية microservice. يمكنك استخدام نسخة مختلطة. ولكن هذا النهج لا يعمل دائما ، لأن قد لا يكون المطور المتخصص في العقدة متخصصًا في Java والعكس. وإيجاد مطورين عالميين أصعب بكثير.
من الخبرة في node.js
كان هناك مشروع لتنظيم كمية كبيرة من البيانات. شيء مشابه للمشروع الموضح أعلاه. هنا فقط نقوم بتحميل ملف يحتوي على مجموعة كبيرة من المعلومات ويخضع للتحقق من خلال خدمة تابعة لجهة خارجية (مكتوبة بلغة جافا) ، عدة مرات ووفقًا لقواعد مختلفة. كان من الضروري معالجة مئات غيغابايت من المعلومات ، ولم تكن العقدة مخصصة لهذا الغرض.
كان من المثير للاهتمام بشكل خاص تصميم بنية النظام ، كما يتألف التطبيق من العديد من الخدمات المصغرة ، بما في ذلك الجهات الخارجية. عند العمل مع خدمة تابعة لجهة خارجية قامت بالتحقق ، استخدمنا وسيط رسائل RabbitMQ. قدمنا المعلومات اللازمة إلى خادم طرف ثالث وتلقينا رسالة من RabbitMQ بعد انتهاء التحقق من الصحة ، ثم تمت معالجة البيانات في أجزاء لتجنب نفاد الذاكرة.
وإذا قام التطبيق في البداية بمعالجة ملف يحتوي على 10000 سجل ، فيمكنه الآن معالجة ما يصل إلى مليون سجل. لا يزال بإمكاننا حل هذه المشكلة باستخدام node.js ، على الرغم من أنه في Java يمكن حلها بسهولة أكبر ، ومع ذلك ، أراد العميل استخدام العقدة تمامًا ، لأنه كنت بحاجة إلى بنية تحتية موحدة وهندسة معمارية بها خدمات ميكروية مكتوبة بلغة JS. كان استخدام العقدة لحل المشكلة أكثر تعقيدًا وتطلب المزيد من الوقت ، ولكن node.js يفوز بسبب قابلية التوسع. لهذا السبب يمكننا الآن زيادة عدد العمال ومعالجة المزيد والمزيد من البيانات. في Java ، سيكون هذا أكثر تعقيدًا.
في الواقع ، يمكن حل أي مشكلة بهذه الطريقة ، لكن الأمر يستحق التكرار هنا: إذا كان هناك الكثير من العمليات الحسابية ، فمن الأفضل استخدام Java ، إذا لم يكن هناك العديد من العمليات الحسابية ، يمكنك استخدام العقدة بأمان.
الملخص والآفاق: هل ستكون node.js قادرة على تجاوز Java؟
الآن يتعلق الأمر بحقيقة أنه سيتم استخدام node.js غالبًا كملف ، وسيتم كتابة الحشو بلغات أخرى. منذ فترة طويلة أوجه القصور المعروفة. على سبيل المثال ، تم إصلاح الخلل الشرطي مثل الترابط الفردي. يقدم أحدث إصدار من العقدة القدرة على استخدام مؤشرات ترابط متعددة.
تم إنشاء Java أصلاً كحل خفيف الوزن يحل محل C ++ ، وأصبح الآن ثقيل الوزن. هو مثل التطور. ربما يوما ما سيكون هناك شيء سيحل محل العقدة.
الوحدات - تطوير Java مقابل node.jsالآن ، وفقًا لعدد الطلبات ، ووفقًا لمشاعري ، فإن node.js هي بالفعل متقدمة على Java.
JS تتطور بنشاط وسوف تتغير - ربما سيأتي شيء ليحل محله.
الآن لا يوجد منافس محتمل يمكنه استبدال Java و node.js.
المشكلة هي أن تطوير Java كان بطيئًا مؤخرًا ، وأن node.js تتطور بسرعة لا يمكن استبدالها في المستقبل القريب.