У нас есть большое приложение Ruby on Rails (25 миллионов пользователей в месяц), наше руководство решило переписать в Node.js, я с ума сошел?

Пожалуйста, скажите мне, если:

Node.js сделает наш сайт быстрее!
Node.js будет потреблять меньше ресурсов сервера, мы можем сэкономить деньги!
Node.js сделает нас более продуктивными!
Node.js означает, что мы можем совместно использовать клиентский и серверный JavaScript-код.

Для пояснения мы переписываем интерфейсный сервер, который будет взаимодействовать с нашим существующим приложением Ruby on Rails в качестве API. Тем временем мы реорганизуем наше приложение Ruby on Rails в сервисы.

Подробнее о существующей архитектуре:

Memcached для кэширования HTML-частей
Redis для сессии, и некоторые структурированные данные кэширования
MySQL один мастер, несколько рабов
- Есть одна большая таблица, которая принимает много записей (представьте опрос)
- В противном случае в основном читает.
MongoDB для некоторых метаданных
Ruby on Rails 3.0
nginx и единорог

architecture ruby-on-rails node.js rewrite user88487
источник

блин, все эти хипстерские языки. Хорошо написанное php-приложение легко масштабируется, традиционные инструменты работают, не позволяйте этим хипстерам сказать вам иначе.

Темная ночь

Вопрос должен быть больше похож на «Экономят ли улучшения достаточно денег для бизнеса, чтобы они того стоили?» Это может сэкономить деньги в течение 5 лет, но переписывание обходится дорого и отнимает много времени - если ваш код не является ужасно ужасным беспорядком, я думаю, ваши менеджеры злятся

Mikey C

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

Джори Себрехтс

@Darknight Имейте в виду, что в какой-то момент PHP был хипстерским языком, и люди, показавшие, что его можно использовать в успешных продуктах, способствовали его внедрению, в то время как веб-разработчики Perl хихикали над хипстерами PHP.

Я очень удивлен, что никто не поднял статью Джоэла Спольски. То, что вы никогда не должны делать . Я не говорю, что все переписки плохие, но я согласен с @MikeyC, что к ним следует подходить с особой осторожностью.

Дэн Пичельман,

Ответы:

Большинство вопросов, которые вы задаете, не отвечают без контекста и более или менее спорны, учитывая, что руководство уже сделало выбор за вами ... если только вы не спрашиваете "Должен ли я уйти и найти новую работу перед лицом всех этих изменений" ?

Если вы собираетесь с этим справиться, я рекомендую вам прочитать этот пост на тему: Как выжить с нуля, не теряя здравомыслия .

Недавно я начал переписывать немного серверной логики в node.js. Основная причина в том, что он в настоящее время написан на .NET, и мы хотим перейти от сред MS к следующему.

Мой опыт до сих пор был положительным, у вас будет начальная кривая обучения со всей ее неблокируемостью, но как только вы пройдете мимо этого, на самом деле довольно интересно писать код… Я знаю, ФАН!

Тем не менее, у него есть и темная сторона: каждый мужчина и его собака, которые занимались разработкой интерфейса с помощью JavaScript - и это будет каждый разработчик интерфейса - надеюсь, - немного волнуются, когда вы упоминаете, что node.js - это javascript на стороне сервера. Однако это не означает, что разработчики внешнего интерфейса будут иметь опыт, необходимый для написания хороших серверных приложений.

Одна вещь, которую вы должны учитывать, это то, что фатальная ошибка повредит все приложение из-за его непоточной природы, поэтому ставки немного выше, и вы должны явно проверить и поймать все.

Для тех, кто занимался как спереди, так и сзади - и получал удовольствие от обоих - отсутствие необходимости переключать ментальные контексты с языков на передний план на конечный - это реальный бонус, который, я думаю, в конечном итоге повысит производительность нашей команды в будущем.

dave.zap
источник

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

десять раз

Да, моя главная мысль в этом утверждении состояла в том, что разработчики только переднего конца, как правило, не особенно суетливы, когда дело доходит до обработки исключений. Да ладно, уже почти 2017 год!

dave.zap

Ну, я не думаю, что переписывание приложения было хорошей идеей, если оно не работало плохо. Чтобы ответить на ваши вопросы:

Node.js не волшебство. В вашем приложении огромное количество пользователей, поэтому невозможно быть уверенным, что оно будет работать быстрее.
Да, Node.js на самом деле потребляет меньше ресурсов сервера. Таким образом, вы можете не только сэкономить деньги на ресурсах, но и сделать больше с существующими. Это в основном из-за однопоточной природы Node.js. Нет дополнительных накладных расходов на дополнительные потоки.
Снова Node.js не волшебство. Сказав это, в этом может быть доля правды. Node.js имеет очень активное сообщество, которое создало сотни модулей для каждой возможной задачи. Поэтому вполне вероятно, что большая часть работы была проделана за вас. Вам просто нужно собрать кусочки вместе.
Теоретически да. Поскольку Node.js - это JavaScript, вы можете делиться кодом между клиентом и сервером. Но я не знаю точно, что это будет, что поделится. Я не написал ни одного кода, который можно было бы повторно использовать на клиенте. То, что мы делаем на сервере, обычно не имеет ничего общего с клиентом. Более важным для меня является отсутствие переключения контекста. Мне проще писать код на клиенте и сервере на одном языке.

Поскольку Node.js является однопоточным, если он явно не настроен для этого, он не может использовать преимущества нескольких процессоров .

Посмотрите на комментарии тоже. Они дают некоторое хорошее представление о работе Node.js.

Акшат Дживан Шарма
источник

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

Джо

@ Джо, насколько я понимаю, они будут складываться. В узле j лучше распорядиться запросом как можно быстрее. Либо завершив его за один раз. Или возобновив его в следующий раз. Честно говоря, узел js Это единственная технология, для которой я создал производственные приложения. Так что я, возможно, не лучший человек, чтобы сравнивать ее с другими технологиями на стороне сервера. Именно поэтому я воздерживался от проведения сравнений и просто помещал то, что, как мне кажется, я знаю об узле js, в мой ответ.

Акшат Дживан Шарма

Да, один поток, безусловно, ограничивает использование ресурсов, поскольку сервер может одновременно выполнять только одну операцию в цикле событий. Это также ограничивает использование сервера, потому что он может делать только одну вещь одновременно. Очень важно процитировать функции (однопоточные) и плюсы и минусы, а не просто минусы. Node.js подходит для некоторых целей, но для других это плохая идея. Когда ваш однопоточный сервер узлов имеет проблемы с пропускной способностью, вам, возможно, придется добавить другой экземпляр узла. Теперь у вас есть многопроцессорный сервер.

Джо

Я понимаю, что вы имеете в виду. Я обновлю ответ в ближайшее время (прочитайте после некоторого исследования)

Акшат Дживан Шарма

Дело не только в процессорах. Причина, по которой важно обрабатывать каждый запрос как можно быстрее (в однопоточной системе без другого параллелизма) заключается в том, что сервер не может обслуживать несколько запросов одновременно, поэтому каждый запрос должен ждать, пока вы не закончите обработку всех запросов. запросы перед этим. Параллелизм, выполненный правильно, означает меньше ожидания. Использование потоков по своей сути не снижает производительность, а однопоточность (по умолчанию или иным образом) не является преимуществом производительности.

Питер Хоси