¿Cómo diseñar una aplicación web alojada?

Question

¿Cómo diseñaría una aplicación web alojada? Estoy buscando aplicaciones como Basecamp, Campaign Monitor, Freshbooks, etc., donde los usuarios pueden registrarse en línea y la aplicación está alojada para ellos.

1. ¿Usaría 1 gran base de datos para almacenar todos los datos de sus clientes o los manejaría de manera diferente? ¿Usaría más de 1 base de datos? ¿Haría una base de datos para cada cliente?
2. ¿Duplicaría su base de código para cada registro / cliente o utilizaría 1 base de código para manejar a todos los clientes?
3. ¿Hay otros elementos de diseño en los que debería pensar?
4. ¿Hay algún sitio web o libro que hable sobre esto?

Editar: Encontré un artículo de MSDN que analizaba la arquitectura de datos de múltiples inquilinos: http://msdn.microsoft.com/en-us/library/ aa479086.aspx # mlttntda_topic4

Answer 1

Consulte 37 señales: son expertos en este campo y tienen muchos artículos en los que responden preguntas de la comunidad (muchas como la suya deberían aparecer).

Alta escalabilidad = 37 Arquitectura de señales

Pregunte 37signals: Cómo hacer procesas tarjetas de crédito?

Con respecto al número de bases de datos, de David Heinemeier Hansson en ¿Qué quieres saber?

  

Algunas respuestas técnicas & # 8230;

     

Lance, toda nuestra facturación programada   Las operaciones son automatizadas. Cualquier cosa   eso nos volvería locos.   Es especialmente importante asegurarse   que el manejo de contingencias está en su lugar   por fallar las tarjetas de crédito. Ultimo yo   mira, creo que el 5% de nuestros cargos   rebotado gracias a las tarjetas de crédito que   fueron vencidos, por encima del límite, o   cerrado. Asegúrese de manejar eso   con gracia.

     

Solo usamos Authorize.net y un   solicitud de tarjeta de crédito separada (pequeña   aplicación desarrollada en Rails y utilizada por el   otras aplicaciones en la red interna   a través de REST) ??que mantiene los números   seguro.

     

Warren, ejecutamos cuentas gratuitas y de pago   en la misma base de datos. Es uno   base de datos por aplicación. Una base de datos   por cuenta es normalmente un realmente,   Muy mala idea. Por lo general, los datos son   bastante normalizado, pero estamos & # 8217; re   definitivamente no es religioso al respecto. yo   generalmente valoro mi código fuente sobre mi   esquema. Entonces si puedo conseguir   código fuente mejor / más bonito doblando   un esquema, típicamente haré eso. Pero   comenzar desde normalizado y desnormalizar   como rendimiento o estructura de código   lo exige.

     

Jason, usamos el correo electrónico para sms. Todos nosotros   los transportistas tienen un   phone@carrier-gateway.com gateway.

     

Jake Good, ahh, el buen ol & # 8217; & # 8220; pero lo hace   escala & # 8221; pregunta. Respondí eso el   Hace un par de años. Nada tiene   cambiado para nosotros desde entonces. Lo manejamos   millones y millones de dinámica   solicita todos los días sin siquiera   recurriendo a mucho almacenamiento en caché (la mayoría   pantallas en la mayoría de nuestras aplicaciones   son diferentes para cada usuario, por lo que   los esquemas de almacenamiento en caché tradicionales son más difíciles   aplicar).

     

Hay muchos otros rieles   aplicaciones por ahí gestionando decenas   de millones de solicitudes diarias. Todos   seguir más o menos lo mismo Compartido   Nada se acerca. Todas las tecnicas   para escalar alto y alto están fuera   ahí. Es apenas una llave en mano   solución, pero todo lo que promete   para ser que generalmente está lleno de eso.

Answer 2

Si solo habla de miles de clientes (frente a cientos de miles o millones), la diferencia es bastante mínima a menos que sepa que tiene tablas que pueden tener miles de filas por cliente o más. Entonces su diseño podría cambiar.

La configuración normal para un almacén de datos basado en una base de datos relacional colocará una clave externa customer_id en la mayoría de sus tablas. Entonces, simplemente no muestre esos datos a nadie más que a ese cliente (o en los casos en que hayan indicado de alguna manera que se otorgan permisos explícitos a otra persona).

No se preocupe demasiado por los problemas de escalado de RDBMS hasta que parezca que podría comenzar a tener varios millones de filas en una tabla. Entonces podría ser el momento de investigar un almacén de clave / valor distribuido. Pero tenga en cuenta que ese tipo de problema es un buen tipo de problema, porque presumiblemente significa que está haciendo una tonelada de efectivo.

es decir, cruza el puente de escala cuando llegues a él. Diseñe las cosas lo mejor que pueda, pero de lo contrario, la optimización prematura es la raíz de todo mal.

Answer 3

Trabajo como consultor de varias aplicaciones SaaS, por lo que he visto diferentes arquitecturas. Recomiendo:

1. Una base de datos para todos los clientes. Asegúrese de diseñar bien el db para que tenga una clave principal para el usuario, que es su propia identificación única. He visto algunos problemas en los que el diseño efectivamente (no realmente, pero podría haberlo hecho) hizo algo como correo electrónico, número de teléfono, etc. como la clave principal). Además, no termine arrojando todo en una tabla de usuario gigante.

   1. Deberá comenzar a rastrear un montón de comportamiento de interacción del usuario en algún momento. Para eso, puede usar un almacén de valores de nombre NoSQL y simplemente comenzar a lanzar eventos para su posterior análisis. O use algo como MixPanel o KISSmetrics.

   2. Realice un seguimiento de los KPI diarios escribiendo filas en una tabla de KPI que facilite la consulta de lo que sucedió con el tiempo. De lo contrario, terminará queriendo hacer preguntas a la base de datos y descubrir que es una consulta gigante para hacerlo.

Una ventaja clave de tener una única base de datos SQL es que si su persona de marketing conoce SQL (¡recomendado!) entonces puede consultarlo directamente. Si sigue la ruta NoSQL, entonces es mucho más difícil, y luego el marketing comienza a hacer suposiciones que generalmente son incorrectas, y pierde mucho tiempo siguiendo el camino equivocado en función de esas suposiciones.