Node.js в PayPal

Представляю вашему вниманию перевод статьи Node.js at PayPal, где инженер PayPal, Jeff Harrell, рассказывается о том как PayPal выбирал инструменты для работы с Node.js, сравнивает разработку на Java и Node.js на примере одного и того же продукта, а так же говорит о будущем Node.js в PayPal.

image

Было много разговоров о переходе PayPal на Node.js, в качестве платформы для разработки. Как продолжение части 1: «освободите мой пользовательский интерфейс», я счастлив сообщить что слухи правдивы и наши веб приложения переносятся с Java на JavaScript и Node.js.

Исторически сложилось, что наша команда разработчиков была разделена на тех кто пишет код для браузера (используя HTML, CSS и JavaScript) и тех кто пишет код для приложения (используя Java). Представьте HTML разработчика который должен был просить у Java разработчика соединить две страницы «А» и «Б». Вот где мы были. Эта система мешала внедрению full-stack специалистов, которые способны создавать невероятный пользовательский интерфейс и выстраивать приложение опираясь на него. Зовите их единорогами, но это то, что нам нужно и главной стеной преткновения в PayPal всегда была граница, которую мы проводили между браузером и сервером.

Node.js помог нам решить эту проблему, позволяя писать браузерную и серверную часть приложения на JavaScript. Это объединяет наших специалистов в одну команду которая позволяет нам понимать и реагировать на потребности пользователей на любом из уровней наших технологий.

Предварительный выбор


Как и многие другие, мы проталкивали Node.js как прототипную платформу. Вместе со всеми качествами, подтвердилась высокая профпригодность, так-что мы мы решили дать ему ход на продакшине.

В наших первых попытках использовались express для роутинга, nconf для конфигурации и grunt для построения задач. Нам особенно нравилась вездесущесть express, но мы находили её недостаточно масштабируемой для многочисленной команды разработки. Express ничего не навязывает и позволяет установить сервер так как ты посчитаешь нужным. Это великолепно для гибкости, но плохо для согласованности в больших командах. Со временем мы видели возникшую закономерность, как много команд выбирали Node.js и оборачивали его в kraken.js; Сам по себе, это не фреймворк, а прослойка поверх express, которая позволяет масштабировать его для больших организаций. Мы хотели, чтобы наши инженеры сосредоточились на создании своих приложений, а не только на настройке их окружения. Мы уже много месяцев используем kraken.js (мы скоро будем открывать его исходный код!), и наши разработчики с нетерпением ждут внедрения Node.js приложений, которые мы построили.

Перенос Node.js на продакшн


Наше первое внедрение Node.js на продакшн не было незначительным приложением; Это была страница просмотра аккаунта, одна из самых просматриваемых страниц на нашем сайте. Мы решили шагать широко, но мы уменьшили риски путём построения такого-же приложения на Java параллельно. Мы знали как развернуть и масштабировать Java приложения, так-что если бы что-то пошло не так с приложением на Node.js, мы бы могли вернуться к нему на Java. Это предоставило основание для очень интересных данных.

Разработка


Мы начали в январе, и нам понадобилось несколько месяцев, чтобы создать необходимую инфраструктуру для того, чтобы Node.js работал в PayPal, например сессии, централизованное логгирование, хранилища ключей. На протяжении этого времени у нас было пять разработчиков, работающих над Java приложением. Спустя два месяца разработки на Java, два разработчика стали параллельно работать над Node.js приложением. В начале июня их дороги пересеклись, приложение имело тот же набор функций; в Node.js приложении, меньшая команда, которая стартовала с двухмесячной задержкой, быстро наверстала упущенное. Несколько деталей который мы изучили после запуска тестов на приложениях, где была протестирована одна и та же функциональность. Node.js приложение было:

  • Построено в дважды быстрее с меньшим количеством людей
  • Написано на 33% меньше строк кода
  • Итоговое приложение имело на 40% меньше файлов

Производительность


Производительность это весёлая и вызывающая много дебатов тема. С нашей стороны, у нас было два приложения с одинаковым функционалом и построенные примерно одинаковыми командами: одно на нашем собственном Java-фреймворке, который основан на Spring и другое на kraken.js, с использованием express, dust.js и другого открытого кода. Приложение состояло из трёх роутов и каждый роут делал 2-5 АPI запросов, управлял данными и рендерил страницы используя Dust.

Мы запустили нашу утилиту для тестинга, используя аппаратное обеспечение с продакшина, которая тестировала роуты и собирала данные по производительности и времени отклика.

image

Вы можете увидеть, что Node.js приложение имеет:

  • В двое больше запросов в секунду в сравнении с Java приложением. Это ещё более интересно потому, что для получения наших внутренних результатов производительности было использовано одно ядро для Node.js по сравнению с пятью ядрами для Java. Мы ожидаем дальнейшего увеличения этой разницы.
  • 35% снижение среднего времени ответа для той же страницы. Это привело к тому, что страницы стали обслуживаться на 200 миллисекунд быстрее — что пользователи точно заметят.

К этим данным прилагается отказ от ответственности: это касается наших фреймворков и двух наших приложений. Это сравнение лицом к лицу, тест производительности который мы можем получить путём сравнения двух технологий, ваши результаты могут отличаться. Тем не менее, мы рады тому, что увидели производительность Node.js в чистом виде.

Будущее


Все наши веб-приложения, ориентированные на потребителя, будут построены на Node.js. Некоторые, как наш портал для разработчиков, уже работает, в то время как другие, например просмотр аккаунта, в бете. Уже более дюжины приложений находятся на стадии переноса и мы продолжим делиться данными по мере выпуска приложений. Это захватывающее время для того чтобы быть инженером в PayPal!
Метки:
Поделиться публикацией
Похожие публикации
Комментарии 26
  • +3

    Оригинал 2013 года, в мире nodejs это геологическая эпоха.

    • +6
      Найден древний манускрипт
  • –1
    Ну вот как всегда. Почему не рассматривали другие языки для JVM?
    Думаю, если бы взяли Clojure, количество строк и файлов и времени потрачено было бы еще меньше…
    И точно так же можно было писать и фронт и бек на одном языке используя «мощь фулстека».
    А сам по себе язык гораздо более технологичен, что безусловно скажется в итоге.
    К тому же замеры производительности вызывают вопросы. На сколько корретно было это сравнение?
    Оптимально ли было написано JVM приложение?
    Что-то я очень сомневаюсь, что JVM настолько проигрывает NodeJS в производительности.
  • +2
    Спустя два месяца разработки на Java, два разработчика стали параллельно работать над Node.js приложением.
    Построено в дважды быстрее с меньшим количеством людей
    Немного не правильное утверждение, т.к. когда задача уже сделана и нужно сделать «точно так же», это всегда будет в 2+ раза быстрее, чем узнать все требования и написать с нуля.

    Да и Java для рендеринга html никогда не была хорошим решением. На ней можно это сделать, но это больше в угоду единому стеку разработки, нежели производительности.
    Для фронтенд-сервера, действительно, лучше использовать что-то типа Node.js, А для API сервера, особенно с тяжелой логикой и/или расчетами, лучше брать компилируемый и типизированный язык (Java, C#, Go).

    ps: но все же к результатам теста в статье есть недоверие. Скорее всего тест был проведен на холодном старте, без прогрева JVM / Node.js, думаю, на прогретой JVM, разница была бы не столь велика.
    • 0
      можете добавить сюда еще:
      одно на нашем собственном Java-фреймворке, который основан на Spring и другое на kraken.js, с использованием express, dust.js и другого открытого кода.

      никто не знает, кто что и как комитил в этот собственный фреймворк.

      Отдельно смущает количество страниц в секунду, неужели там настолько тяжелые вызовы api?
    • 0

      При переписывании всегда будет меньше и быстрее, не важно какая новая платформа.

      • 0

        Я понимаю что это перевод и все таки спрошу. Вы сами понимаете смысл цифр в таблице? Я вот например если правильно понял у paypal было около 8 rps а стало около 15rps. Было время ответа около 1с а стало 600-800 мс. Но я все таки надеюсь что я что-то не так понимаю

        • 0
          Да, конечно. Слева показано количество страниц аккаунта которые грузились за одну секунду, а справа время, которое было на них затрачено. В итоге, к примеру страница /wallet на Node.js за одну секунду грузилась 25 раз, при этом занимало это дело 1189 миллисекунд. В свою же очередь приложение на Java 15 таких же /wallet страниц грузила за 1817 миллисекунд. В итоге 25 страниц за 1189 миллисекунд, против 15 страниц за 1817 миллисекунд.
          Если запутались именно в таблице, то в шапке таблицы (прям под синими столбиками) написано к-во страниц которое загрузилось за секунду, а ниже данные для каждой конкретной страницы.
          • 0

            Я просто к тому что цифры какие-то не серьезные и для Java и для Node.js. К примеру даже на банальном PHP цифры получаются совсем другого порядка. Первая же ссылка в гугле — https://github.com/kenjis/php-framework-benchmark Цифры начинаются от 100 и заканчиваются на 2000 rps. Правильно организованная Java должна брать 2-3k rps

            • +2

              Как я понял понял, по вашей ссылке тест реализаций Hello world в разных фреймворках. Странно это сравнивать с /wallet в PayPal.

              • 0
                Вы путаете синтаксический бенчмарк для тестирования сферических коней, с какой-то реальной бизнес-логикой.

                В статье нету никакой информации про то что приложение выполняет под капотом и какая там реализация. Допустим, если приложение делает 2 запроса на другие сервера (авторизация и получение данных), то при классическом подходе на Spring troughput будет ниже, чем на Node.js, банально из-за того, что все время проведет в ожидании io (но на Spring можно написать такой же асинхронный код, как и на node.js).
                • 0

                  Я согласен что нельзя ожидать что в реальных проектах скорость будет такая же как в синтетике. Просто Вы правда считаете что для реального проекта 15 rps/ 1s на ответ это норма?

                  • 0
                    Согласен, это крайне плохой результат, но про систему ничего не известно.
                    Но это платежная система. Она должна обеспечивать высокий уровень безопасности пользователя, а для этого нужно собрать много метрик и сделать много проверок (девайс, браузер, куки, геолокация, время суток и еще черт знает что). И скорее всего, тот сервер, который они тестировали — лишь проксирует эти данные на другой сервер.
          • –3
            BimBam, Вы автор перевода? Просьба. Перечитайте текст, и перепишите некоторый предложения с «русского языка» на русский язык. И знаки препинания не забывайте… Вроде понимаешь при чтении о чем написано, но приходится перечитывать, чтобы убедиться…

            Это объединяет наших специалистов в одну команду которая позволяет нам понимать и реагировать на потребности пользователей на любом из уровней наших технологий.


            … мы скоро будем открывать его исходный код!...


            И далее по тексту еще есть подобное.
            • 0
              Не верю. Перейти со сверх надежного языка, проекты на котором сопровождать одно удовольствие, на язык, где все работает как у карточного домика, а понять чужой код и уж тем более вести поддержку и развитие проекта практически невозможно, не сулит ничего хорошего. Если банк или финансы, то только Java/С#, другого не дано.
              • +1
                Я думаю, что это сугубо ваше мнение, как Java разработчика. Программисты компании PayPal явно не дураки и прежде чем перенести cамую крупную платёжную систему на планете на другой язык, детально изучили его возможности и уж тем более я не сомневаюсь, что вопрос безопасности там стоял на самом первом месте. Многие мировые лидеры в своих областях используют Node.js и я вас уверяю, это не потому что он такой плохой.
                • 0
                  Я к сожалению не Java-разработчик. У меня 6 лет PHP и 2 года JavaScript. Как раз сомнения что они все хорошенько взвесили прежде чем переходить. В статье даже не говорится что они перешли на TypeScript, значит они перешли на ES2015. Оба языка очень сырые, посмотрите какое количество языков на JVM.
              • 0
                мы что-то измерили, что-то получили… и выяснилось, что node.js в два раза шустрее java…
                шикарный исследовательский подход… особенно радуют выборки — 1 пользователь, 5, 10… серьезно? )))
                а если по существу, делать корректные, воспроизводимые бенчмарки — это не просто замерить время вызова одной странички…
                • 0
                  В этой статье не сравниваются языки. Тут сопоставляются приложения и автор акцентирует на этом особое внимание. От себя добавлю, что только в мире программистов инструмент почему-то играет большую роль, чем мастер. Никогда не слышал чтобы плотники спорили о том, какой молоток быстрее забивает гвозди… Ну быстрее Node.js в данном конкретном случае и быстрее. Автор предупредил, что ваши тесты могут отличаться и не пытается выдать свои наблюдения за неопровержимую истину.
                  • 0

                    Плотники зато знают, какая пила пилит быстрее:)

                    • 0
                      В том то и суть, что не пила пилит быстрее, а тот, в чьих она руках. Сама по себе пила, это просто инструмент, а то как ей пользоваться, это уже дело мастера.
                      • 0
                        смотрите, если использовать аналогию с плотниками: есть молоток для обивки кожи, есть молоток для забивания гвоздей, есть ювелирный молоток — под конкретную задачу свой инструмент… так же и у нас — под каждое приложение может быть использован свой стек технологий…
                        если paypal выяснили, что node.js для них оптимальный выбор — это хорошо, вопросов нет…
                        мой комментарий был акцентирован на то, что представленные графики времени отклика неверно составлены… более показательны были бы графики зависимости latency от bandwidth на всем диапазоне кол-ва запросов — от нулевого до максимального… и при этом стенды испытаний, чтобы были одинаковы…
                        • 0

                          Nope. Есть пила для пиления поперек волокон, есть пила для пиления вдоль и есть универсальные (пилят и так и эдак, но похуже). Но споров не будет — плотники-то знают, какая пила для чего.


                          Правда, у плотников было несколько тысяч лет, чтобы выяснить, какие пилы для чего предназначены, а у программистов и ста лет еще не было.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.