Quelle est l'architecture Node.js correcte?
Je suis un peu confus au sujet de l'architecture de Node.js
Le premier est correct ou le second? Parce que dans le deuxième diagramme, chaque appel passe d'abord par la V8, puis par les liaisons Node.js, mais dans le premier, c'est l'inverse. Pouvez-vous s'il vous plaît aider à comprendre. Merci d'avance.
Tout d'abord, les deux graphiques sont corrects bien que le premier soit un peu dépassé. La partie ascynchrone de Node.js était constituée de libev, libeio et libuv. Cependant, au fur et à mesure que libuv progressait au cours des dernières années, " [dans] la version node-v0.9.0 de libuv libev a été supprimée ", laissant libuv pour s'occuper de l'intégralité de I asynchrone de Node.js/O processus (incluant donc bien sûr la boucle d'événement). Ainsi, la version moderne de l'architecture Node.js remplacerait "libeio" et "libev" par "libuv" (comme dans la deuxième image).
La raison pour laquelle les deux graphiques diffèrent dans leur structure est qu'ils sont organisés en fonction de perspectives différentes. Le graphique 1 représente la classification de différents éléments de la technologie Node.js de haut niveau à bas niveau (donc cela n'implique pas un flux de travail); tandis que le graphique 2 est le flux de travail réel d'une opération Node.js.
Pour mettre cela dans une analogie: disons que vous essayez de représenter différentes pièces d'une voiture à l'aide de graphiques. Vous pouvez le faire de plusieurs façons: vous pouvez soit organiser les différentes pièces selon leurs classifications/fonctionnalités (scénario A), ainsi:
- système d'alimentation : moteur, huile, refroidissement, échappement, etc.
- système de transmission : boîte de vitesses, arbre, ensemble d'embrayage, différentiel, etc.
- système de suspension : bras de commande, amortisseur, composants de direction, etc.
- ......
ou vous pouvez également organiser les pièces par workflow (scénario B):
- huile -> moteur -> transmission -> différentiel -> suspension -> etc.
(Je ne sais pas trop en détail sur les voitures. Le nom des pièces et le flux de travail réel peuvent être faux. Il est uniquement répertorié pour aider à la compréhension.)
Maintenant, parce que les moyens par lesquels vous organisez les pièces sont différents, l'ordre dans lequel ils apparaissent différera également. Le scénario A est similaire à votre graphique 1 et le scénario B est similaire au graphique 2.
Je ne sais pas dans quelle mesure vous comprenez le fonctionnement de Node.js, je vais donc donner un bref aperçu des différents éléments qui s'intègrent dans l'architecture Node.js avant de continuer pour expliquer la façon dont ils interagissent les uns avec les autres:
V8 - Moteur JavaScript open source de Google qui réside dans les navigateurs Chrome/Chromium. Au lieu d'interpréter le code JavaScript à la volée comme le font les navigateurs Web classiques, V8 traduit votre code JS en code machine afin qu'il soit rapide. La V8 est écrite en C++. En savoir plus sur le fonctionnement de V8 ici .
libuv - libuv est à l'origine développé pour fournir des E/S asynchrones qui incluent asynchrones TCP Sockets & UDP, boucle d'événements (célèbre), résolution DNS asynchrone, lecture/écriture du système de fichiers, etc. libuv est écrit en C. Voici un bon vidéo à vérifier pour en savoir plus sur libuv.
Autres composants de bas niveau - tels que c-ares , analyseur http , OpenSSL , zlib , etc., principalement écrits en C/C++.
Application - voici votre code, vos modules et Node.js ' modules intégrés , écrit en JavaScript (ou compilé en JS via TypeScript, CoffeeScript, etc.)
Liaison - une liaison est essentiellement un wrapper autour d'une bibliothèque écrite dans une langue et expose la bibliothèque à des codes écrits dans une autre langue afin que les codes écrits dans différentes langues peut communiquer.
Maintenant, le premier graphique devrait avoir du sens: en haut se trouve votre application (, modules et modules intégrés Node.js de base) écrite en JavaScript; en bas se trouvent les composants internes de Node.js écrits en C/C++. Pour les relier afin qu'ils puissent communiquer, vous avez besoin de liaisons. C'est donc là que les liaisons Node.js se situent: entre l'application de haut niveau et les composants de bas niveau Node. Ces graphiques ne représentent pas nécessairement le flux de travail; c'est juste une classification des différentes pièces Node.js selon à leurs relations/fonctionnalités les uns aux autres.
Le deuxième graphique représente le flux de travail réel d'une application Node.js. Le code écrit dans votre application est compilé par V8. Le code communique avec les composants Node.js de bas niveau via des liaisons. Tous les événements écrits dans votre code sont enregistrés sur Node.js. Une fois les événements déclenchés, ils sont mis en file d'attente dans la file d'attente des événements en fonction de l'ordre dans lequel ils sont déclenchés. Tant qu'il reste des événements dans la file d'attente d'événements, la boucle d'événements continue de les récupérer, d'appeler leurs fonctions de rappel et de les envoyer aux threads de travail pour traitement. Une fois qu'une fonction de rappel est exécutée, son rappel est à nouveau envoyé à la file d'attente d'événements, en attendant d'être repris par la boucle d'événements.
Une partie de votre confusion peut provenir du choix des termes techniques utilisés dans le deuxième graphique. Si vous regardez de plus près, sous "NODE.JS BINDINGS" dit "(NODE API)", qui, malheureusement, sont deux choses différentes. Node.js API est l'interface de ses bibliothèques intégrées, tandis que bindings , du point de vue de la programmation logicielle, sont des ponts entre des codes écrits dans différents langages.
J'espère que ça aide.
Une représentation plus précise de la structure interne de Node.js est la suivante: 
(J'ai téléchargé cette image à partir d'une source sur Internet il y a quelque temps et j'ai oublié d'où elle vient. Si la photo vous appartient, veuillez commenter et j'ajouterai du crédit en dessous! Merci!)
Edit: J'ai récemment écrit un article plus complet pour expliquer architecture de Node.js avec une analogie facile à comprendre. Je souhaite que cela puisse aider!