Java ( с либами ) против Node.js, что выбрать для вебсервиса?
Добрый день,
Раньше филосовски относился к тому, как сторонники Ноды рвут глотки, что мол через год все пересядут с джавы на нее, ибо она неблокирующая, пока для меня самого не встал вопрос ребром. Суть:
Инвестор хочет замостырить веб-сервис по расчету грузоперевозок ( вбиваешь 2 города, параметры груза, жмешь кнопку, ждешь, глядишь результат), при этом в расчетах юзаются вебсервисы сторонних контор ( и потом их предложения в результатах есть)
При этом какая то редиска насикала ему в уши, что Нода асинхронна ( и картинку показал, ту самую, где запрос в ней выполняется 10 наносек)
Короче, надо ему доказать, что Java ( не голая естественно, а соотв либами) не хуже, а лучше ( + многопоточность из коробки)
Подскажите, если возьму Nginx + Apache + Spring 5 + REST + AKKA ( или Vert.X) + NIO , то на всем этом же можно сделать асинхронную обработку? Собственно Spring 5, AKKA ( или Vert.X), NIO - это и есть все неблокирующее. Это точно заменит Node.js?
( и доп вопрос: в Spring 5 случаем не встроен уже NIO ?)
Если не докажу ему, то будем делать на Ноде, недостатки очевидны, спецов мало, случись что с теми, кто напишет это, будет ппц, кто всю эту лапшу колбечную ( да знаю, там промисы уже и асинки, но тоже не сахар) будет поддерживать...
Спасибо
вот собственно, та гадская картинка, которая инвестору пришлась по сердцу. Что на нее ответить, чтобы ему было доступно, причем приводить конкретные примеры с технологиями, которые тоже асинхронны в джаве.
Алексей Помогаев, извиняю, но инвестор говорит, докажи что это булшит. Действительно, залить меду в уши легко, говоришь, что вот мол асинхронный фреймворк берет таску, отправляет куда надо, и идет обслуживать следующий запрос. А джава берет поток из пула и синхронно выполняет, т.е. не обслуживает следующий, пока не выполнит этот. Что на это возразить? причем надо простыми словами, чтобы инвестор понял.
В Java также есть асинхронное IO, называется NIO. Вот, например, фреймворк vertx.io Сервлеты также поддерживают асинхронность (гуглите подробности startAsync). Есть и асинхронный доступ к БД, но нужно искать сторонний фреймворк. Официально асинхронное JDBC будет только в 10-ке в марте этого года. Но в целом хватает создание пула соединений через вот это https://brettwooldridge.github.io/HikariCP/
Т.е. здесь джава как и нода отдаёт поток другим задачам, пока текущая задача ожидает IO.
Асинхронность для не IO задач не имеет смысла. Т.к. следующие задачи просто некому обслуживать - все процессоры и так заняты обработкой текущих задач.
А доказательства я уже приводил вам - конкретные бенчмарки. Либо самостоятельно запустите тест и нагрузите HelloWorld на ноде и на джаве. И покажите инвестору.
Очевидно что когда начинаются разговоры такого вида - то это просто не ваш клиент. Если же клиент платит за свои хотелки, тогда в чем собственно вопрос?
Александр Таратин, Он не мой клиент, он мой работодятел. Он же инвестор. Короче он хочет понять на пальцах, как на Джаве сделать то же самое, что на Ноде. Можно ли? Если нельзя - то делать на Ноде. Если можно - то разрешит делать на Джаве, потому что в дело вступит аргумент, что джавистов больше на рынке, и если что всегда найдем кто продолжит поддерживать продукт
InoMono, Он не программист, он увидел картинку
а теперь я должен развенчать миф этой картинки. Либо покориться этой картинке и делать все на ноде ( основы я знаю, остальное команда выучит за пару недель, а кто не выучит, тех заменят на людей с улицы)
ericcartman, Так ведь на картинке сравнивается системный вызов со временем запроса по сети. Чего тут объяснять то.
Сам я ноду конечно больше люблю. Но на картинке бред какой-то уж совсем.
Александр Таратин, Ну хорошо, картинка допустим бред, но так или иначе придется ему объяснять, как на джаве сделать не хуже чем на ноде.
Если нельзя - то делать на Ноде. Если можно - то разрешит делать на Джаве, потому что в дело вступит аргумент, что джавистов больше на рынке, и если что всегда найдем кто продолжит поддерживать продукт
Он не мой клиент, он мой работодятел. Он же инвестор. Короче он хочет понять на пальцах, как на Джаве сделать то же самое, что на Ноде. Можно ли? Если нельзя - то делать на Ноде. Если можно - то разрешит делать на Джаве, потому что в дело вступит аргумент, что джавистов больше на рынке, и если что всегда найдем кто продолжит поддерживать продукт
Можно написать маленькую проверку-демонстрашку. Сравнить и Java и Node.
На NodeJS - разработчиков дешевых больше. Так как из фронтендеров можно набрать - коих много очень. Если мерять не по самым дешевым, то да, на Java их больше. Но не самых дешевых.
Вообще это идиотизм, в случае сложного проекта решает квалификация конкретного разработчика и конкретная архитектура проекта.
Инструмент - вторичен.
Точнее инструмент - это выбор разработчика.
Посадите человека работать за то, что он хуже знает - никакой "типа крутой" инструмент не спасет
Я ничего не нахожу нелогичным когда два высоковалифицированных и безусловно разбирающихся в теме человека как вы и инвестор определяете архитектуру, выбираете инструмент - и под это уже подбираете разработчиков.
Но в данном случая, я так понимаю - ни вы ни он специалистом не являетесь.
Гораздо логичнее нанять специалиста, который и разработает архитектуру.
ericcartman, что до картинки, то есть куча мест, куда нужно воткнуть этот Non-Blocking, чтобы у вас все было хорошо.
Подспудно по цифрам догадываюсь, что речь идет о фронтенде (250ms - считается границей комфорта при загрузке страницы в веб-браузере) - и картинка иллюстрирует результаты параллельной загрузки страницы.
То есть к бэкенду она имеет слабое отношение. На бэкенде цифры, как правило значительно меньше. Он не тормозит настолько.
То есть такой проблемы на бэкенде в принципе быть не может. Если уж совсем криво не написать.
Вообще это идиотизм, в случае сложного проекта решает квалификация конкретного разработчика и конкретная архитектура проекта.
Нету конкретного разработчика, нету архитектуры. Есть идея бизнеса, деньги и связи инвестора. Остальное - дело техники. Вот это "дело техники" надо быстро решить, начать нанимать Нод-щиков, или Джавистов.
плохо у вас будет или хорошо решает не картинка эта
а насколько плохо или хорош будет конкретный разработчик
насколько хорошую или плохую он сделает архитектуру.
не вижу в описании задачи ничего такого сверх.
вполне можно сделать и на PHP, к примеру
и если сделать хорошо, то будет летать.
хотя лично я выбрал бы Go
хотя, с учетом дефицита квалифицированных разработчиков
(а больше количество на рынке только недоделанных разработчиков)
- по моему выбор языка программирования вообще вторичен.
InoMono, Да, так и есть. Но уже просто уже взяло зло на эту ноду, хочется разобраться. Неужели на джаве нельзя сделать то же самое, что на Ноде? Нода приняла запрос, допустим там есть запрос к БД. Кому она отдает работу? Потоку из пула потоков своего процесса? Или какое то чудо происходит под капотом? Тут большая разница, потоков не может быть 10К
Александр Таратин, Спасибо, разобрался, для I/O операций Нода юзает libuv, которая работает асинхронно. Netty умеет то же самое, что радует ( подробности не скажу, но то ли epoll она использует, то ли ту же самую libuv, если под линуксом запущено).
Осталось разобраться с запросами к БД. Как я понял у Ноды кроме основного треда, которые реактивно берет запросы от юзера и накидывает их в libuv, есть еще threadpool. Что юзается при запросах к БД ? libuv или как раз потоки из threadpool ( их там 4 вроде), которые уже синхронно обращаются к БД ( и если все 4 повиснут на тяжелых запросах, то Нода перестанет ходить в БД, пока один из них не освободится)
Так?
ЗЫ: пул там есть все таки
ЗЫЫ: ну пусть не в самой Ноде, неважно, важно разобраться, блокнется Нода на тяжелых запросах к БД или нет
Запрос к базе зависит от модуля который используем. В основном есть пул соединений к базе по сокету.
При запросе пользователя берем свободный коннекшн из пула или создаем новый или ждем пока появиться свободный (если насоздавали уже кучу соединений) - ну и делаем запрос через него.
Пример для mysql https://github.com/mysqljs/mysql#pooling-connections
libuv has a default thread pool size of 4, and uses a queue to manage access to the thread pool - the upshot is that if you have 5 long-running DB queries all going at the same time, one of them (and any other asynchronous action that relies on the thread pool) will be waiting for those queries to finish before they even get started
А для I/O libuv юзает нативные функции ОС, которые умеют действительно асинхронно работать. Netty так же работате, поэтому ответ на первоначальный вопрос: берешь Netty ( а значит и Vert.x или AKKA) и Nodejs идет лесом, ибо все остальное( фрейморки и тп) в джаве реализовано так, что никакая нода и рядом не стояла
На картинке присутствует запрос, но отсутствует ответ. Нужно ее дорисовать таким образом что бы показать что вызывающая система во 2м случае тратит 10 ns на вызов, но все так же ждет результата как и первая система.
В Spring 5 есть WebFlux, который работает поверх Netty. А Netty это такой замечательный асинхронный фреймворк, про который один из инженеров Netflix'а писал, что у них один инстанс держит в среднем 20 000 одновременных соединений, пропуская через себя 40 Гбит/с трафика. На хабре ещё была статейка про написанную на Netty систему управления IoT-устройствами, которая обрабатывает 980 000 соединений с секунду, работая при этом на двух DO'шных VPS'ах за 20 и 40 баксов в месяц.
ericcartman, ну зря вы совсем безапелляционно проводите равенство между NIO и Netty. Для некоторого класса задач можно и на чистом NIO написать код, будет быстрее, хоть и сложнее.
Да, в Spring 5 WebFlux уже встроен Netty и никаких дополнительных телодвижений не требуется.
А зачем ему эта асинхронность? Я быначал с требований к системе. Ведь асинхронность можно реализовать разными способами. Например, очередью и обратным вызовом. Маштибороваться легко будет. Все должно идти от бизнес задачи. Тогда не получиться - сделали асинхронность ради асинхронности.
Крутость асинхронности - это, к сожалению маркетинг. Нода однопоточная, асинхронность - это так, чисто разделение вашего пользовательского кода и операций ввода/вывода. Да, есть форки, но это все равно отдельные процессы без общей памяти, да в es9 есть shared memory, но это на порядки более куцее решение, чем говорят о нем.
Асинхронный код для нано сервисов может быть и не плох, исключительно за счет скорости имплементации, но на лонг ране - это домоклов меч. Банально, у вас в одном из промисов происходит исключение, как вы определите что не так? Только догадки, так как это произойдет в следующем тике, а там основная часть стектрейса уже потеряна. Я уже молчу про кровь из глаз при покрытии асинхронного кода тестами.
К сожалению "мне тяжело", "не могу", "потерял", "у меня кровь из глаз", "как мне определить" - не аргументы для инвесторов, на это ответ один: ты программист, ты и разберись. Считай что ты гонщик, я тебе даю супер быстрый кар ( а по картинке см ниже так и получается: суперкар, да и и только!). Не можешь ездить на суперкаре, значит найдем того, кто может, но нам надо обогнать конкурентов, а ты предлагаешь пересесть на медленный, не чувак, не покатит. Не можешь программировать - иди на стройку. Вот такой ответ у инвестора, проверено неоднократно. Тут надо именно улыбнуться и на пальцах объяснить, почему эта картинка - фуфло для малограмотных
ericcartman
> "мне тяжело", "не могу", "потерял", "у меня кровь из глаз", "как мне определить" - не аргументы для инвесторов
Согласен, аргумент для инвесторов - дороговизна поддержки и расширения будет расти экспоненциально времени
аргумент для инвесторов - дороговизна поддержки и расширения будет расти экспоненциально времени
Нет, подозреваю ( если ошибаюсь, прошу прощения) Вы мало общались с бизнесменами нашими. Как правило, это люди "внезапно" ( менее 10 лет) разбогатевшие. Им надо все и сразу. Когда-то что-то пойдет не так, если все щас будет зашибись ( см картинку выше ) в их сознании занимает место мизерное.
В общем, надо здесь и сейчас объяснить ему, как работает Node.js, и как средствами Java и многочисленных инструментов достичь той же асинхронности. А после этого уже аргумент, что джава программеров в 10 раз больше на рынке уже пройдет. Но главное - первая часть. Разрушить миф этой дурацкой картинки
К сожалению "мне тяжело", "не могу", "потерял", "у меня кровь из глаз", "как мне определить" - не аргументы для инвесторов, на это ответ один: ты программист, ты и разберись.
Вся эта "кровь из глаз" - это просто время и стоимость разработки.
Этот язык инвесторы хорошо понимают.
Не можешь программировать - иди на стройку. Вот такой ответ у инвестора, проверено неоднократно.
Инвесторы, которые выбирают тебе инструмент?
Может быть у них другие соображения?
Скажем потому что 30% проекта уже реализовано на Ноде и они предпочитают не распылаться по разным технологиям - это я понимаю.
Как правило, это люди "внезапно" ( менее 10 лет) разбогатевшие. Им надо все и сразу. Когда-то что-то пойдет не так, если все щас будет зашибись ( см картинку выше ) в их сознании занимает место мизерное.
Вы абсолютно неправы.
Эти люди как раз сами заработали, а не их предки.
И они прекрасно понимают, что потерять также легко.
Простой
Простой
