Как определить распределенную архитектуру?

Question

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

Предположим, у меня есть клиент, которому нужен новый клиентский сайт, и он оценивает 40 000 заказов в день с уже 25 000 пользовательской базой. При настройке приложения, как вы определяете, требуется ли распределенная архитектор? Должен ли я использовать веб-ферму? и т. д.

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

Любое понимание было бы замечательным!

Answer 1

Это будет зависеть от множества других факторов, чем просто количество заказов в день. Где он будет размещаться? Как выглядит эта физическая архитектура? Что еще делает приложение помимо электронной торговли? Нужно ли интегрироваться с другими приложениями (помимо платежных шлюзов, конечно)? И т. Д.

Простое двухуровневое приложение в правой облачной среде размещения (скажем, VMware, например), которое может масштабироваться динамически, будет отлично работать для веб-сайта электронной коммерции. Простое двухуровневое приложение в правильной локальной среде размещения (веб-ферма с балансировкой нагрузки) также должно отлично работать на веб-сайте электронной торговли. Это разница между масштабированием (потенциально скрытым с виртуализацией, которая заканчивается нечеткой шкалой) и масштабированием (добавлением большего количества серверов).

Распределенная архитектура позволит распределить загрузку системы (например, обработку заказа) на серверы 1: M, которые сидят (возможно) за балансировщиком нагрузки. Это очень распространенный подход, который также будет очень хорошо работать на веб-сайте электронной торговли.

На мой взгляд, нет единой архитектуры или системного дизайна, который подходит для каждой формы. Ближайшая архитектура, подходящая для каждой формы (опять же, мое мнение), будет ориентированной на обслуживание архитектурой. Если все бизнес-процессы и логика являются сервисами (и спроектированы правильно), то независимо от того, как ваши требования меняются, независимо от того, как ваша среда хостинга выглядит или меняется, и независимо от того, какие у вас требования интеграции, ваша система может справиться с ней или никаких изменений.

Answer 2

Загрузить Проверьте свое новое приложение с самого начала.

Поскольку делать большой дизайн вперед никогда не даст вам результатов, которые вы ожидаете от него (более 15 лет опыта), самое лучшее, что нужно сделать, это создать дизайн для изменения и позволить правильной архитектуре выйти из ваших требований ,

Учитывая ваше описание, примите гибкую методологию для этого проекта и используйте его методы, чтобы ваш проект был успешным. Одна из этих жизненно важных практик - это «определение совершенства» для всей работы, которую вы выполняете. Очевидно, что в вашем Министерстве обороны вы будете иметь товар:

• Нужно пройти испытание на нагрузку (40 000 заказов, 25 000 пользователей в день).

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

HtH

Answer 3

Масштабирование может быть решена, по меньшей мере, частично, с балансировки нагрузки.

Параллельность может быть вашей настоящей проблемой. Распределенные транзакции - это тяжелый инструмент, но он не будет решать каждый случай использования без дополнительной мысли.

Некоторые финансовые компании имеют дополнительные требования к безопасности в отношении веб-серверов, имеющих прямой доступ к базе данных.

Answer 4

Поскольку вы кодируете .Net, поместите приложение в Azure (da cLOUD man, DA CLOUD!;).

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