Подходы к созданию файлового сервера

Question

Я работаю над созданием файлового сервера, который может снять нагрузку с основного веб-сайта и обслуживать изображения/файлы через Интернет для клиента.

Основные задачи файлового сервера:
- Сними нагрузку с основного сервера хостинг сайта
- Повторное использование существующего кода веб-сервер базы и избежать дублирования кода/логики для лучшей ремонтопригодности
- Будучи масштабируемой для увеличения downloads
- Скрыть реальный путь загрузки URL-адреса от пользователя

Имея в виду выше, я мог бы придумать два подхода. Представление схемы последовательности двух подходов для удобства понимания [извинения за искаженное использование диаграммы последовательности]. Ни один из подходов не будет удовлетворять всем моим целям.

Какой из этих подходов вы бы рекомендовали рассмотреть мои цели?
Есть ли лучший третий подход?

Некоторые различия, я мог думать:
- Подход № 1 приведет к дублированию кода BL вызывает ремонтопригодность вопросы
- Подход № 2 будет повторно использовать код и централизовать BL восстанавливающий ремонтопригодность вопросы
- Approach # 1 будет уменьшать количество сетевых вызовов, в то время как # 2 увеличивает их

Концепция файловых серверов, масштабируемость загрузок, распределение полосы пропускания все время были там некоторое время. Пожалуйста, поделитесь своими мыслями!

ОБНОВЛЕНО:
Подход № 1 выглядит очень привлекательно, как он принимает нагрузку с основного сервера полностью. Единственная проблема, с которой приходится обращаться в # 1, - это проблемы с дублированием кода и ремонтопригодностью. Это можно было бы преодолеть, имея только один проект для BL/DAC, содержащий функциональные возможности, необходимые как для веб-службы, так и для файлового сервера. И ссылайтесь на сборку/библиотеку в проектах веб-сервиса и файлового сервера. Теперь есть только один код BL/DAC для поддержки, а также избегает сетевых вызовов в подходе №2.

Answer 1

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

Большую часть времени, простое решение является лучшим решением. Просто разместите их на другом сервере под другим субдоменом, то есть http://content.mydomain.com/img/xyz.jpg. Вы можете размещать их в центре обработки данных на выделенном сервере, предоставляя свой перфорацию (рядом с основой), вы можете загрузить баланс URL и иметь 2+ серверов в 2+ разных центрах обработки данных, что даст вам устойчивость и масштабируемость.

Задача maintence заключается в том, чтобы найти замену при продвижении вашего сайта, чтобы жить, чтобы заменить пути контента dev/uat контуром контента в реальном времени (вам нужно было только это сделать в css-файлах, так как вы могли хранить пути для содержимого, используемого в файлах aspx для данных конфигурации).