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

Question

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

Паттерны , такие как Мушиный вес шаблон, как мне кажется, является специализированной версией Заводской Узор, для обеспечения высокой масштабируемости или при работе в рамках ограничений памяти или хранилища.

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

Возможными ситуациями являются:

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

Answer 1

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

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

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

• Лучшие практики масштабируемости:Уроки от eBay
• Доступность и согласованность презентация технического директора Amazon доктораWerner Vogels
• Презентации Microsoft PDC'08
• Лучшие практики создания масштабируемых облачных сервисов На основе

Answer 2

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

Answer 3

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

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

Превосходный бумага чтобы почитать на эту тему.

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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