Modèles de conception (ou techniques) pour l'évolutivité

Question

Quels modèles de conception ou techniques avez-vous utilisés qui sont spécifiquement adaptés à la évolutivité ?

Des motifs tels que le motif Flyweight me paraissent être une version spécialisée du Modèle d'usine >, pour favoriser une grande évolutivité ou lorsque vous travaillez dans des contraintes de mémoire ou de stockage.

Qu'avez-vous déjà utilisé? ( Dénormalisation des bases de données , etc. .) Trouvez-vous que les règles changent lorsque la haute disponibilité ou l'évolutivité est votre objectif principal?

Les situations possibles sont les suivantes:

• Appareils mobiles dotés d'une mémoire, d'une puissance de traitement et d'une connectivité plus limitées qu'un ordinateur de bureau ou un ordinateur portable
• Nombre élevé d'utilisateurs utilisant du matériel limité (stratégies de mise en cache, etc.)
• Optimisation du schéma de base de données pour plus d’efficacité au lieu d’une conception normalisée (par exemple, habillage des colonnes SharePoint pour le stockage)

Answer 1

Quelques motifs qui viennent à l’esprit:

• Application sans état
• Couplage lâche
• Asynchronisme
• Chargement paresseux
• Mise en cache
• parallélisme
• Partitionnement
• Routage

Quelques ressources:

• Meilleures pratiques d'évolutivité: enseignements tirés d'eBay
• Disponibilité & amp; Présentation cohérente du Dr. Werner Vogels, CTO d'Amazon
• Présentations Microsoft PDC'08
• Meilleures pratiques en matière de construction Service évolutif compatible avec le cloud

Answer 2

Rendre l'application aussi apatride que possible. Sera plus facile à adapter à une batterie de serveurs.

Answer 3

Rien n’est gratuit - il s’agit des compromis acceptables pour atteindre vos objectifs commerciaux. Les principales variables étant:

• Coût
• Disponibilité
• cohérence
• Capacité de survie (par exemple, tolérance de partition)

Un excellent

Les modèles de conception jouent un rôle, mais c'est l'architecture globale qui compte le plus. L’un des modules a peut-être été très complet, mais les contraintes au niveau du réseau et l’évolutivité en ont souffert.

À la fin de la journée, je pense qu’il faut se demander: pour le type d’échec X, combien d’utilisateurs sont "utilisateurs"; peut être affecté et pour combien de temps?

Il y aura toujours un SPOF (Single Point Of Failure) quelque part, mais on peut concevoir un système tel que ce SPOF soit rapproché des terminaux (par exemple, les utilisateurs). Dans de nombreux cas cependant, le SPOF échappe au contrôle de l'application, par exemple. POP réseau non disponible.

Quoi qu'il en soit, je pourrais passer des heures sur le sujet ...

Answer 4

Les manuels POSA (architecture logicielle orientée modèles) sont une excellente source pour de tels modèles.

POSA 4 , en particulier, concerne l'informatique distribuée, mais tous les volumes sont pleins de modèles d’évolutivité.

Answer 5

Ce que j’ai observé avec la logique d’application Stateless, c’est qu’elle introduit de nombreuses autres exigences, comme le verrouillage sur une base de données, qui finit par aller à l’encontre de l’évolutivité.

Disons que la logique d'application déployée est sans état sur une batterie de serveurs, puis pour une demande qui frappe deux nœuds d'un cluster en même temps, nous devons introduire des concepts tels que le verrouillage de base de données afin de nous assurer qu'une seule demande sera traitée.

Je suis confronté à de telles situations maintenant et je me demandais comment tout le monde réagissait face à un tel comportement apatride.