Hébergement d'un site Web sur plusieurs serveurs?
Supposons que je possède un site Wordpress hébergé sur une boîte Linux et que je souhaite ajouter une toute nouvelle fonctionnalité à l'aide de asp.net.
Serait-il possible d'héberger la nouvelle partie asp.net du site sur un serveur Windows tout en offrant une expérience utilisateur transparente? Est-ce une bonne idée? Quels problèmes puis-je m'attendre si le serveur est configuré de la sorte?
Il y a plusieurs solutions.
Vous pouvez obtenir un serveur IIS avec le support PHP
Pas sûr que Wordpress le supporteVous obtenez un serveur Apache avec mod_mono (implémentation open source d’ASP)
* Pas sûr que mod_mono supporte les dernières fonctionnalités ASP.net *Vous pouvez héberger la section asp sur un sous-domaine et pointer le sous-domaine vers le nouveau serveur. La solution la plus simple. Vous pouvez utiliser la même conception pour le domaine principal et le sous-domaine et personne ne remarquera la différence.
Vous pouvez également configurer un proxy côté serveur pour intercepter les demandes et rediriger la demande vers le serveur approprié.
Cela se produit tout le temps et dépend de ce que vous essayez de faire. Séparer la charge sur deux serveurs de la sorte pourrait en théorie améliorer l'expérience utilisateur si votre serveur actuel est soumis à une charge élevée. Il est assez courant d'utiliser, par exemple, CURL (http://curl.haxx.se/) pour accéder à une fonctionnalité sur un autre serveur et les effets sur l'expérience utilisateur dépendraient beaucoup de l'autre serveur, de sa charge, etc.
D'après mon expérience personnelle, l'accès aux api, etc. ralentit généralement un peu les choses, en particulier si le deuxième serveur est accédé côté serveur car vous créez essentiellement un transport de données à trois voies, où l'utilisateur contacte le serveur 1, le serveur un contacte le serveur 2, le serveur2 quelque chose et retourne ensuite au serveur 1 avec une réponse, qui doit ensuite la restituer à l'utilisateur, ce qui est bien mieux si la fonctionnalité est accessible à l'aide d'un appel ajax afin que le navigateur de l'utilisateur puisse contacter directement le serveur 2.
J'espère que cela t'aides
Vous pouvez simplement configurer un nom de domaine et trouver une société d’hébergement ASP.NET pour l’héberger. Cela ira de manière transparente pour les utilisateurs et c'est probablement la meilleure façon de le faire. Vous pouvez également consulter le site www.smarterasp.net pour bénéficier de tarifs exceptionnels et de la fiabilité de leur plan d'hébergement asp.net. C'est la compagnie que j'utilise depuis quelques années.
Je suis d'accord avec Joyce sur le fait qu'il y a plusieurs façons de s'y prendre. En fait, IIS7 prend en charge PHP et, dans la plupart des cas, il fonctionne assez bien. Avec le site WordPress exécuté dans IIS, il est assez simple de créer un répertoire virtuel (application IIS) pour exécuter votre application ASP.Net sur le même domaine que votre site principal (ex. http://mydomain.com/ASPdotNetApp/ ).
Si vous voulez garder WordPress en cours d'exécution sur votre serveur Linux, plusieurs options sont probablement les plus courantes. La première consiste à exécuter votre application ASP.Net sur un serveur Windows distinct en tant que sous-domaine. Ainsi, votre site principal serait toujours http://mydomain.com et la nouvelle application serait http://aspnetapp.mydomain.com .
L’autre option courante pour exécuter l’application ASP.Net sur un autre serveur serait d’utiliser un proxy inverse. Cela a été mentionné dans quelques réponses données jusqu'à présent, mais je ne pense pas que cela ait été explicitement indiqué. Pour ce faire, vous devez exécuter votre application ASP.Net sur un autre serveur, puis installer mod_proxy sur votre serveur Linux (plus précisément, à l'aide de la directive ProxyPass).
Vous trouverez des informations sur mod_proxy ici et des informations sur ProxyPass sur cette page ici .
Avec le proxy inverse en place, si vous dirigiez les utilisateurs vers http://mydomain.com/AspdotNetApp/ , ils ne seraient pas conscients que l'application s'exécutait sur un autre serveur.