Идеи архитектуры для статического ресурса (изображения) веб-сервера? - PullRequest
0 голосов
/ 20 июля 2009

Мы собираемся удалить все статические ресурсы (в основном, изображения) в нашем веб-приложении ASP.NET 2.0 и перенести их на отдельный сервер. Основные требования к дизайну касаются скорости (поэтому кэширование будет иметь важное значение) и минимального уровня безопасности (чтобы люди не могли просто напрямую загружать или копировать изображения). Использование простого веб-сервиса .net 2.0 сразу же приходит на ум, но я беспокоюсь о возможных проблемах с производительностью и кешированием? Это действительная проблема?

Так, какие архитектурные установки подойдут этому счету?

Некоторые другие моменты для рассмотрения:

  • WCF пока не подходит, так как мы еще не переходим на .net3.5 в течение нескольких месяцев
  • Время разработки ограничено 2 неделями

Редактировать - Чтобы уточнить нашу позицию:

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

Ответы [ 3 ]

2 голосов
/ 20 июля 2009

Просто используйте статическую папку, настроенную как виртуальную папку в IIS. Это даст все, что вам нужно. Кеширование, скорость и пр.

Минимальная псевдобезопасность может быть достигнута при случайных именах папок / файлов. Или инжекторы с инжекционным трубопроводом. Конечно, вы должны отключить списки папок и т. Д.

2 голосов
/ 20 июля 2009

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

Многопоточность и синхронизация обходятся дороже, чем вы думаете. Асинхронная архитектура довольно широко используется на серверах и может быть очень ресурсоэффективной. Часто один поток настолько быстр, что может значительно обогнать многопоточные серверы.

Используя asynccore (инфраструктура асинхронного сервера Python), я мог бы создать однопоточный сервер XML-RPC, который мог бы подключаться к базе данных, выдавать простой запрос, объединять соединения и отвечать на запросы быстрее, чем многопоточный сервер с пул потоков. На одном процессоре машина была примерно в 2,5 раза быстрее.

Прокатить собственный асинхронный сервер не так уж и сложно. Я видел их назначенными на второй курс по информатике. Вероятно, вы можете найти библиотеки веб-сервера Async для большинства языков - Python входит в стандартную библиотеку.

Наконец, у меня не так много времени, чтобы люди говорили: «Сделай это, но это должно быть сделано за две недели». Если ваше экономическое обоснование может оправдать только две недели разработки, не беспокойтесь - экономическое обоснование слишком незначительно, если только оно не является низко висящим плодом. Я механически перевожу маргинальное экономическое обоснование в совсем не экономическое обоснование. Если это важно, дай мне время сделать это по-настоящему. Если это не важно, не делай этого вообще.

Вот и все - просто сэкономил вам две недели и все текущие расходы на техническое обслуживание.

1 голос
/ 20 июля 2009

Вы можете разработать простой HttpHandler (+ MVC Routing для удобных для пользователя URL). Но это требует ручной обработки сжатий, заголовков кэша, частей контента и так далее.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...