Tout ceci est fait avec un serveur web externe, qui écoute le monde (je recommande nginx ou lighttpd).
En ce qui concerne les limites de débit, nginx est capable de limiter, c'est à dire 50 req/minute par chaque IP, tous sur obtenir la page 503, que vous pouvez personnaliser.
En ce qui concerne l'arrêt temporaire prévu, dans le monde de rails, cela se fait via une page spéciale maintainance.html. Il y a une sorte d'automatisation qui crée ou fait un lien symbolique avec ce fichier lorsque les serveurs de l'application Rails sont hors service. Je recommande de ne pas se fier à la présence du fichier, mais à la disponibilité réelle du serveur d'applications.
Mais en réalité, vous êtes en mesure de démarrer/arrêter des services sans perdre la moindre connexion. Par exemple, vous pouvez exécuter une instance distincte du serveur d'applications sur un port UNIX socket/IP différent et faire en sorte que l'équilibreur (nginx/lighty/haproxy) utilise également cette nouvelle instance. Ensuite, vous fermez l'ancienne instance et tous les clients sont servis par la nouvelle. Aucune connexion n'est perdue. Bien sûr, ce scénario n'est pas toujours possible, il dépend du type de changement que vous avez introduit dans la nouvelle version.
haproxy est une solution d'équilibrage uniquement. Elle peut équilibrer de manière extrêmement efficace les demandes adressées aux serveurs d'applications de votre ferme.
Pour un service assez important, vous vous retrouvez avec quelque chose comme :
- api.domain se résolvant sur des équilibreurs round-robin N balancers
- Chaque équilibreur redirige les demandes vers les serveurs Web M pour le contenu statique et les serveurs d'applications P pour le contenu dynamique. Oh, mais votre API REST n'a pas de fichiers statiques, n'est-ce pas ?
Pour les services de petite taille (moins de 2K rps), tout l'équilibrage est effectué dans un ou deux serveurs web.