Производительность NodeJS - несколько маршрутов против отдельных маршрутов

Question

Я создал одну конечную точку в Node.js.

Ниже приводится конечная точка:

app.post('/processMyRequests',function(req,res){

switch(req.body.functionality) {
    case "functionalityName1":
        jsFileName1.functionA(req,res);
        break;
    case "functionalityName2":
        jsFileName2.functionB(req,res);
        break;
    default:
        res.send("Sorry for that");
        break;
}
});

В каждой из этих функций выполняются вызовы API, затемданные обрабатываются, и, наконец, ответ отправляется обратно.

Мои вопросы:

1. Поскольку Node.js по умолчанию обрабатывает запросы асинхронно, можем ли мы иметь единый маршрут для всех ответов?
2. Будет ли параллелизм проблемой, т. Е. Когда параллельные попадания происходят на одном маршруте, Node.js остановится или замедлится?
3. Если ответ на вопрос (2) - ДА, как будетоно меняется, когда у меня есть отдельные маршруты, т.е. если на конкретный маршрут поступает одинаковое количество запросов, тогда это будет та же проблема, верно?

Был бы рад, если бы кто-то мог использовать использование в реальном временислучаев.Спасибо

Answer 1

1. Технически вы можете иметь единый маршрут для всех ответов, но считается «лучшей практикой» для создания конечных точек, которые являются компактными, ясными в том, что представляет собой предполагаемая функция / назначение, и не слишком сложными; в вашем примере может быть много возможных ветвей кода, которые может пройти маршрут. Это требует уникальной логики для каждой ветви, что увеличивает сложность ваших конечных точек и лишает ясности кода. Представьте, что при возникновении ошибки вам теперь нужно отладить потенциально несколько разных файлов и разных веток вашей конечной точки, когда вы могли бы создать отдельную конечную точку для каждой уникальной «ветки».
   • Поскольку ваше приложение растет как по размеру, так и по сложности, вам понадобится простой способ управления вашим API. Помещение множества вещей в одну конечную точку станет для вас кошмаром для обслуживания и отладки.
   • Для вас может быть полезно взглянуть на некоторые учебные пособия / документы о том, как разрабатывать и реализовывать API, вот хорошая статья из Scotch.io

Пример для первого вопроса:

// GET multiple records
app.get('/functionality1',function(req,res){
   //Unique logic for functionality
});

// GET a record by an 'id' field
app.get('/functionality1/:id',function(req,res){
   //Unique logic for functionality
});

// POST a new record
app.post('/functionality1',function(req,res){
   //Unique logic for functionality
});

// PUT (update) a record
app.put('/functionality1',function(req,res){
   //Unique logic for functionality
});

// DELETE a record
app.delete('/functionality1',function(req,res){
   //Unique logic for functionality
});

app.get('/functionality2',function(req,res){
  //Unique logic for functionality
});
...

Это дает вам гораздо более четкое представление о том, что происходит для каждой конечной точки, вместо необходимости переваривать много технически несвязанной логики в одной конечной точке API. Подводя итог, лучше иметь конечные точки, которые являются ясными и краткими по своему назначению и объему.

2. Это действительно зависит от того, как реализована логика; Очевидно, Node.js является однопоточным. Это означает, что он может обрабатывать только 1 «поток» кода за раз (без истинного параллелизма или параллелизма). Однако Node справляется с этим через цикл обработки событий . Проблема, с которой вы можете столкнуться, зависит от того, написали ли вы асинхронный (неблокирующий) код или синхронный (блокирующий) код . В Node почти всегда лучше и рекомендуется писать неблокирующий код. Это помогает предотвратить блокировку цикла событий, что означает, что ваше приложение узла может выполнять другие действия, например, ожидая завершения чтения файла, вызова API или выполнения обещания. Написание кода блокировки приведет к «горению» вашего приложения, что воспринимается вашими конечными пользователями как более высокая задержка

3. Наличие нескольких маршрутов или одного маршрута не решит эту проблему. Это больше о том, как вы используете (или не используете) цикл обработки событий. Чрезвычайно важно максимально использовать асинхронный код.

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

Некоторые чрезвычайно полезные ресурсы:

• Node.js Express Best Practices
• ОТЛИЧНОЕ видео, объясняющее цикл событий
• Параллелизм и параллелизм в Node.js
• Node.js кластеризация
• API Design