Шаблоны проектирования (или методы) для масштабируемости

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

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

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

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

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

Ответ 1

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

Приложение без гражданства
Свободная муфта
Асинхронность
Lazy loading
Кэширование
Parallelism
Разметка
Routing

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

Рекомендации по масштабируемости: уроки eBay
Доступность и согласованность презентация технического директора Amazon Dr. Werner Vogels
Презентации Microsoft PDC'08
Рекомендации по созданию масштабируемого облачного сервиса на основе

Ответ 2

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

Ответ 3

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

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

Отличная бумага для чтения по этому вопросу.

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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