Design Patterns (ou técnicas) para Escalabilidade

Question

O padrões de design ou técnicas você usou que são especificamente voltados para escalabilidade ?

Patterns como a Flyweight padrão me parece para ser uma versão especializada do Padrão Fábrica , para promover a alta escalabilidade ou quando se trabalha dentro da memória de armazenamento ou restrições.

O que os outros têm você usou? ( Desnormalização de Bases de Dados , etc .) você acha que as regras mudam quando a alta disponibilidade ou escalabilidade é o seu objetivo principal?

situações possíveis são:

• Dispositivos móveis com memória de forma mais limitada, poder de processamento e conectividade de um desktop ou laptop
• alta # de usuários no hardware limitada (estratégias de cache, etc)
• Optimização do esquema do banco para a eficiência em vez de um desenho normalizado (por exemplo, a quebra de colunas SharePoint para armazenamento)

Answer 1

Alguns padrões que vêm em mente:

• aplicação Stateless
• acoplamento frouxo
• Asynchrony
• preguiçoso de carga
• Cache
• O paralelismo
• Partitioning
• Routing

Alguns recursos:

• escalabilidade Melhores Práticas: Lições do eBay
• Disponibilidade e consistência apresentação do CTO Dr. Werner Vogels da Amazon
• Microsoft PDC'08
• melhores práticas de construção Scalable Nuvem Pronto Based Service

Answer 2

Faça o aplicativo como apátrida possível. Será mais fácil de se adaptar a um farm de servidores.

Answer 3

Nada é de graça - tudo se resume ao que são os compromissos aceitáveis, a fim de atingir seus objetivos de negócios. As principais variáveis ??que são:

• Custo
• Disponibilidade
• Consistência
• Sobrevivência (por exemplo, de partição Tolerância)

Um excelente papel para ler sobre o assunto.

Eu acredito que uma boa métrica seria examinar a curva "custo / user" e tentar mantê-lo para a progressão linear (assumindo que o custo aceitável por usuário é um parâmetro conhecido: -)

Os padrões de projeto desempenham um papel, mas é a arquitetura global que é mais importante. Um poderia ter sido muito completo no nível de módulo, mas perdeu restrições de nível de rede e sofre de escalabilidade como uma consequência.

No final do dia, eu acredito que é preciso perguntar-se (ela mesma): para o tipo de falha X, quantos "usuários" podem ser afetados e por quanto tempo

Haverá sempre uma SPOF (único ponto de falha) em algum lugar, mas pode-se projetar um sistema de tal forma que este SPOF é movido mais perto dos pontos finais (por exemplo, usuários). Em muitos casos, porém, o SPOF está fora do controlo da aplicação, por exemplo, rede POP indisponíveis.

De qualquer forma, eu poderia passar horas sobre o assunto ...

Answer 4

A (arquitetura de software Padrões Orientada) POSA livros são uma grande fonte de tais padrões.

POSA 4 , especialmente, está preocupado com computação distribuída, mas todos os volumns estão cheios de padrões de escalabilidade.

Answer 5

O que tenho observado com a lógica da aplicação Stateless é que ele introduz muitas outras outras exigências, como o bloqueio em DB que eventualmente, em seguida, trabalhar contra a escalabilidade.

Vamos dizer que a lógica aplicativo implantado não mantém estado entre um farm de servidores, em seguida, para um pedido que é bater dois nós de um cluster ao mesmo tempo temos de introduzir conceitos como DB bloqueio para certificar-se apenas um pedido será processado.

Estou lidando tais situações agora e queria saber como toda a gente está lidando com esse tipo de comportamento sem estado.