Comment construire une infrastructure évolutive pour une famille de sites Web liés mais séparés?

Question

Donc, mon entreprise parle de la construction d'une plateforme de commerce électronique qui servira de nombreux clients différents. Chaque client aurait un aspect différent, et son propre ensemble d'utilisateurs, mais le code de support (c.-à-d. Services d'administration, serveurs d'authentification, services de paiement, éventuellement pages d'administration, etc.), et certains utilisateurs seraient partagés. Correction d'un bug peut être appliqué à tous les sites en même temps, un administrateur principal pourrait se connecter à tous les sites Web. Comme l'ensemble des sites Web de StackExchange (avec un trafic assez élevé) fonctionnent sur un petit nombre de serveurs (deux je crois), je me demande ce que cela impliquerait de servir de nombreux sites Web (mais similaires) via une webapp, ou même une base de données. Pour avoir une base de données, j'imagine que chaque table aurait des colonnes identifiant le domaine auquel appartenait l'entité, et chaque appel SQL serait filtré par cette colonne. Cela semble être devenu un cauchemar pour l'entretien, et (ce qui est moins important pour moi) l'enfer d'un DBA.

Une autre option, avec une webapp, mais plusieurs bases de données, j'imagine que le domaine pourrait être lié à une source de données spécifique, où toutes les données non partagées pourraient être spécifiées. Puis, lorsqu'une requête est faite, la source de données appropriée peut être chargée et la webapp s'exécute comme s'il n'y avait qu'une seule source. Cela aurait un avantage supplémentaire d'être facilement extensible horizontalement puisque la même application Web, mais un ensemble différent de domaines et de sources de données, pourrait être engendré si nécessaire. Les sites Web pourraient facilement être déplacés vers de nouveaux serveurs en copiant simplement la webapp et en déplaçant la base de données.

Je me demande quelles sont les autres possibilités, ainsi que des exemples spécifiques s'ils existent.

Remarque: Je ne parle pas de l'évolutivité à l'échelle de Twitter, ni du matériel/des langages/etc, mais plutôt des méthodologies et des modèles de conception.

Answer 1

L'architecture dont vous parlez s'appelle l'architecture «multi-locataires». Il y a diff. façons d'architecturer une application multi-locataire. En termes généraux, le niveau de données peut être architecturé de 3 façons:

1. base de données distincte pour chaque client - plus facile à coder, diff. pour maintenir
2. une base de données, différents schémas
3. une base de données, un schéma (avec clientid dans chaque tableau, à l'exception des tables de méta-données) - plus de temps dans le codage, plus facile à maintenir

Chacun a ses propres avantages/inconvénients. Jetez un oeil à cet article de Microsoft sur la multi-location. http://msdn.microsoft.com/en-us/library/aa479086.aspx

D'une manière générale, je suggérerais l'option 3 car elle offre une véritable multi-location. Si vous avez des tables que vous attendez de devenir très grandes, vous pouvez partitionner cette table en fonction du clientid (par exemple: si vous voulez 10 partitons, vous pouvez faire une partition basée sur le mod de clientid)