Шаблоны проектирования (или методы) для масштабируемости - PullRequest
25 голосов
/ 17 сентября 2009

Какие шаблоны проектирования или методы вы использовали, которые специально предназначены для масштабируемости ?

Шаблоны, такие как Flyweight , кажутся мне специализированной версией Factory Pattern , для обеспечения высокой масштабируемости или при работе в пределах памяти или ограничений хранения.

Какие другие вы использовали? ( Денормализация баз данных и т. Д.) Считаете ли вы, что правила меняются, когда вашей основной целью является высокая доступность или масштабируемость?

Возможные ситуации:

  • Мобильные устройства с более ограниченными памятью, вычислительной мощностью и возможностями подключения, чем настольный компьютер или ноутбук
  • Большое количество пользователей на ограниченном оборудовании (стратегии кэширования и т. Д.)
  • Оптимизация схемы базы данных для повышения эффективности вместо нормализованного дизайна (например, перенос столбцов SharePoint для хранения)

Ответы [ 5 ]

45 голосов
/ 17 сентября 2009

Несколько шаблонов, которые приходят на ум:

  • Заявка без гражданства
  • Слабая связь
  • Асинхронность
  • Ленивая загрузка
  • Кэширование
  • параллелизм
  • Разметка
  • Маршрутизация

Некоторые ресурсы:

10 голосов
/ 17 сентября 2009

Сделайте приложение как можно без гражданства. Будет легче адаптироваться к ферме серверов.

6 голосов
/ 17 сентября 2009

Нет ничего бесплатного - все сводится к тому, что является приемлемым компромиссом для достижения целей вашего бизнеса. Основными переменными являются:

  • Стоимость
  • Наличие
  • Последовательность
  • Живучесть (например, допуск раздела)

Отличная статья для чтения по теме.

Я полагаю, что хорошей метрикой было бы изучение кривой «затраты / пользователь» и попытка поддерживать ее в линейном прогрессе (предполагая, что приемлемая стоимость на пользователя является известным параметром: -)

Шаблоны проектирования действительно играют роль, но наиболее важной является общая архитектура. Можно было бы быть очень тщательным на уровне модуля, но как следствие пропущенные ограничения сетевого уровня и масштабируемость страдают.

В конце концов, я считаю, что нужно спросить себя: для типа сбоя X сколько «пользователей» может быть затронуто и как долго?

Где-то всегда будет SPOF (единая точка отказа), но можно спроектировать систему таким образом, чтобы этот SPOF перемещался ближе к конечным точкам (например, пользователям). Однако во многих случаях SPOF находится вне контроля приложения, например, сетевой POP недоступен.

Во всяком случае, я мог бы потратить часы на эту тему ...

2 голосов
/ 17 сентября 2009

Книги POSA (Patterns-Oriented Software Architecture) являются отличным источником для таких шаблонов.

POSA 4 особенно касается распределенных вычислений, но все столбцы полны шаблонов масштабируемости.

1 голос
/ 05 декабря 2012

Что я заметил в логике приложения без сохранения состояния, так это в том, что оно вводит множество других требований, таких как блокировка БД, которые в конечном итоге затем работают против масштабируемости.

Допустим, что развернутая логика приложения не имеет состояния по всей ферме серверов, а затем для запроса, который одновременно обрабатывает два узла кластера, мы должны ввести такие понятия, как блокировка БД, чтобы обеспечить обработку только одного запроса.

Я имею дело с такими ситуациями сейчас, и мне было интересно, как все остальные имеют дело с таким поведением без гражданства.

...