design-patterns - retry - patrones de diseño de servicios

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

Question

¿Qué patrones de diseño o técnicas ha utilizado que estén específicamente orientados a la escalabilidad ?

Los patrones como el patrón de Flyweight me parecen una versión especializada del patrón de fábrica , para promover una alta escalabilidad o cuando se trabaja dentro de la memoria o las limitaciones de almacenamiento.

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

Las situaciones posibles son:

• Dispositivos móviles con más memoria limitada, capacidad de procesamiento y conectividad 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 mayor eficiencia en lugar de un diseño normalizado (por ejemplo, ajuste de columna de SharePoint para almacenamiento)

Answer 1

Algunos patrones que vienen a la mente:

• Aplicación sin estado
• Bajo acoplamiento
• Asincronía
• Carga lenta
• Almacenamiento en caché
• Paralelismo
• Particionamiento
• Enrutamiento

Algunos recursos:

• Mejores prácticas de escalabilidad: Lecciones de eBay
• Presentación de disponibilidad y consistencia del CTO de Amazon, Dr. Werner Vogels
• Presentaciones de Microsoft PDC''08
• Mejores prácticas en la creación de servicios escalables en la nube listos para servicios

Answer 2

Haga la solicitud lo más apátrida posible. Será más fácil adaptarse a una granja de servidores.

Answer 3

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

Digamos que la lógica de la aplicación implementada no tiene estado en una granja de servidores para una solicitud que está afectando a dos nodos de un clúster al mismo tiempo, tenemos que introducir conceptos como el bloqueo de DB para asegurarnos de que solo se procesará una solicitud.

Estoy lidiando con estas situaciones ahora y me preguntaba cómo todos los demás están lidiando con este tipo de comportamiento sin estado.

Answer 4

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

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

Answer 5

Nada es gratis: se trata de 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 paper para leer sobre el tema.

Creo que una buena métrica sería examinar la curva "costo / usuario" y tratar de mantenerla en una progresión lineal (suponiendo que el costo aceptable por usuario es un parámetro conocido :-)

Los patrones de diseño juegan un papel importante, pero lo que más importa es la arquitectura general. Uno podría haber sido muy minucioso a nivel de módulo, pero las restricciones de nivel de red perdidas 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 por cuánto tiempo?

Siempre habrá un SPOF (punto único de falla) en algún lugar, pero uno puede diseñar un sistema de tal manera que este SPOF se mueva más cerca de los puntos finales (por ejemplo, los usuarios). Sin embargo, en muchos casos, el SPOF está fuera del control de la aplicación, por ejemplo, la red POP no está disponible.

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