de diseño (o técnicas) para la escalabilidad

Question

Lo patrones de diseño o técnicas has utilizados que están orientados específicamente hacia escalabilidad?

Los patrones como el modelo Flyweight me parecen una versión especializada del Factory Pattern, para promover una alta escalabilidad o cuando se trabaja con limitaciones de memoria o almacenamiento.

¿Qué otros has usado? (Denormalization of Databases, etc.) ¿Considera que las reglas cambian cuando su principal objetivo es la alta disponibilidad o la escalabilidad?

situaciones posibles son:

• dispositivos móviles con memoria más limitada, potencia de procesamiento y conectividad que un ordenador de sobremesa o portátil
• altos Número de usuarios de hardware limitada (estrategias de caché, etc.)
• Optimización del esquema de la base de datos para la eficiencia en lugar de un diseño normalizado (por ejemplo, ajuste de columnas de SharePoint para el almacenamiento)

Answer 1

Unos patrones que vienen en mente:

• aplicación sin estado
• acoplamiento flojo
• asincronía
• La carga diferida
• almacenamiento en caché
• Paralelismo
• Partición
• enrutamiento

Algunos recursos:

• Scalability Best Practices: Lessons from eBay
• Availability & Consistency presentación de CTO de Amazon Dr. Werner Vogels
• Microsoft PDC'08 Presentations
• Best Practices In Building Scalable Cloud Ready Service Based

Answer 2

Haga que la aplicación sea tan apátrida como sea posible ble. Será más fácil adaptarse a una granja de servidores.

Answer 3

Nada es gratis, todo se reduce a cuáles son los compromisos aceptables para cumplir con los objetivos de su negocio. Las principales variables de ser:

• Costo
• disponibilidad
• consistencia
• de supervivencia (por ejemplo, tolerancia de partición)

Un excelente paper para leer en el tema.

Creo que una buena métrica sería examinar el "usuario/coste" curva e intentar mantenerlo hasta la progresión lineal (suponiendo que el costo aceptable por usuario es un parámetro conocido :-)

Los patrones de diseño hacen juego un papel, pero es la arquitectura general lo que más importa. Uno podría haber sido muy minucioso a nivel de módulo, pero se han perdido restricciones de nivel de red y la escalabilidad sufre como consecuencia.

Al final del día, creo que uno debe preguntarse a sí mismo: para el tipo de falla X, ¿cuántos "usuarios" pueden verse afectados y durante cuánto tiempo?

Siempre habrá un SPOF (Single Point Of Failure) en alguna parte, pero uno puede diseñar un sistema de modo que este SPOF se mueva más cerca de los puntos finales (por ejemplo, los usuarios). Sin embargo, en muchos casos, SPOF está fuera del control de la aplicación, p. red POP no disponible.

De todos modos, podría pasar horas sobre el tema ...

Answer 4

El POS Los libros A (Arquitectura de software orientada a patrones) son una gran fuente para tales patrones.

POSA 4, especialmente, se ocupa de la informática distribuida, pero todos los volúmenes están llenos de patrones de escalabilidad.

Answer 5

Lo que he observado con la lógica de la aplicación sin estado es que introduce muchos otros requisitos, como el bloqueo en la base de datos, que finalmente funciona en contra de la escalabilidad. Digamos que la lógica de la aplicación desplegada es sin estado en una granja de servidores y luego, para una solicitud que golpea dos nodos de un clúster, debemos introducir conceptos como el bloqueo de la base de datos para asegurarnos de que solo se procesa una solicitud.

Estoy lidiando con tales situaciones ahora y me preguntaba cómo todos los demás están lidiando con ese comportamiento sin estado.