Каковы потенциальные сложности/проблемы, уникальные для большого приложения NodeJS

Ответ 1

Я постараюсь ответить на некоторые из ваших вопросов.

Насколько хорошо он поддается развитию большой команды? Какие уникальные проблемы существуют для Node, в команде из 20 или 50 или 200 разработчиков?

• Он делает то же самое, что и любой другой язык; ничего! Команды программистов обычно используют системы управления версиями, такие как git, svn, mercurial и т.д. Для работы с коллегами, работающими над одними и теми же файлами.

Какие уникальные проблемы существуют в отношении доступа к базе данных? Проблемы с доступом к данным "Enterprisey" обрабатываются в основном тривиально в Java (пулы подключений, безопасность и т.д. Через Spring). В этом случае с Node?

• Node является агностиком базы данных. Вы можете использовать любую базу данных с node, где для нее существуют драйверы/оболочки (такие же, как и для PHP). Существует множество драйверов/оболочек для реляционных баз данных (MySQL, SQLite) и NoSQL (MongoDB).

Для приложений с высокой степенью отчетности часто требуется Excel, PDF, даже экспорт PNG... Как node тариф в этом типе приложений?

• Node может, как и php и другие, обращаться к нормальной оболочке. Поэтому, если вы обрабатываете изображение с помощью php, вы используете обертку для ImageMagick или GD. GD необходимо установить на WebServer, чтобы он работал, поскольку php отправляет команды в командную строку. То же самое с node; найдите обертку (http://search.npmjs.org) и используйте желаемую функцию.

Предоставляет ли node какие-либо уникальные проблемы в отношении отладки времени разработки?

• Node - это Javascript, поэтому он не компилируется, а делает JIT. Таким образом, сбой будет обнаружен только как только он будет выполнен. Вы хотите, чтобы локальный env для каждого разработчика рядом с вашим стажером/dev-машиной и живыми серверами, чтобы они могли протестировать код до его передачи на промежуточном сервере.

Какие существуют уникальные проблемы с операциями? Все, начиная с перезагрузки сервера и сводного обмена с горячим кодом/балансировки нагрузки на инструменты для мониторинга и управления производственным кластером.

• Нет "уникальных" вызовов, о которых я знаю. Вы будете иметь дело с мониторингом/сердцебиением, как со всеми другими языками (да, есть языки, которые делают это, как Эрланг). Вам понадобится служба, как навсегда, или супервизор для запуска node на перезапуске сервера, но то же самое с Apache + PHP/Perl.
• (Node имеет модуль Cluster, который помогает вам обрабатывать несколько сотрудников (для многоядерных серверов))

посмотрите Git для управления кодом. И выберите язык, основанный на том, что вы хотите делать (высокий concurrency, масштабируемость)

Ответ 2

Я буду комментировать вещи, для которых я компетентен:

• Объединение пулов в источники данных. Стандартные серверные инструменты Node HTTP (S) реализуют пул по умолчанию, и есть кнопки, которые вы можете настроить для улучшения или контроля производительности. Сообщество очень активно, есть много других проектов (например poolee), которые реализуют либо универсальные или специализированный пул соединений. Вам нужно будет осмотреться. Фактически, учитывая ваш традиционный фон Webdev...

  1.1 Sidenote: сторонние библиотеки При разработке Node вы можете использовать множество сторонних библиотек. в зависимости от вашего конкретного фона это может показаться странным. Чтобы понять, почему, рассмотрим .NET или Java: стандартные библиотеки для этих платформ являются гигантскими. В результате при использовании этих платформ вы можете выбрать очень мало сторонних инструментов или плагинов, чтобы помочь вам выполнить свою работу. Node, для сравнения, имеет намеренно узкую и строго контролируемую стандартную библиотеку. Все необходимые API для унификации "того, как все написано" в интересах производительности сервера есть, но не более.

  Чтобы управлять внешними библиотеками, менеджер пакетов npm был разработан и включен очень рано с node. Известно, что он имеет высокое качество. Авторы явно ожидали много стороннего использования.

• Вычислить мощность Вы упомянули об экспорте изображений. Библиотеки Javascript для всех этих вещей существуют, так как "это можно сделать легко", это возможно. Имейте в виду, что если у вас есть сложная задача, Javascript может быть не самым эффективным языком для реализации основного вычисления. Двигатель v8 позволяет вам писать модули на C, если вам нужно, но пересылка запроса на специализированный серверный сервер - это то, что Node работает очень хорошо.

• Проблемы с операциями Node.js не будет масштабироваться до вашего оборудования. Если ваш сервер имеет несколько ядер (что, безусловно, уже сейчас), вам нужно будет запускать несколько серверных процессов на одном физическом оборудовании для достижения высокого уровня использования. Это может сделать другое изображение для операций: намного больше процессов, чем вы обычно видите, эти процессы могут быть сгруппированы по физической или виртуальной машине.

  Разрыв вашего сервера в процессах - это не плохо для надежности, кстати: один большой традиционный процесс выйдет из строя на необработанном исключении, сбив с него восемь (или что-то еще) сердечников для активных сеансов. Несколько процессов Node все равно будут разбиваться по отдельности, но с пропорционально меньшим воздействием. Вероятно, есть место, чтобы исследовать суть "сколько процессов слишком много?", Учитывая как производительность, так и контролируемость. На самом деле может стоить использовать более Node процессов на сервер, чем есть доступные ядра.