Como criar um aplicativo da web hospedado?

Question

Como seria você criar um aplicativo da web hospedado?Eu estou olhando para aplicações como o Basecamp, o Campaign Monitor, Freshbooks, etc...onde os utilizadores podem inscrever-se online e o aplicativo é hospedado por eles.

1. Você gostaria de usar 1 grande banco de dados para armazenar todos os seus dados do cliente ou manipular os dados de forma diferente?Você gostaria de usar mais de 1 banco de dados?Você poderia fazer um banco de dados para cada cliente?
2. Você gostaria de duplicar a sua base de código para cada inscrição/cliente ou teria que usar 1 codebase para lidar com todos os clientes?
3. Existem outros elementos de design que eu deveria pensar?
4. Quaisquer web sites ou livros que falam sobre isso?

Editar:Eu encontrei um artigo do MSDN, que discutiu multi-inquilino Arquitetura de Dados:http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4

Answer 1

Consulte a 37signals -- eles são especialistas neste campo e tem um monte de artigos, onde eles respondem perguntas da comunidade (muitos como a sua deve vir para cima).

Alta Escalabilidade = 37signals Arquitetura

Pergunte 37signals:Como você processar cartões de crédito?

Em relação ao número de bancos de dados, de David Heinemeier Hansson em O que você quer saber?

Algumas respostas técnicas...

Lança, e todos os nossos cobrança agendada as operações são automatizadas.Nada espécie de que nos louco.É especialmente importante para se certificar de essa contingência de manipulação é no lugar por falta de cartões de crédito.Da Última Vez Que Eu olhou, eu acredito que 5% do nosso encargos saltou graças aos cartões de crédito que foram expirado, ao longo do limite, ou fechado.Certifique-se de lidar com essa graciosamente.

Nós só usar Authorize.net e um cartão de crédito em separado aplicação (minúsculo aplicativo desenvolvido em Rails e utilizados pelo a outros aplicativos na rede interna através de RESTO ), que mantém os números seguros.

Warren, corremos livres e pagar contas no mesmo banco de dados.É um banco de dados por aplicativo.Um banco de dados por conta, normalmente, é uma verdade, péssima ideia.Normalmente os dados bastante normalizado, mas estamos definitivamente não religiosas sobre ele.Eu geralmente o valor de código, sobre o meu esquema.Então se eu puder fazer melhor/mais bonita do código fonte por flexão um esquema, eu vou normalmente fazer isso.Mas iniciar a partir normalizado e desnormalizar como o desempenho ou a estrutura de código ele exige.

Jason, nós usamos e-mail para sms.Todos NÓS os portadores têm uma telefone@carrier-gateway.com gateway.

Jake Bom, ah, o bom e velho' ", mas não ele escala" pergunta.Eu respondi que no um par de anos atrás.Nada tem alterado para nós desde então.Nós gerir milhões e milhões de dinâmica de solicitações a cada dia, mesmo sem recorrer a quantidade de cache (mais telas em mais um de nossos aplicativos são diferentes em uma base por usuário, de modo tradicional cache de esquemas são mais difíceis para aplicar).

Há muitos outros Trilhos aplicações lá fora, dezenas de gestão de milhões de pedidos por dia.Todos seguem mais ou menos o mesmo Compartilhado Nada abordagem.Todas as técnicas para o dimensionamento alto e alto são as não.É quase um turn-key a solução, mas tudo o que promete para ser o que normalmente é cheio de ti.

Answer 2

Se você está falando apenas de milhares de clientes (vs centenas de milhares ou milhões), a diferença é bastante mínima, a menos que você saiba que você tem tabelas que podem ter milhares de linhas por cliente ou mais. Então seu design pode mudar.

Configuração normal para um datastore baseado em dados relacional será colocado customer_id Chave estrangeira na maioria das suas mesas. Em seguida, simplesmente não mostre esses dados para ninguém, mas esse cliente (ou nos casos em que de alguma forma indicaram permissões explícitas são concedidas a outra pessoa).

Não se preocupe muito com os problemas de escala do RDBMS até parecer que você pode começar a ter vários milhões de linhas em uma mesa. Pode ser hora de investigar um armazenamento de chave/valor distribuído. Mas lembre -se de que esse tipo de problema é o bom problema de ter, porque presumivelmente significa que você está ganhando muito dinheiro.

ou seja, atravesse a ponte de escala quando você vier. Projete as coisas da melhor maneira possível, mas, caso contrário, a otimização prematura é a raiz de todo o mal.

Answer 3

Eu trabalho como consultor de vários aplicativos SaaS, então já vi diferentes arquiteturas. Eu recomendo:

1. Um banco de dados para todos os clientes. Certifique -se de projetar bem o banco de dados para ter uma chave primária para o usuário, que é seu próprio ID exclusivo. Eu já vi algumas bagunças em que o design eficaz (não, na verdade, mas poderia muito bem) fez algo como email, número de telefone, etc. como a chave primária). Além disso, não acabe lançando tudo em uma tabela de usuários gigantes.

   1. Você vai querer começar a rastrear muitos comportamentos de interação do usuário em algum momento. Para isso, você pode usar uma loja de nomes no NOSQL e começar a lançar eventos para análise posterior. Ou use algo como MixPanel ou Kissmetrics.

   2. Acompanhe os KPIs diários escrevendo linhas em uma tabela KPI que facilita a consulta o que aconteceu com o tempo. Caso contrário, você vai querer fazer perguntas ao banco de dados e descobrir que é uma consulta gigante fazê -lo.

Uma vantagem importante de ter um único SQL DB é que, se sua pessoa de marketing conhece SQL (recomendada!), Ele poderá consultá -lo diretamente. Se você seguir a rota NoSQL, é muito mais difícil e, em seguida, o marketing começa a fazer suposições que geralmente estão erradas e você perde muito tempo seguindo o caminho errado com base nessas suposições.