Comment résoudre le service NodeJS qui plante toujours

Cet article vous présentera comment résoudre le problème du plantage constant du service NodeJS. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il sera utile à tout le monde.

Beaucoup de gens ont une telle image, NodeJS est plus rapide, mais comme il est monothread, il est instable, un peu dangereux et ne convient pas à la gestion d'entreprises complexes ; Il est plus adapté aux scénarios commerciaux simples avec des exigences de concurrence élevées.

En fait, NodeJS a un côté "fragile". Une exception "non gérée" générée quelque part dans un seul thread provoquera en effet le crash et la fermeture de l'ensemble de Node.JS. un Le fichier de node-error.js :

var http = require(＇http＇);

var server = http.createServer(function (req, res) {

  //这里有个错误，params 是 undefined
  var ok = req.params.ok;

  res.writeHead(200, {＇Content-Type＇: ＇text/plain＇});
  res.end(＇Hello World
＇);
});

server.listen(8080, ＇127.0.0.1＇);

console.log(＇Server running at http://127.0.0.1:8080/＇);

Démarrez le service et testez-le dans la barre d'adresse et trouvez http://127.0.0.1:8080/ Comme prévu, le nœud s'est écrasé

$ node node-error
Server running at http://127.0.0.1:8080/

c:githubscript
ode-error.js:5
  var ok = req.params.ok;
                     ^
TypeError: Cannot read property ＇ok＇ of undefined
    at Server.<anonymous> (c:githubscript
ode-error.js:5:22)
    at Server.EventEmitter.emit (events.js:98:17)
    at HTTPParser.parser.onIncoming (http.js:2108:12)
    at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:121:23)
    at Socket.socket.ondata (http.js:1966:22)
    at TCP.onread (net.js:525:27)

Quoi ? Quelle est la solution ?

En fait, avec le développement de Node.JS aujourd'hui, s'il ne peut même pas résoudre ce problème, alors personne ne l'utilisera probablement depuis longtemps.

Utilisation d'uncaughtException

Nous pouvons utiliser uncaughtException pour capturer globalement les erreurs non capturées. En même temps, vous pouvez également imprimer la pile d'appels de cette fonction après la capture. empêcher le processus du nœud de se terminer. Par exemple :

process.on(＇uncaughtException＇, function (err) {
  //打印出错误
  console.log(err);
  //打印出错误的调用栈方便调试
  console.log(err.stack)；
});

Cela équivaut à une protection à l'intérieur du processus du nœud, mais beaucoup de gens ne préconisent pas cette méthode, ce qui signifie que vous ne pouvez pas contrôler entièrement les exceptions de Node. .JS.

Utilisez try/catch

Nous pouvons également ajouter try/catch avant le rappel pour garantir également la sécurité des threads.

var http = require(＇http＇);

http.createServer(function(req, res) {
  try {
    handler(req, res);
  } catch(e) {
    console.log(＇
＇, e, ＇
＇, e.stack);
    try {
      res.end(e.stack);
    } catch(e) { }
  }
}).listen(8080, ＇127.0.0.1＇);

console.log(＇Server running at http://127.0.0.1:8080/＇);

var handler = function (req, res) {
  //Error Popuped
  var name = req.params.name;

  res.writeHead(200, {＇Content-Type＇: ＇text/plain＇});
  res.end(＇Hello ＇ + name);
};

L'avantage de cette solution est que la pile d'erreurs et d'appels peut être sortie directement sur la page Web où elle se produit actuellement.

Intégré au framework

Le traitement des réponses HTTP standard passera par une série de Middleware (HttpModule) et atteindra finalement le Handler, comme le montre la figure ci-dessous :




Ces middleware et gestionnaire ont une fonctionnalité dans NodeJS, ce sont toutes des fonctions de rappel, et la fonction de rappel est le seul endroit où Node plantera pendant l'exécution. Selon cette fonctionnalité, il suffit d'intégrer un try/catch dans le framework pour résoudre relativement parfaitement le problème d'exception, et cela n'affectera pas les demandes des autres utilisateurs.

En fait, presque tous les frameworks WEB NodeJS actuels le font. Par exemple, WebSvr

, sur lequel est basé le blog open source OurJS, a un tel code de gestion des exceptions :
<🎜. >

Line: 207

  try {
    handler(req, res);
  } catch(err) {
    var errorMsg
      = ＇
＇
      + ＇Error ＇ + new Date().toISOString() + ＇ ＇ + req.url
      + ＇
＇
      + err.stack || err.message || ＇unknow error＇
      + ＇
＇
      ;

    console.error(errorMsg);
    Settings.showError
      ? res.end(＇<pre class="brush:php;toolbar:false">＇ + errorMsg + ＇

＇) : res.end(); }

Qu'en est-il des erreurs qui ne sont pas générées lors des rappels ? Ne vous inquiétez pas, en fait, un tel programme de nœuds ne peut pas du tout être démarré.

De plus, le propre cluster du nœud a également une certaine tolérance aux pannes. Il est très similaire au worker de nginx, mais consomme un peu plus de ressources (mémoire) et la programmation n'est pas très pratique.

Protégez le processus NodeJS et enregistrez les journaux d'erreurs

Le problème du plantage de Node.JS en raison d'exceptions est désormais fondamentalement résolu. Cependant, aucune plate-forme n'est fiable à 100 %, et il en existe encore. erreurs. Certaines exceptions levées depuis la couche inférieure de Node ne peuvent pas être interceptées par try/catch et uncaughtException. Lors de l'exécution de ourjs auparavant, je rencontrais parfois des exceptions de lecture de flux de fichiers émises par la couche sous-jacente. Il s'agissait d'un BUG de la libuv sous-jacente qui a été corrigé dans la version 0.10.21.

Face à cette situation, nous devrions ajouter un processus démon à l'application nodejs afin que NodeJS puisse être relancé immédiatement après avoir rencontré un crash anormal.

De plus, ces exceptions doivent être enregistrées dans le journal afin qu'elles ne se reproduisent plus jamais.

Utiliser le nœud pour garder le nœud

node-forever fournit une fonction de garde et une fonction de journalisation LOG.

Il est très simple à installer

[sudo] npm install forever

Il est également très simple à utiliser

$ forever start simple-server.js
$ forever list
  [0] simple-server.js [ 24597, 24596 ]

Vous pouvez également lire le journal

forever -o out.log -e err.log my-script.js

Utiliser shell pour démarrer le script pour garder le nœud

Utiliser un nœud pour garder la ressource peut être un peu coûteux et un peu compliqué. OurJS démarre le script directement au démarrage pour garder le thread du processus.

Par exemple, le fichier de démarrage ourjs placé dans debian : /etc/init.d/ourjs

Ce fichier est très simple, avec uniquement les options de démarrage. La fonction principale du garde est composée. d'une boucle infinie while true; Pour éviter que trop d'erreurs ne bloquent le processus, le service est redémarré toutes les 1 seconde après chaque erreur

WEB_DIR=＇/var/www/ourjs＇
WEB_APP=＇svr/ourjs.js＇

#location of node you want to use
NODE_EXE=/root/local/bin/node

while true; do
    {
        $NODE_EXE $WEB_DIR/$WEB_APP config.magazine.js
        echo "Stopped unexpected, restarting 

"
    } 2>> $WEB_DIR/error.log
    sleep 1
done

L'enregistrement du journal des erreurs est également très simple, directement dans le processus console Affichez simplement l'erreur dans le fichier error.log : 2>> $WEB_DIR/error.log Dans cette ligne, 2 représente l'erreur.

Apprentissage recommandé :

Tutoriel vidéo javascript

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!