Я пытаюсь придумать крупномасштабное приложение вокруг мыслительного процесса.
Скажем, у меня есть клиент, которому нужен новый клиентский сайт, и он оценивает 40 000 заказов в день с уже 25 000 пользователей. При настройке приложения, как вы определяете, требуется ли распределенная архитектор? Должен ли я использовать веб-ферму? и др.
В прошлом я в основном создавал 2-х уровневые (физические) приложения, и я действительно хочу улучшить свое понимание.
Любое понимание было бы замечательно!
Это будет зависеть от множества других факторов, чем просто количество заказов в день. Где он будет размещаться? Как выглядит эта физическая архитектура? Что еще делает приложение помимо электронной торговли? Нужно ли интегрироваться с другими приложениями (помимо платежных шлюзов, конечно)? Etc.
Простое двухуровневое приложение в правильной облачной среде размещения (скажем, VMware, например), которое может масштабироваться динамически, будет отлично работать для веб-сайта электронной коммерции. Простое двухуровневое приложение в правильной локальной среде размещения (веб-ферма с балансировкой нагрузки) также должно отлично работать на веб-сайте электронной торговли. Это разница между масштабированием (потенциально скрытым с виртуализацией, которая заканчивается нечеткой шкалой) и масштабированием (добавлением большего количества серверов).
Распределенная архитектура позволит вам распределить загрузку системы (например, обработку заказа) на серверы 1: M, которые сидят (возможно) за балансировщиком нагрузки. Это очень распространенный подход, который также очень хорошо работает для веб-сайта электронной торговли.
По моему мнению, нет никакой архитектуры или системного дизайна, который бы соответствовал каждой форме. Ближайшая архитектура, подходящая для каждой формы (опять же, мое мнение), будет ориентированной на обслуживание архитектурой. Если все бизнес-процессы и логика являются сервисами (и спроектированы правильно), то независимо от того, как ваши требования меняются, независимо от того, как ваша среда хостинга выглядит или меняется, и независимо от того, какие у вас требования интеграции, ваша система может справиться с ней или никаких изменений.
Загрузка. Проверяйте новое приложение с помощью get-go.
Так как работа с большим дизайном никогда не даст вам результатов, которые вы ожидаете от этого (более 15 лет опыта), самое лучшее, что нужно сделать, - это создать дизайн для изменения и позволить правильной архитектуре выйти из ваших требований.
Учитывая ваше описание, примите гибкую методологию для этого проекта и используйте его методы, чтобы помочь вашему проекту в успехе. Одна из этих жизненно важных практик - это "определение совершенства" для всей работы, которую вы выполняете. Очевидно, что в вашем DoD у вас будет элемент:
Как вы могли бы начать разработку, одна из первых вещей - это настроить среду, чтобы иметь возможность запускать такой тест нагрузки. Если это никогда не произойдет, вы уже знаете очень рано в проекте, что у вас будут проблемы. Испытав нагрузку столько раз, сколько необходимо (по крайней мере один раз каждый спринт), вы будете знать, что требование к масштабу/может обрабатываться вашей архитектурой.
HtH
Поскольку вы кодируете .Net, поместите приложение в Azure (da cLOUD man, DA CLOUD!;).
Это поможет вам получить необходимую вычислительную мощность. Приложение будет работать, если вы не совершаете глупых ошибок.
Масштабирование можно решить, по крайней мере частично, с балансировкой нагрузки.
Concurrency может быть вашей истинной проблемой. Распределенные транзакции - это инструмент с тяжелыми инструментами, но он не будет решать каждый случай использования без дополнительных размышлений.
Некоторые финансовые компании имеют дополнительные требования к безопасности в отношении веб-серверов, имеющих прямой доступ к базе данных.