Comment concevoir une application Web hébergée?

Question

Comment concevriez-vous une application Web hébergée? Je regarde des applications telles que Basecamp, Campaign Monitor, Freshbooks, etc. où les utilisateurs peuvent s'inscrire en ligne et où l'application est hébergée pour eux.

1. Utiliseriez-vous une grande base de données pour stocker toutes les données de vos clients ou manipuleriez-vous les données différemment? Voulez-vous utiliser plus d'une base de données? Voulez-vous créer une base de données pour chaque client?
2. Voulez-vous dupliquer votre base de code pour chaque abonnement / client ou utiliser un seul code pour gérer tous les clients?
3. Y a-t-il d'autres éléments de design auxquels je devrais penser?
4. Des sites Web ou des livres qui parlent de cela?

Modifier: J'ai trouvé un article MSDN sur l'architecture de données multi-locataires: http://msdn.microsoft.com/en-us/library/ aa479086.aspx # mlttntda_topic4

Answer 1

Reportez-vous à 37signals - ils sont des experts dans ce domaine et ont de nombreux articles dans lesquels ils répondent aux questions de la communauté (de nombreux articles comme le vôtre devraient apparaître).

Architecture haute évolutivité = 37 signaux

Demander à 37signals: Comment procéder vous traitez les cartes de crédit?

En ce qui concerne le nombre de bases de données, de David Heinemeier Hansson dans Que voulez-vous savoir?

  

Quelques réponses techniques & # 8230;

     

Lance, toutes nos factures programmées   les opérations sont automatisées. N'importe quoi   En quelque sorte, cela nous rendrait fous.   Il est particulièrement important de vous assurer que   ce traitement d'urgence est en place   pour défaut de cartes de crédit. Dernier je   regardé, je crois que 5% de nos charges   rebondi grâce aux cartes de crédit   ont expiré, dépassé la limite, ou   fermé. Assurez-vous de gérer cela   gracieusement.

     

Nous utilisons simplement Authorize.net et un   demande de carte de crédit séparée (minuscule   application développée dans Rails et utilisée par le   autres applications sur le réseau interne   via REST) ??qui garde les chiffres   sécurisé.

     

Warren, nous courons gratuitement et payons des comptes   sur la même base de données. C'est l'un   base de données par application. Une base de données   par compte est normalement un vraiment,   vraiment mauvaise idée. Habituellement, les données sont   assez normalisé, mais nous sommes   certainement pas religieux à ce sujet. je   valorisent généralement mon code source sur mon   schéma. Donc si je peux avoir   code source meilleur / plus joli en se pliant   un schéma, je le fais généralement. Mais   partir de normalisé et dénormaliser   comme performance ou structure de code   l'exige.

     

Jason, nous utilisons le courrier électronique pour les SMS. Nous tous   les transporteurs ont un   phone@carrier-gateway.com gateway.

     

Jake Bien, ahh, le bon vieux & # 8217; & # 8220; mais fait   il échelle & # 8221; question. J'ai répondu à ça   quelques années en arrière. Rien n'a   changé pour nous depuis lors. Nous gérons   des millions et des millions de dynamique   demandes tous les jours sans même   recourant à beaucoup de cache (la plupart   écrans dans la plupart de nos applications   sont différents pour chaque utilisateur, donc   les systèmes de mise en cache traditionnels sont plus difficiles   à appliquer).

     

Il y a beaucoup d'autres Rails   applications là-bas gérer des dizaines   de millions de demandes quotidiennes. Tout   suivre plus ou moins la même partagée   Rien approche. Toutes les techniques   pour mettre à l'échelle haut et haut sont sur   Là. C'est à peine une clé en main   solution, mais tout ce qui promet   être qui est généralement juste plein.

Answer 2

Si vous ne parlez que de milliers de clients (par rapport à des centaines de milliers ou de millions de personnes), la différence est minime, à moins que vous ne sachiez que vous avez des tables pouvant comporter des milliers de lignes par client ou plus. Ensuite, votre conception pourrait changer.

La configuration normale d'un magasin de données basé sur une base de données relationnelle va placer une clé étrangère nom_client sur la plupart de vos tables. Dans ce cas, ne montrez ces données qu’à ce client (ou dans les cas où il a indiqué que des autorisations explicites sont accordées à quelqu'un d'autre).

Ne vous inquiétez pas trop des problèmes de dimensionnement des SGBDR jusqu'à ce qu'il semble que vous pourriez commencer à avoir plusieurs millions de lignes dans une même table. Ensuite, il serait peut-être temps d'étudier un magasin de clés / valeurs distribué. Mais gardez à l'esprit que ce genre de problème est le bon type de problème, car cela signifie probablement que vous gagnez beaucoup d'argent.

c’est-à-dire, traversez le pont d’échelle lorsque vous y arrivez. Concevez vos objets au mieux de vos capacités actuelles, mais sinon, une optimisation prématurée est la racine de tout mal.

Answer 3

Je travaille comme consultant pour un certain nombre d'applications SaaS. J'ai donc vu différentes architectures. Je recommanderais:

1. Une base de données pour tous les clients. Assurez-vous de bien concevoir la base de données afin d’avoir une clé primaire pour l’utilisateur, qui est votre propre ID unique. J'ai vu des erreurs dans lesquelles la conception (pas réellement, mais elle aurait tout aussi bien pu l'être) créait quelque chose comme une adresse électronique, un numéro de téléphone, etc. en tant que clé primaire). En outre, ne finissez pas par tout jeter dans une table d'utilisateurs géante.

   1. Vous voudrez peut-être commencer à suivre de nombreux comportements d'interaction de l'utilisateur à un moment donné. Pour cela, vous pouvez utiliser un magasin de noms NoSQL et commencer à y envoyer des événements pour une analyse ultérieure. Ou utilisez quelque chose comme MixPanel ou KISSmetrics.

   2. Gardez une trace des indicateurs de performance clés quotidiens en écrivant des lignes dans une table d'indicateurs de performance clés, ce qui facilite l'interrogation de ce qui s'est passé au fil du temps. Sinon, vous finirez par vouloir poser des questions à la base de données et vous découvrirez qu'il s'agit d'une requête gigantesque.

L’avantage principal d’une seule base de données SQL est que si votre responsable du marketing connaît le langage SQL (recommandé!), il peut simplement l’interroger directement. Si vous choisissez la voie NoSQL, c'est beaucoup plus difficile, puis le marketing commence à émettre des hypothèses qui sont généralement fausses et vous perdez beaucoup de temps à emprunter le mauvais chemin en fonction de ces hypothèses.