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

Question

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

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

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

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

Answer 1

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

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

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

• Необходимо пройти нагрузочное тестирование (40 000 заказов; 25 000 пользователей в день).

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

HtH

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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