#c# #.net #asp.net #architecture #distributed
#c# #.net #asp.net #архитектура #распределенный
Вопрос:
Я пытаюсь разобраться в мыслительном процессе при разработке крупномасштабного приложения.
Допустим, у меня есть клиент, которому нужен новый веб-сайт для клиентов, и он оценивает 40 000 заказов в день с уже 25 000 пользовательской базой. Как вы относитесь к определению того, нужна ли распределенная архитектура при проектировании приложения? Должен ли я использовать веб-ферму? и т.д.
В прошлом я в основном создавал двухуровневые (физические) приложения, и я действительно хочу улучшить свое понимание.
Любая информация была бы отличной!
Комментарии:
1. Лучший совет: привлеките к работе кого-нибудь с проверенным опытом в этой области. В противном случае не принимайте никаких глупых проектных решений и масштабируйте по мере необходимости. Но без опыта трудно отличить глупого от вменяемого
2. 1 к комментарию @sehe — вам нужно обратиться за помощью к кому-то, кто знает, что они делают
3. Хотя я согласен с вами, ребята (sehe и BrandonZeider), не у всех есть возможность сделать то, что вы предлагаете.
4. Вы могли бы подумать о том, чтобы перейти к serverfault.com если вам нужно больше информации по этому поводу.
Ответ №1:
Нагрузочное тестирование вашего нового приложения с самого начала.
Поскольку предварительное проектирование никогда не даст вам результатов, которых вы от него ожидаете (более 15 лет опыта), лучшее, что можно сделать, это спроектировать с учетом изменений и позволить правильной архитектуре появиться в соответствии с вашими требованиями.
Учитывая ваше описание, примите гибкую методологию для этого проекта и используйте ее методы, чтобы привести ваш проект к успеху. Одна из этих жизненно важных практик — иметь «Определение Done» для всей выполняемой вами работы. Очевидно, что в вашем DoD у вас будет элемент:
- Необходимо пройти нагрузочный тест (40 000 заказов; 25 000 пользователей в день).
После этого, когда вы приступите к разработке, одно из первых, что нужно сделать, это, конечно, настроить среду для выполнения такого нагрузочного теста. Если этого никогда не произойдет, вы уже на самом раннем этапе проекта знаете, что у вас будут проблемы. Выполнив нагрузочный тест столько раз, сколько необходимо (по крайней мере, один раз в каждом спринте), вы будете знать, что требования к масштабированию выполняются / могут быть выполнены вашей архитектурой.
HtH
Ответ №2:
Это будет зависеть не только от количества заказов в день, но и от множества других факторов. Где это будет размещено? На что похожа эта физическая архитектура? Что еще делает приложение, помимо электронной коммерции? Требуется ли интеграция с другими приложениями (помимо платежных шлюзов, конечно)? И т.д.
Простое двухуровневое приложение в подходящей облачной среде размещения (скажем, VMware, например), которое может динамически масштабироваться, отлично подойдет для веб-сайта электронной коммерции. Простое двухуровневое приложение в подходящей локальной среде хостинга (веб-ферма с балансировкой нагрузки) также должно отлично работать для веб-сайта электронной коммерции. Это разница между увеличением масштаба (потенциально скрытым при виртуализации, что в конечном итоге приводит к некачественному масштабированию) и расширением (добавление большего количества серверов).
Распределенная архитектура позволила бы вам распределить нагрузку на систему (скажем, обработку заказов) на серверы 1: M, которые находятся (возможно) за балансировщиком нагрузки. Это очень распространенный подход, и он также будет очень хорошо работать для веб-сайта электронной коммерции.
На мой взгляд, не существует единой архитектуры или системного дизайна, который подходил бы под все формы. Наиболее подходящей архитектурой для каждой формы (опять же, на мой взгляд) была бы сервис-ориентированная архитектура. Если все бизнес-процессы и логика являются сервисами (и спроектированы правильно), то независимо от того, как изменяются ваши требования, независимо от того, как выглядит ваша среда размещения или в чем она изменяется, и независимо от того, какие у вас требования к интеграции, ваша система может справиться с этим практически без изменений.
Ответ №3:
Поскольку вы занимаетесь программированием.Net, размести приложение в Azure (da cLOUD man, DA CLOUD! ;).
Это поможет вам получить необходимую вычислительную мощность. Приложение будет работать нормально до тех пор, пока вы не сделаете никаких глупых ошибок.
Ответ №4:
Масштабирование можно решить, по крайней мере частично, с помощью балансировки нагрузки.
Параллелизм может быть вашей настоящей проблемой. Распределенные транзакции — это тяжелый инструмент, но он не решит все варианты использования без дополнительного обдумывания.
Некоторые финансовые компании предъявляют дополнительные требования к безопасности в отношении веб-серверов, имеющих прямой доступ к базе данных.