Нещодавно ми з колегами обговорювали питання популярності деяких технологій — зокрема Java і node.js. Після недовгого інтернет-серфінгу з'ясувалося, що саме ці технології використовують інформаційні гіганти для розробки і підтримки своїх майданчиків у мережі. Нижче я наведу лише малу частину.
Компанії які використовують Java:
Компанії які використовують node.js: 
He менш цікавим є і те, що за даними пошуку на indeed.com (28.06.2019) за запитами Java Developer (30272 вакансії) та node.js developer (7401 вакансії), фахівці з цими технологіями досить затребувані.
Але все це лише загальна інформація, що стосується популярності. Інформація, яка наштовхнула мене на думку заглибитися в тему і поговорити на предмет технічних особливостей, що призвело до написання цієї статті.
Чому їх варто порівнювати
Java — це мова, node.js — можна назвати екосистемою побудованої на базі JS, і, перш за все, на базі V8 — рушія від Google.
Однак, коли ми говоримо про Java, ми говоримо не тільки про мову, а про віртуальну машину Java, а також всю екосистему і побудовану інфраструктуру навколо цієї машини. Як мінімум, їх можна порівнювати за цією ознакою — як результат, в обох випадках ми маємо середовище виконання. У разі Java — це віртуальна машина. У разі node.js — це рушій V8 який представлений на більшості ОС, таких як Linux, MacOS, Windows і менш відомих.
Розробники можуть писати код користуючись однією і тією ж мовою, і це буде працювати більш-менш однаковим чином на різних ОС за рахунок того, що існує середовище виконання. Середовище виконання впливає на те, як відбувається взаємодія з ОС. Крім того, їх можна порівнювати оскілки вони використовуються для вирішення схожого кола завдань.
V8 і JVM
Коли в v8 потрапляє код JS, здійснюється just in time компіляція в байт-код, який виконується у віртуальній машині, код на JS виконується все швидше і швидше.
Байт-код — це проміжна мова високого рівня, тому у віртуальній машині Java пишуть не тільки на Java, але також на Scala і Kotlin.
Є передумови того, що в найближчому майбутньому для V8 можна буде використовувати не тільки JS але і TypeScript або інші. На даний момент йде трансліпування цих мов в JS. У майбутньому, вони ймовірно будуть підтримуватися з коробки, і все буде працювати набагато швидше.
Зараз йде безперервний розвиток V8, і за великим рахунком, поява нових версій node.js пов'язано з появою нової версії рушія V8. Вони прямо взаємопов'язані.
Node.js: переваги та недоліки
Node.js був створений Райаном Далом (Ryan Dahl) в 2009 році.
Сам node.js включає в себе кілька основних складових:
- рушій V8;
- бібліотеки libuv, яка відповідає за центральну частину node — цикл подій (event loop), який здійснює взаємодію з ОС, а так само за асинхронне введення/виведення (I/O);
- з набору різних JS бібліотек і безпосередньо самої мови JS.
Перейдемо до його плюсів і мінусів.
Плюси:
- легкість і швидкість написання
- легковаговик
- відносна простота (у порівнянні з java)
- npm (node package manager (величезна кількість бібліотек які можуть бути встановлені в один рядок)
- кожна бібліотека потрапляє в дерево залежностей і все це робиться легко
- постійний розвиток (зараз активно розвивається TypeScript (який привносить в JS типізацію, декоратори і використовується наприклад для Angular)
Мінуси:
- гнучкість і швидкий розвиток породжує також і мінуси оскільки треба постійно стежити за оновленнями, деякі речі виходять недостатньо протестованими;
- був випадок, коли розробник видалив свою бібліотеку з NPM і безліч застосунків, що використовують її перестали працювати;
Переваги і недоліки Java
На противагу відразу розглянемо основні характеристики Java.
Плюси:
- швидкість роботи,
- поширеність (у ВУЗАХ багатьох країн вивчають java, також на java зручно вивчати ООП),
- величезний набір бібліотек.
Мінуси:
- важковаговик
- деякі парадигми Java створювалися давно і вже застаріли,
- JDK комерційний, тому Java розвивається повільно.
Останнім часом JS починає обганяти Java (і чим далі, тим більше).
Також Java йде зі світу Android, їй на зміну приходить Kotlin який хоч і використовує JVM, але все ж є іншою мовою.
Конфлікт Oracle і Google
Java була створена компанією Sun, яка пізніше була викуплена компанією Oracle і донині належить їй. З цієї причини, для багатьох компаній використання Java створює деякі проблеми.
Більше про: багаторівнева архітектура
У Google виникли проблеми, коли Oracle почали з ними судовий розгляд за використання Java в Android. Через це Google дуже активно прийняв Kotlin, який з'явився незалежно. Java є комерційною. Але є віртуальна машина Oracle, а також відкрита віртуальна машина Java (open JVM), яка використовується в Linux і написана в open source. Іноді існують деякі розбіжності, але останнім часом їх все менше і менше.
До речі, Google так і не зміг повністю відмовитися від Java. В Dalvik, який використовується як ядро Android, вшитий JVM. Можливо від цього підуть, але зробити це буде дуже складно, оскільки практично вся екосистема Android побудована на Java — насамперед на використанні модернізованого JVM. І це, в якийсь момент, теж було причиною конфлікту між Oracle і Google, тому що Oracle забороняє просто так модернізувати JVM. Це найважливіша частина Java. А сам мову можна використовувати практично без обмежень.
Java vs node.js: продуктивність і ресурсомісткість
Насамперед варто відзначити, що продуктивність Java набагато вище ніж у JS, і, відповідно, node.js.
Продуктивність node.js і Java
Якщо запустити якусь просту задачу, на кшталт зведення в квадрат, то в тестах показники можуть розрізнятися до 10 разів. Якщо запустити цикли в мільйони завдань калькуляції, Java практично завжди буде перевершувати node.js. Плюс, величезна відмінність між Java і node.js у тому, що node є однопоточним, це є його перевагою, так і недоліком з іншого боку.
Java вміє працювати з потоками, які підтримуються на рівні ОС, і виходить, що програма написана на Java найбільш повно використовує можливості ОС. І якщо потрібно написати високонавантажений застосунок, який буде використовувати велику кількість обчислень, то Java для цього однозначно підійде краще. Проблема в тому, що навіть маленький сервер написаний на Java буде займати багато пам'яті на диску, а також оперативну пам'ять.
Node.js є легковаговиком за рахунок архітектури побудованої на обробці подій. Він побудований для роботи в якості веб-сервера і дуже добре справляється з обслуговуванням легких завдань. Наприклад, простий запит на зразок розрахунку чого-небудь, або запису в базу даних відбувається дуже швидко. А якщо запитів стає дуже багато і ми хочемо масштабувати систему в node, можна використовувати веб-сервер Nginx або Apache. Можна завести багато однакових инстансов node. Тоді все буде розподілятися через балансування навантаження по round-robin. Якщо ми запустимо 8 екземплярів node на 16 ядер відповідно, ОС сама розподілить екземпляри між ядрами. Node цим не управляє, у нього буде один потік.
Управління потоками в Java і node.js
В Java можна створити застосунок і запустити в ньому 8 потоків. За рахунок того, що відбувається тісніша взаємодію з ОС, можна розподілити навантаження.
Як відомо, один з веб-серверів написаних на Java — це tomcat. Там можна чітко простежити, що коли користувач робить запит, запускаються додаткові потоки. А коли приходить запит на node, цикл подій (event loop) буде оброблений і відправлений назад, потім прийде наступний запит. І за рахунок того, що ми не чекаємо результатів першого, він теж буде підхоплений. Поки запити легковагі, все добре. Однак, коли проводиться важке обчислення, при наявності одного екземпляра, node зупиняється і настає тайм-аут.
Управління потоками в Java
На node можна прописати буквально кілька рядків коду і отримати найпростіший веб-сервер. Природно, для ширшого функціоналу, де будуть оповіщення, авторизації, логування і т. д. це складніше реалізувати, але існують фреймворки які дозволяють вирішувати такі питання.
Управління потоками в node.js
На Java є розвинене API — concurrency api, який дозволяє працювати з конкурентними потоками. Але в той же час, це є однією з проблем оскільки конкурентність це дуже складна штука і далеко не кожен розробник добре на цьому розуміється.
Веб, REST API — це стихія node, і іноді саме його і використовують. Але якщо ми маємо справу зі складними розрахунками, все ж краще використовувати Java.
Мій проект на Java
На Java в мене був цікавий проект — розподілений застосунок, основним завданням якого була обробка великих обсягів графічної інформації для подальшого використання в каталогах. При створенні каталогу необхідно підготувати набори великої кількості зображень різних розширень, які будуть використані при створенні каталогу. Простіше кажучи — це застосунок для автоматизації переддрукарської підготовки каталогу.
Раніше фотографам доводилося робити все вручну. Для початку потрібно було використовувати якийсь невеликий застосунок для того, щоб завантажити свої зображення. Далі, спеціаліст створював каталог повинен був розробити структуру каталогу через інший застосунок. Потім, в іншому застосунку, створювався робочий потік, який розкидав картинки на ту структуру, яка була створена. Загалом, процес був досить важким. Використовувався ImageMagick який є на Linux, Windows, MacOS. Ми мали справу з Linux.
Наприклад, в програма була завантажена .tiff картинка розміром 200-300 мб, а з неї потрібно було зробити картинки різних розширень, щось вирізати, або зробити підкладку.
Перша версія програми не справлялася з великим навантаженням, не вистачало навіть сервера з 16 ядерним процесором. Ми поліпшили архітектуру програми для використання декількох екземплярів одночасно, щоб кардинально не змінювати роботу застосунка. Запускалося багато екземплярів, які взаємодіяли між собою і кожен з них обробляв частину завдання. Було складно, але нам вдалося успішно реалізувати все буквально за декілька місяців. І система досі працює. В процесі довелося розбиратися з конкурентністю та різними аспектами взаємодії.
Що з цього проекту все ж можна було перенести на node, але деякі речі все одно довелося б робити на Java, оскільки там було багато різних обчислень. В принципі, ми могли зробити частину на node, яка б викликали певні частини на Java і використовувати мікросервісну архітектуру. Можна було використовувати змішаний варіант. Але цей підхід не завжди працює, бо розробник який спеціалізується на node, може не бути фахівцем в Java і навпаки. А знайти універсальних розробників набагато складніше.
З досвіду на node.js
Був проект по організації великого обсягу даних. Чимось схожий на проект описаний вище. Тільки тут у нас завантажується файл, який містить великий набір інформації і підлягає валідації через сторонній сервіс (написаний на java), кілька разів і за різними правилами. Потрібно було обробляти сотні гігабайт інформації, а node для цього не призначений.
Проектувати архітектуру системи було особливо цікаво, оскільки застосунок складався з кількох мікросервісів, в тому числі сторонніх. При роботі зі стороннім сервісом, який здійснював валідацію, ми використовували RabbitMQ message broker. Ми віддавали сторонньому сервера необхідну інформацію і отримували повідомлення від RabbitMQ після закінчення валідації, потім дані оброблялися по частинах, щоб уникнути out of memory.
І якщо спочатку застосунок обробляв файл, що містить 10000 записів, то тепер може обробляти до мільйона. Нам все ж вдалося вирішити цю задачу за допомогою node.js хоча на Java її можна було вирішити простіше, однак замовник хотів використовувати саме node, оскільки потрібна була єдина інфраструктура та архітектура з мікросервісами написаними на JS. Використовуючи node вирішити завдання було набагато складніше, і вимагало більше часу, але node.js виграє за рахунок масштабування. Саме тому зараз ми можемо нарощувати кількість воркеров і обробляти все більше і більше даних. На Java це відбувалося б складніше.
Насправді, будь-яку задачу можна розв'язати і так і так, але тут варто повторитися: якщо є багато обчислень то краще використовувати Java, якщо обчислень не багато, можна сміливо використовувати node.
Підсумки та перспективи: чи зможе node.js обігнати Java?
Зараз йде до того, що node.js часто буде використовуватися як обгортка, а начинку будуть писати на інших мовах. Його недоліки давно відомі. Наприклад, такий умовний недолік як однопоточність вже виправлено. В останній версії node представлена можливість використання декількох потоків.
Java спочатку створювалася як легковажне рішення що заміняє C++, а тепер стала важкою. Це як еволюція. Можливо, коли-небудь з'явиться щось, що замінить і node.
Модулі — Розвиток Java vs node.js
Зараз, за кількістю замовлень, і за моїми відчуттями, node.js вже обігнав Java.
JS активно розвивається і він буде змінюватися — можливо що прийде йому на зміну.
Зараз не видно потенційного конкурента, який зміг би замінити Java і node.js.
Проблема в тому, що розвиток Java останнім часом йде досить повільно, а node.js розвивається з такою швидкістю, що замінити його найближчим часом не представляється можливим.
Ще немає коментарів