Résumé des méthodes de déploiement Web Python-Tutoriel Python-php.cn

Ne laissez pas le serveur fonctionner à nu

Tous ceux qui ont étudié PHP savent que le déploiement de l'environnement formel de PHP est très simple. Il suffit de modifier quelques fichiers et tout ira bien. L'utilisation de la méthode FastCgi n'est également qu'une question de minutes. En comparaison, le déploiement de Python dans les applications Web est beaucoup plus compliqué, principalement en raison du grand nombre d'outils et d'un support insuffisant des serveurs grand public. Avant de comprendre la méthode de déploiement de Python dans l'environnement de production, clarifions quelques concepts ! Très important !

CGI :

CGI est une interface de passerelle commune Interface) est un standard d'interface entre les applications externes (programmes CGI) et les serveurs Web. Il s'agit d'une procédure de transfert d'informations entre les programmes CGI et les serveurs Web. La spécification CGI permet aux serveurs Web d'exécuter des programmes externes et d'envoyer leur sortie aux navigateurs Web. CGI transforme l'ensemble de simples documents hypermédia statiques du Web en un tout nouveau média interactif. En termes simples, CGI est comme un pont qui relie la page Web et le programme d'exécution du serveur WEB. Il transmet les instructions reçues par le HTML au programme d'exécution du serveur, puis renvoie les résultats du programme d'exécution du serveur au HTML. page. Image de synthèse Les performances multiplateformes sont excellentes et peuvent être implémentées sur presque tous les systèmes d'exploitation.

Lorsque la méthode CGI rencontre une demande de connexion (demande de l'utilisateur), elle doit d'abord créer un sous-processus cgi, activer un processus CGI, puis traiter la demande et terminer le sous-processus après traitement. Il s’agit du modèle fork-and-execute. Par conséquent, un serveur utilisant CGI aura autant de sous-processus CGI qu'il y a de demandes de connexion. Le chargement répété de sous-processus est la principale raison des faibles performances CGI. Lorsque le nombre de requêtes utilisateur est très important, une grande quantité de ressources système telles que la mémoire, le temps CPU, etc. sera occupée, ce qui entraînera de faibles performances.

Flux de travail du script CGI :

Le navigateur demande une URL pointant vers une application CGI via un formulaire HTML ou un lien hypertexte.
Le serveur exécute le serveur pour envoyer et recevoir la requête. L'application CGI spécifiée.
Les applications CGI effectuent les opérations requises, généralement basées sur les entrées du spectateur.
Les applications CGI formatent les résultats dans un document (généralement une page HTML) que les serveurs Web et les navigateurs peuvent comprendre.
Le serveur web renvoie les résultats au navigateur.

Python dispose d'un module cgi qui peut prendre en charge les programmes cgi natifs

FastCGI :

FastCGI est un speed Une interface pour la communication entre les serveurs HTTP et les langages de script dynamiques. HTTP le plus populaire Les serveurs prennent tous en charge FastCGI, notamment Apache, Nginx et lighttpd. Parallèlement, FastCGI est également pris en charge par de nombreux langages de script, notamment Python. FastCGI est développé et amélioré à partir de CGI. Le principal inconvénient de la méthode d'interface CGI traditionnelle est la faible performance, car chaque fois que le serveur HTTP rencontre un programme dynamique, l'analyseur de script doit être redémarré pour effectuer l'analyse, puis les résultats sont renvoyés au serveur HTTP. Ceci est presque indisponible lorsqu’il s’agit d’un accès simultané élevé. FastCGI est comme un CGI de longue durée. Il peut être exécuté à tout moment, tant qu'il est activé, il ne faudra pas de temps pour le bifurquer à chaque fois (c'est le fork-and-execute le plus critiqué). modèle). CGI est ce qu'on appelle l'application de courte durée, et FastCGI est ce qu'on appelle l'application de longue durée. Merci à FastCGI Le programme n'a pas besoin de générer continuellement de nouveaux processus, ce qui peut réduire considérablement la pression sur le serveur et produire une plus grande efficacité des applications. Son efficacité en vitesse est au moins 5 fois supérieure à celle de la technologie CGI. Il prend également en charge l'informatique distribuée, à savoir Les programmes FastCGI peuvent s'exécuter sur des hôtes autres que le serveur Web et accepter les demandes d'autres serveurs Web.

FastCGI est une extension ouverte CGI à architecture évolutive et indépendante du langage. Son comportement principal est de conserver le processus de l'interpréteur CGI en mémoire et ainsi d'obtenir des performances plus élevées. Comme nous le savons tous, le chargement répété de l'interpréteur CGI est la principale raison des faibles performances CGI. Si l'interpréteur CGI reste en mémoire et accepte la planification du gestionnaire de processus FastCGI, il peut offrir de bonnes performances, une évolutivité, des fonctionnalités de basculement, etc. L'interface FastCGI adopte une structure C/S, qui peut séparer le serveur HTTP et le serveur d'analyse de script, et démarrer un ou plusieurs démons d'analyse de script sur le serveur d'analyse de script. Chaque fois que le serveur HTTP rencontre un programme dynamique, celui-ci peut être transmis directement au processus FastCGI pour exécution, puis le résultat est renvoyé au navigateur. Cette méthode permet au serveur HTTP de traiter exclusivement les requêtes statiques ou de renvoyer les résultats du serveur de script dynamique au client, ce qui améliore considérablement les performances de l'ensemble du système d'application.

Workflow FastCGI :

Charger le gestionnaire de processus FastCGI (PHP-CGI ou PHP-FPM ou spawn-cgi) au démarrage du serveur Web
Le gestionnaire de processus FastCGI s'initialise, démarre plusieurs processus interpréteurs CGI (visibles plusieurs php-cgi) et attend les connexions du serveur Web.
Lorsqu'une requête client atteint le serveur Web, le gestionnaire de processus FastCGI sélectionne et se connecte à un interpréteur CGI. Web Le serveur envoie des variables d'environnement CGI et des entrées standard au sous-processus FastCGI php-cgi.
Une fois le sous-processus FastCGI terminé, il renvoie la sortie standard et les informations d'erreur au Web à partir de la même connexion. Serveur. Lorsque le processus enfant FastCGI ferme la connexion, la demande est traitée. Le processus enfant FastCGI attend et traite ensuite les demandes du gestionnaire de processus FastCGI (exécuté sur le Web). Serveur) prochaine connexion. En mode CGI, php-cgi se termine ici.

Caractéristiques de FastCGI :

Briser la technologie traditionnelle de traitement de pages. Avec la technologie traditionnelle de traitement de page, le programme doit communiquer avec le serveur Web ou l'application. Les serveurs sont sur le même serveur. Cette histoire a été brisée par la technologie FastCGI il y a N ans. Les applications de la technologie FastCGI peuvent être installées sur n'importe quel serveur du groupe de serveurs et via TCP/IP. Le protocole communique avec le serveur Web, ce qui convient à la fois au développement de grands groupes Web distribués et au contrôle efficace de bases de données.
Mode de requête explicite. La technologie CGI n'a pas de rôle clair dans FastCGI Dans le programme, le programme se voit attribuer un rôle clair (rôle de répondeur, rôle d'authentificateur, rôle de filtre).

WSGI :

　Passerelle du serveur Web Python Interface, en abrégé WSGI) est une interface simple et commune entre un serveur web et une application web ou un framework défini pour le langage Python. Depuis le développement de WSGI, des interfaces similaires sont apparues dans de nombreux autres langages. WSGI sert d'interface de bas niveau entre un serveur Web et une application Web ou un cadre d'application pour améliorer le terrain d'entente pour le développement d'applications Web portables. WSGI est conçu sur la base de la norme CGI existante.

WSGI est divisé en deux parties : l'une est le "serveur" ou "passerelle", et l'autre est "l'application" ou le "cadre d'application". Lors du traitement d'une requête WSGI, le serveur fournit à l'application le contexte d'environnement et une fonction de rappel (Callback Fonction). Lorsque l'application termine le traitement de la demande, le résultat est renvoyé au serveur via la fonction de rappel précédente. Ce qu'on appelle WSGI Le middleware implémente les deux côtés de l'API et fait donc office d'intermédiaire entre le service WSGI et l'application WSGI : du point de vue du serveur WSGI, le middleware joue le rôle de l'application, et du point de vue de l'application, le middleware joue le rôle de le serveur d'applications. Le composant « middleware » peut remplir les fonctions suivantes :

Après réécriture des variables d'environnement, le message de requête est acheminé vers différents objets d'application en fonction de l'URL cible.
Permet à plusieurs applications ou cadres d'application de s'exécuter simultanément en un seul processus.
Équilibrage de charge et communication à distance en transférant les messages de demande et de réponse sur le réseau.
Effectuez un post-traitement du contenu, par exemple en appliquant des feuilles de style XSLT.

Dans le passé, comment choisir un framework d'application Web approprié est devenu un problème qui trouble les débutants en Python, car, d'une manière générale, le choix du framework d'application Web limitera les possibilités disponibles. choix des serveurs Web et vice versa. À l'époque, les applications Python étaient généralement conçues pour l'une des interfaces CGI, FastCGI, mod_python ou même une interface API personnalisée pour un serveur Web spécifique. Il n'y a pas d'implémentation officielle de WSGI, Parce que WSGI ressemble plus à un protocole. Tant que ces protocoles sont respectés, les applications WSGI peuvent s'exécuter sur n'importe quel serveur. vice versa. WSGI est le wrapper CGI de Python, comparé à Fastcgi, qui est le wrapper CGI de PHP.

WSGI divise les composants Web en trois catégories : serveur Web, middleware Web et application Web. Le mode de traitement de base de wsgi est : WSGI Server -> (Middleware WSGI)* ->

Résumé des méthodes de déploiement Web Python

uwsgi :

le protocole uwsgi est le propre protocole d'un serveur uWSGI, qui est utilisé pour définir le type d'informations transmises (type d'informations), chaque uwsgi Les 4 premiers octets du paquet sont des descriptions de types d'informations de transmission, qui sont deux choses différentes par rapport à WSGI. On dit que son efficacité est 10 fois supérieure à celle du fcgi. Pour le contenu spécifique du protocole, veuillez vous référer à : l'uwsgi protocole (http://uwsgi-docs.readthedocs.org/en/latest/Protocol.html)

Les quatre ci-dessus peuvent être compris comme des protocoles ! protocole! protocole! En implémentant un tel protocole, vous pouvez implémenter des services web associés aux serveurs web et aux applications web !

uWSGI :

Le projet uWSGI vise à développer une solution complète de déploiement d'applications réseau en cluster distribué. uWSGI est principalement orienté vers le Web et ses services standards, et a été utilisé avec succès dans de nombreux langages différents. Grâce à l'architecture extensible d'uWSGI, il peut être étendu à l'infini pour prendre en charge davantage de plates-formes et de langages. Actuellement, vous pouvez écrire des plugins en C, C++ et Objective-C. Le « WSGI » dans le nom du projet est un clin d’œil au projet Python du même nom. Web Standards remercie WSGI d'avoir développé le premier plug-in du projet. uWSGI est un serveur Web qui implémente le protocole WSGI, uwsgi, http et d'autres protocoles. uWSGI n'utilise ni le protocole wsgi ni le protocole FastCGI, mais crée son propre protocole uwsgi comme mentionné ci-dessus.

Les principales fonctionnalités d'uWSGI sont les suivantes :

Performances ultra-rapides.
Faible utilisation de la mémoire (mesurée comme étant environ la moitié du mod_wsgi d'Apache2).
Gestion de plusieurs applications.
Fonction de journalisation détaillée (peut être utilisée pour analyser les performances de l'application et les goulots d'étranglement).
Hautement personnalisable (limite de taille mémoire, redémarrage du service après un certain nombre de fois, etc.).

Gunicorn :

Un outil similaire à uWSGi, porté depuis l'outil de déploiement de rails (Unicorn). Mais le protocole qu'il utilise est le WSGI mentionné ci-dessus, qui est le standard officiel défini dans python2.5 (PEP 333 ), la racine est rouge et le déploiement est relativement simple. Pour des didacticiels d'utilisation détaillés, veuillez cliquer ici (http://gunicorn.org/). Gunicorn utilise le mode pré-fork, Gunicorn Le serveur est compatible avec divers frameworks Web, nécessite une exécution très simple, une consommation de ressources légère et est assez rapide. Il se caractérise par une intégration étroite avec Django et un déploiement particulièrement pratique. Il présente également de nombreuses lacunes et n'est pas pris en charge. HTTP 1.1, les performances d'accès simultané ne sont pas élevées et il existe un certain écart de performances avec uWSGI, Gevent, etc.

1. Conception de Gunicorn

Gunicorn est un processus maître qui génère un serveur Web de plusieurs processus de travail. maître Le processus contrôle la création et la mort du processus de travail. Le processus de travail n'a qu'à accepter la demande et à la traiter. Cette séparation rend le rechargement du code très pratique et facilite l'ajout ou la suppression de processus de travail. L'auteur a donné beaucoup de place à l'expansion dans le processus de travail. Il peut prendre en charge différentes méthodes d'E/S, telles que Gevent, le processus synchrone Sync, le processus asynchrone Asyc, Eventlet, etc. le maître suit Le processus de travail est complètement séparé, ce qui fait de Gunicorn essentiellement un service qui contrôle le processus.

2. Structure du code source de Gunicorn

À partir de Application.run(), initialisez d'abord la configuration, lisez à partir du fichier, lisez depuis le terminal, etc. pour terminer la configuration. puis commence Arbiter, Arbiter est essentiellement le cœur du processus maître.Il lit et définit d'abord à partir de la classe de configuration, puis initialise la fonction de traitement du signal et établit le socket. Puis ça commence générer un processus de travail, générer en fonction du nombre configuré de processus de travail. Ensuite, il entre dans l'état d'interrogation, reçoit le signal, traite le signal et continue. La façon de réactiver le processus ici est de créer un PIPE écrit dans le tube via la fonction de traitement du signal, puis le maître se réveille de select.select().

Après l'apparition, le processus de travail commence à s'initialiser, puis traite le signal de la même manière, commence l'interrogation, traite les requêtes HTTP, appelle le côté application WSGI et obtient la réponse. retour. Continuez ensuite.

L'avantage du processus de synchronisation Sync est que chaque requête est isolée et que l'échec de chaque requête n'affectera pas les autres requêtes, mais cela entraîne un goulot d'étranglement des performances.

Tornado :

Tornado est un python Le cadre de développement est également un serveur http asynchrone non bloquant. Sa propre implémentation de sortie de données n'est pas conforme à certains des protocoles courants mentionnés ci-dessus, les requêtes dynamiques sont directement envoyées aux utilisateurs via le mécanisme interne. contenu dynamique demandé. Si vous l'utilisez comme serveur distinct et souhaitez l'utiliser pour déployer avec d'autres frameworks tels que Flask, vous devez utiliser le protocole WSGI qui a intégré ce protocole, tornado.wsgi.WSGIContainer.

wsgiref :

Python est livré avec un serveur wsgi qui implémente le protocole WSGI. Le serveur wsgi peut être compris comme un site Web conforme aux spécifications wsgi Le serveur reçoit la requête, encapsule une série de variables d'environnement et appelle le wsgi enregistré conformément à la spécification wsgi. app, et renvoie enfin la réponse au client. C'est le propre serveur de Django.

Tout ce qui précède peut être compris comme une mise en œuvre ! accomplir! accomplir! Des outils qui implémentent le protocole !

Remarque : mod_wsgi (module apache) est en fait un module qui implémente le protocole wsgi. Il n'est quasiment pas abandonné maintenant, donc je n'en dirai pas plus. Si vous êtes intéressé, vérifiez. faites-le vous-même.

Donc, si vous utilisez le framework Django pour développer une application et que vous souhaitez la déployer dans un environnement de production, vous ne pouvez certainement pas utiliser celui fourni avec Django. Vous pouvez utiliser le serveur uWSGI qui utilise le. protocole uwsgi, ou vous pouvez utiliser le protocole WSGI gunicorn ou Tornado, vous pouvez également utiliser FastCGI, le mode CGI Nginx, lighttpd, le serveur Apache. Il en va de même pour les autres frameworks ! Une fois que vous avez compris ces concepts, vous pouvez en être conscient lors de leur déploiement, et vous pouvez « savoir ce qu'ils sont et pourquoi ils sont ce qu'ils sont » lorsque vous associez divers outils.

Il existe deux frameworks, Django et Tornado, dans les projets de notre groupe, et deux méthodes de déploiement sont également utilisées dans l'environnement de production. uWSGI et Gunicorn :

Le projet Django est déployé à l'aide de Nginx uWSGI, et le projet Tornado est déployé à l'aide de Nginx Gunicorn :

Nginx est utilisé pour l'équilibrage de charge et le transfert de contenu statique. Le projet Tornado utilise Supervisord pour gérer Gunicorn et Gunicorn pour gérer Tornado. Comme nous le savons tous, en raison de l'existence du GIL de Python, la concurrence de Python adopte le mode multi-processus, notre méthode de déploiement est donc un cœur et deux processus.

Ce qui précède est un résumé des méthodes de déploiement Web Python. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (m.sbmmt.com) !