Différence dans les paradigmes de serveur Web (Apache vs. Reverse proxy + serveur Web)

Question

J'ai commencé à développer avec Ruby on Rails, et j'ai rencontré ce qu'il a été décrit comme a different paradigm lorsqu'il s'agit de serveurs Web.

Old paradigm (apache) 
===================== 

       +--- web process fork 
       | 
[requests] -----+--- web process fork 
       | 
       +--- web process fork 


New paradigm (Puma + Nginx) 
=========================== 
              +---> web app process 1 --> threads 
              | 
[requests] <--> [reverse proxy server] --+---> web app process 2 --> threads 
              | 
              +---> web app process 3 --> threads 

Sur l'article que je lisais, il n'a pas essayé d'expliquer les différences entre ces 2 paradigmes et les avantages de l'un sur l'autre. C'est ce qui m'intéresse.

Quel est le point de ce nouveau paradigme utilisé sur les applications Ruby on Rails? Quels avantages a sur l'ancienne façon de démon HTTP? Quels sont ses inconvénients?

Answer 1

L'architecture du serveur d'applications a les caractéristiques suivantes:

Dans l'ensemble, je suis en faveur de l'exécution d'applications Web en tant que serveurs d'applications et inverse mandatement pour eux. Cela nécessite un minimum d'efforts et les avantages sont nombreux: vous pouvez gérer votre serveur et votre application séparément, vous pouvez exécuter autant ou peu de processus d'application sur autant de machines que vous le souhaitez sans avoir besoin de plus de serveurs Web, vous pouvez exécuter l'application en tant qu'utilisateur différent avec aucun effort, vous pouvez changer de serveur web, vous pouvez supprimer l'application sans toucher le serveur web, vous pouvez faire un déploiement transparent en commutant simplement où un fifo pointe, etc. Soudage de votre application à votre serveur web est absurde et il n'y a pas de bonne raison de le faire.

par rapport au modèle classique:

PHP est naturellement lié à Apache. Le faire fonctionner séparément, ou avec n'importe quel autre serveur web, nécessite autant de déblayage (peut-être plus) que de déployer n'importe quelle autre langue. php.ini s'applique à toutes les applications PHP exécutées n'importe où. Il n'y a qu'un seul fichier php.ini, et il s'applique globalement; Si vous utilisez un serveur partagé et que vous devez le modifier ou si vous exécutez deux applications nécessitant des paramètres différents, vous n'avez pas de chance. vous devez appliquer l'union de tous les paramètres nécessaires et les réduire depuis l'intérieur des applications en utilisant ini_set ou dans le fichier de configuration d'Apache ou dans .htaccess. Si tu peux. Aussi wow c'est beaucoup d'endroits que vous devez vérifier pour comprendre comment un paramètre obtient sa valeur. De même, il n'existe pas de moyen facile d '"isoler" une application PHP et ses dépendances du reste du système. Exécuter deux applications qui nécessitent différentes versions d'une bibliothèque, ou même PHP lui-même? Commencez par construire une deuxième copie d'Apache. L'approche "tas de fichiers", en plus de faire du routage une énorme douleur dans le cul, signifie également que vous devez soigneusement mettre en liste blanche ou noire ce qui est réellement disponible, parce que votre hiérarchie d'URL est aussi votre arbre de code entier. Les fichiers de configuration et autres "partiels" ont besoin de gardes de type C pour éviter qu'ils ne soient chargés directement. Le bruit de contrôle de version (par exemple, .svn) doit être protégé. Avec mod_php, tout sur votre système de fichiers est un point d'entrée potentiel; avec un serveur d'applications, il n'y a qu'un seul point d'entrée, et seule l'URL contrôle si elle est invoquée. Vous ne pouvez pas mettre à niveau de manière transparente un tas de fichiers qui exécutent un style CGI, sauf si vous voulez des plantages et un comportement indéfini lorsque les utilisateurs atteignent votre site à mi-chemin de la mise à niveau.

D'autres paradigmes comprennent:

• L'application Web est un serveur web, et peut accepter les requêtes HTTP directement. Exemples de ce modèle:

  • Presque tous les nœuds.Applications Web js et Meteor JS (https://lookback.io).

  • Le logiciel de suivi des bogues de Trac fonctionnant sur son serveur autonome (https://trac.webkit.org).

• L'application Web ne parle pas HTTP directement, mais est connecté directement au serveur Web via une carte de communication. CGI, FastCGI et SCGI en sont de bons exemples. (web.py, flask, sinatra)

 
      start() 
    ----------------------------- 
    |       | 
    | init()     | 
NEW ->-- INITIALIZING  | 
| |   |    |  -------------------- STARTING_PREP -->- STARTING -->- STARTED -->--- | 
| |   |               | | 
| |destroy()|               | | 
| -->--------- STOPPING ------>----- STOPPED ----->----- 
| \|/        ^     |^
|  |    stop()   |      | | 
|  |  --------------------------      | | 
|  |  |            | | 
|  |  | destroy()      destroy() | | 
|  | FAILED ---->------ DESTROYING -------------------- \|/       | 
|         DESTROYED      | 
|                | 
|       stop()        | 
--->------------------------------>------------------------------ 

sur Heroku, les applications sont complètement autonomes et ne reposent pas sur l'injection d'exécution d'un serveur Web dans l'environnement d'exécution pour créer un service orienté web. Chaque processus Web se lie simplement à un port et écoute les demandes arrivant sur ce port. Le port auquel se connecter est attribué par Heroku en tant que variable d'environnement PORT.

Références

• PHP: a fractal of bad design

• Phusion Passenger: Design and Architecture

• Optimizing PHP Application Concurrency | Heroku Dev Center

• Runtime Principles | Heroku Dev Center