Un résumé de ce dont je parlais dans une communauté technique, Slack.
Soyez prudent car il contient probablement des spéculations.
J'utilise généralement aiohttp Server lors du développement d'applications Web en Python.
main.py
from aiohttp import web
from app import app
web.run_app(app)
Je crée presque toujours un fichier comme celui-ci, et quand je l'exécute en production, je lance juste python main.py (dans le conteneur Docker). Ce n'est pas difficile, il exécute simplement une application Web.
Cependant, lorsque je développais des applications Web avec Flask auparavant, j'utilisais un serveur appelé uWSGI pour l'exécuter en production.
Qu'est-ce que c'est? Pourquoi aviez-vous besoin d'uWSGI à ce moment-là et pas cette fois?
Non, je sais que "WSGI est l'interface pour les applications Web et uWSGI est l'une de ses implémentations".
Il était une fois, lorsque j'écrivais une application Web en Perl (Amon2), j'utilisais Plack (serveur PSGI), et quand je l'écrivais en Ruby (Sinatra), j'utilisais Unicorn (serveur Rack). Les langues que j'ai touchées dans le passé ont un mécanisme similaire. Mais ce n'était pas dans Node.js + Express. [^ pm2] Quelle est la différence entre Node.js et d'autres langages?
[^ pm2]: J'utilisais pour toujours et pm2 pour la surveillance des processus, mais je les ai ignorés cette fois parce qu'ils sont différents.
Pour résumer les questions, cela ressemble à ceci.
Autant que je sache, la conclusion est ** "Parce que le framework d'application Web parle ou ne parle pas HTTP" **.
Plus précisément:
[^ express]: Pour être précis, l'application Express est servie avec le module http standard Node.js, mais elle ne définit pas d'interface unique comme WSGI, donc elle dit qu'elle parle directement HTTP. Ce n'est pas une exagération (je pense) [^ flask]: Flask semble parler HTTP parce qu'il a une fonction serveur intégrée (ʻapp.run () `), mais c'est une implémentation de serveur WSGI après tout, et c'est une implémentation simple, donc elle convient à une utilisation en production. Non [^ aiohttp]: Puisque aiohttp Server est un "module qui gère HTTP avec asyncio" plutôt qu'un "framework d'application Web", il est étrange que vous deviez parler HTTP.
Les applications qui ne parlent pas HTTP ne peuvent pas s'exécuter seules et doivent être associées à un serveur Web compatible. [^ a]
[^ a]: J'avais mal compris que tous les frameworks listés ci-dessus étaient capables de parler HTTP et supportaient également des interfaces comme WSGI.
Alors, pourquoi certains frameworks parlent ou ne parlent pas HTTP?
Il semble que c'est parce que "le serveur Web et l'application Web doivent être séparés (l'application Web elle-même n'a pas besoin de parler HTTP)".
Les serveurs Web doivent traiter un grand nombre de requêtes HTTP à grande vitesse, et il est coûteux et coûteux pour chaque framework d'implémenter un serveur pour le réaliser. Une fois que vous avez une interface comme WSGI, vous pouvez séparer le serveur Web et l'application Web et les utiliser dans n'importe quelle combinaison. (En réfléchissant à cela, l'idée est: "Si vous parlez quand même HTTP, assurez-vous que vous pouvez tout faire avec Nginx, y compris la terminaison SSL et la distribution de contenu statique." Mais je pense que l'unité Nginx est née de cette idée. Convaincu)
Alors pourquoi Node.js + Express et Python + aiohttp Server parlent-ils HTTP directement sans utiliser une interface comme WSGI?
Les deux ont quelque chose en commun, tous deux prenant en charge les E / S non bloquantes avec des boucles d'événements.
Node.js est un E / S non bloquant quel que soit le framework, car le runtime lui-même est une boucle d'événements.
Python est un langage d'E / S bloquant, donc une implémentation simple parlant HTTP peut entraîner aucune performance du tout, par exemple, lors du traitement d'une requête, elle bloque toutes les autres requêtes. Par conséquent, nous considérerons le traitement parallèle dans les threads et les boucles d'événements, mais si le traitement parallèle est effectué sous la contrainte qu'il y a un GIL, il peut être préférable de le faire dans les boucles d'événements que dans les threads (?). Comme aiohttp Server repose sur asyncio (boucle d'événement), il s'agit d'un IO non bloquant de ce type.
Que se passe-t-il si l'application elle-même peut gérer le traitement parallèle? Même si vous l'implémentez de manière simple, vous pouvez gérer les demandes en parallèle normalement. Après cela, vous pouvez gérer un grand nombre de demandes en démarrant simplement plusieurs processus et en équilibrant la charge. Vous n'avez donc pas besoin d'utiliser WSGI pour séparer votre serveur Web de votre application Web.
Recommended Posts