Estructura recomendada para el sitio web de alto tráfico

Question

Estoy reescribiendo un gran sitio web, que necesita una arquitectura muy sólida, aquí están mis pocas preguntas, y perdónenme por mezclar manzanas y naranjas y probablemente también kiwi :) Investigué mucho y terminó completamente confundido.

Pregunta principal: ¿Qué enfoque tomaría en la construcción de un gran sitio web que se espera que crezca en todos los sentidos?

1. único punto de entrada, páginas de datos en la base de datos, tirados por la asociación de variables GET con la entrada de base de datos (? PageID = lo que sea)

2. único punto de entrada, páginas de datos en archivos separados, incluir en base a GET variable (? pageid = cualquiera incluiría whatever.php)

3. MVC (Muy bien chicos, estoy de acuerdo, pero no puedo entender el concepto además de verificar todos los tutoriales y frameworks, ¿almacenan "view "en la base de datos" me parece que de ejemplos que si tiene 1000 páginas del mismo tipo pueden ser formadas por 1 modelo, pero ¿Todavía necesitaré tener 1000 archivos de "vistas"?

4. PAC - esto me suena aún más lógico, pero no encontré muchos recursos - si este es un buen camino a seguir, ¿me puede recomendar alguna libros o enlaces?

5. DAL/DAO/DDD - aprendí sobre estos términos al leer diligentemente el desbordamiento de pila antes de publicar la pregunta. No estoy seguro de si pertenece a esta lista

6. sentarse y crear mi propia arquitectura (probable que lo haga si nadie me ilumina aquí :)

7. Algo que no se menciona ...

Gracias .

Answer 1

La escalabilidad/disponibilidad (iow. High-traffic) para los sitios web se resuelve mejor con ninguno de los elementos que menciona. Especialmente los puntos 1 y 2; almacenar las definiciones de página en una base de datos es un absoluto no-no. MVC y otros patrones similares son más para la claridad y el mantenimiento del código, no para la escalabilidad.

Una parte importante de la información que falta es qué tipo de visitas concurrentes/seg estás esperando? A veces, las personas que no han creado sitios web de alto tráfico se sorprenden de las tasas de aciertos que en realidad constituyen una "pesadilla de escalabilidad".

Hay libros sobre cómo diseñar arquitecturas escalables, por lo que un SO post no podrán el tema de justicia, pero algunos conceptos de alto nivel muy, sin ningún orden en particular, son:

• La escalabilidad es mejor manejado primero mirando soluciones basadas en hardware. Un servidor fornido con una variedad de discos SSD puede ser muy útil.
• Haga que todo lo estático sea estático. Sirva todo lo que pueda del servidor web, no del DB. Por ejemplo, muchas páginas de sitios web generan dinámicamente listas de datos de bases de datos de tiendas de datos que muy rara vez o nunca cambian realmente.
• Salida de caché que cambia con poca frecuencia y ajuste la actualización de caché.
• Cree páginas dinámicas sin estado o asíncronas. Consulte en CQRS y Event Sourcing los patrones que favorecen/facilitan el escalado.
• Ajusta tus consultas. El DB es generalmente el gran cuello de botella ya que es un recurso compartido. Muchos creadores de aplicaciones web usan ORM que crean consultas deficientes.
• Ajuste su motor de base de datos. Copias de seguridad, replicación, barrido, registro, todo esto requiere solo un poco de recursos de su motor. Sintonizarlo puede conducir a una base de datos más rápida que le compre tiempo desde una escala horizontal.
• Reduce el número de solicitudes HTTP de los clientes. Cada conexión HTTP tiene una sobrecarga. Verifique sus páginas y vea si puede aumentar la carga en cada solicitud para reducir el número total de solicitudes individuales.

En este punto, ha optimizado el comportamiento en un servidor, y tiene que "escalar". Ahora, las cosas se vuelven muy complicadas muy rápido. Escenarios de equilibrio de carga de varios tipos (fragmentación, DNS, equilibrio tonto, etc.), separa los datos de lectura de los datos de escritura en diferentes bases de datos, va a una solución de virtualización como Google Apps, descarga contenido estático a un gran servicio CDN, usa un lenguaje como Erlang o Scala y paralelizar su aplicación, etc.

Answer 2

Soy fan de MVC porque me ha resultado más fácil escalar tu equipo cuando todo tiene un lugar y es agradable y compartimentado. Toma algo de tiempo acostumbrarse, pero la forma más fácil de manejarlo es sumergirse.

Dicho esto, definitivamente revise su biblioteca local para ver si tienen el libro O'Reilley sobre escalado: http://oreilly.com/catalog/9780596102357 que es un buen lugar para comenzar

Answer 3

Si está creando un sitio web "grande" y no comprende completamente MVC o un marco web, entonces un CMS podría ser una mejor ruta ya que puede expandirlo con complementos como mejor le parezca. Con esta ruta, puede preocuparse más por el contenido y la estructura de la página que por la plataforma. Siempre que elija el CMS apropiado.

Answer 4

Sugeriría crear una aplicación simulada con algunos de los frameworks mvc web en la naturaleza y elegir uno, con lo que su desarrollo fue lo suficientemente suave. Establecer su código sobre una base sólida es fundamental, si desea comprender los conceptos de mvc y estar preparado para agregar nuevas funcionalidades a su web fácilmente.

Answer 5

único punto de entrada, páginas de datos en la base de datos , tirados por la asociación de variables GET con la entrada de la base de datos (? PageID = lo)

potencial pesadilla para el mantenimiento. Y también para el desarrollo si tienes un equipo de más de 2-3 personas.Debería crear un conjunto de reglas estrictas para que todos se adhieran, esfuerzo que sería mejor gastar si usa MVC. Lo mismo va para 2.

MVC (Muy bien chicos, yo soy todo para él, pero no puede captar el concepto además de comprobar todos los tutoriales y los marcos por ahí, que almacenan "vista" en base de datos? me parece que a partir de ejemplos que si usted tiene 1000 páginas del mismo tipo pueden ser en forma de modelo 1, pero todavía tendrá que tener 1000 "puntos de vista" archivos?)

se depende de cuántos diseños de página hay. La mayoría de los marcos MVC le permiten trabajar con vistas estructuradas (es decir, vistas de página principal, subvistas). Piense en una vista como plantilla HTML para la página web. Cuántas plantillas y subpáginas dentro necesitas es exactamente cuántas vistas tendrás. Creo que la mayoría de los sitios web pueden salirse con hasta 50 vistas principales y hasta 100 subvistas, pero esos son sitios muy grandes. Al mirar algunos sitios que corro, se parece más a 50 vistas en total.

DAL/DAO/DDD - he aprendido acerca de estos términos leyendo con diligencia a través desbordamiento de pila antes de publicar cuestión. No estoy seguro si pertenece a esta lista

Lo hace. DDD es ideal si necesita meta-vistas o meta-modelos. Digamos, si todos sus modelos son bastante similares en estructura, pero difieren solo en las tablas de bases de datos utilizadas y sus vistas casi mapean 1: 1 a los modelos. En ese caso, es un buen momento para DDD. Un buen ejemplo es algún software ERP en el que no necesite un diseño separado para todas las tablas de la base de datos, puede usar una forma uniforme para realizar todas las operaciones CRUD. En este caso, probablemente podría salirse con la suya con un modelo y un par de vistas, todos generados dinámicamente en tiempo de ejecución utilizando un metamodelo que correlaciona las columnas, los tipos y las reglas de la base de datos con la lógica del lenguaje de programación. Pero, tenga en cuenta que dedica tiempo y esfuerzo construir un motor DDD de calidad para que su aplicación no se vea como un programa MS Access pirateado.

sentarse y crear mi propia arquitectura (probable que lo haga si nadie me ilumina aquí :)

Si usted está construyendo un sitio web de cara al público, lo más probable que va a hazlo bien con MVC. Un muy buen punto de partida es mirar los tutoriales en video de CodeIgniter. Me ayudó a comprender qué es realmente MVC y cómo usarlo mucho mejor que cualquier HOWTO o manual que haya leído. Y sólo pueden llevar 29 minutos en total:

http://codeigniter.com/tutorials/

disfrutar.