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

Question

¿Qué patrones de diseño o técnicas has utilizado específicamente para la escalabilidad ?

Patrones como el Flyweight me parecen a mí ser una versión especializada del Patrón de fábrica , para promover una alta escalabilidad o cuando se trabaja dentro de las limitaciones de memoria o almacenamiento.

¿Qué otros has usado? ( Desormalización de bases de datos , etc. .) ¿Le parece que las reglas cambian cuando la alta disponibilidad o escalabilidad es su objetivo principal?

Las posibles situaciones son:

• Dispositivos móviles con memoria, potencia de procesamiento y conectividad más limitadas que una computadora de escritorio o portátil
• Alto número de usuarios en hardware limitado (estrategias de almacenamiento en caché, etc.)
• Optimización del esquema de la base de datos para la eficiencia en lugar de un diseño normalizado (por ejemplo, envoltura de columnas de SharePoint para almacenamiento)

Answer 1

Algunos patrones que vienen en mente:

• Aplicación sin estado
• Acoplamiento suelto
• Asincronía
• Carga diferida
• Almacenamiento en caché
• Paralelismo
• Particionamiento
• Enrutamiento

Algunos recursos:

• Mejores prácticas de escalabilidad: lecciones de eBay
• Availability & amp; Consistencia presentación del CTO de Amazon Dr. Werner Vogels
• Presentaciones de Microsoft PDC'08
• Mejores prácticas en construcción Servicio escalable listo para la nube basado

Answer 2

Haga que la aplicación sea lo más apátrida posible. 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 son:

• Costo
• Disponibilidad
• Consistencia
• Supervivencia (por ejemplo, tolerancia de partición)

Un excelente

Los patrones de diseño juegan un papel importante, pero es la arquitectura general lo que más importa. Uno podría haber sido muy exhaustivo a nivel de módulo, pero las limitaciones de nivel de red perdidas y la escalabilidad sufren como consecuencia.

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

Siempre habrá un SPOF (Punto único de falla) en alguna parte, pero uno puede diseñar un sistema de tal manera que este SPOF se acerque a los puntos finales (por ejemplo, los usuarios). Sin embargo, en muchos casos, el SPOF está fuera del control de la aplicación, p. POP de red no disponible.

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

Answer 4

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

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

Answer 5

Lo que he observado con la lógica de aplicación sin estado es que introduce muchos otros requisitos, como el bloqueo en la base de datos, que eventualmente funcionan en contra de la escalabilidad.

Digamos que la lógica de la aplicación implementada no tiene estado en una granja de servidores, entonces para una solicitud que está llegando a dos nodos de un clúster al mismo tiempo, tenemos que introducir conceptos como bloqueo de base de datos para asegurarnos de que solo se procesará 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.