Консультации по архитектуре обработки изображений

Question

Я работаю над стандартным веб-приложением ASP.NET MVC 3 (размещенным на IIS 7). Сайт позволяет пользователям загружать фотографии, между прочим.

Процесс загрузки выглядит следующим образом:

1. Пользователь использует виджет (в настоящее время plupload ) для выбора файлов на своем ПК.
2. AJAX-вызов происходит с моим сервером, с изображением в HTTP POST (Request.Files)
3. Сервер изменяет размер фотографии N количество раз
4. Каждая фотография с измененным размером загружается в Amazon S3

На данный момент все вышеперечисленное реализовано с использованием метода «забей и забудь» с использованием TPL .NET 4.0.

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

Я думаю о размещении службы WCF в качестве службы Windows, которая опрашивает папку с изображениями.

Мой основной веб-сайт будет просто отправлять изображение в папку «Просмотрено», а затем служба будет заботиться об обработке изображения и загрузке.

Пользователь не должен быть уведомлен "немедленно", что фотография сделана. Другими словами, сейчас мы показываем сообщение «Ваше изображение обрабатывается и скоро будет доступно».

Подводя итог, услуга должна:

1. Изменить размер изображения
2. Загрузка изображений на S3
3. Чтение / запись в базу данных
4. Возможность «повторить» неудачные изображения

Есть совет? FileSystemWatcher хороший вариант?

Answer 1

В моем текущем проекте мы реализовали подобный сервис промежуточного программного обеспечения, отвечающий за обработку данных с использованием FileSystemWatcher с относительным успехом. О чем нужно помнить:

1. Убедитесь, что реализовали какую-то очередь для обработки ядра. Запуск 100 процессов преобразования изображений не является хорошей идеей. Рассмотрите возможность использования ThreadPool.
2. FileSystemWatcher выдаст уведомления, как только файл будет создан, и в этот момент он все еще может быть заблокирован только для записи - вам придется периодически проверять, чтобы определить подходящий момент для начала обработки. Вероятно, с использованием основного цикла и очереди.
3. Отслеживайте мелкозернистые изменения состояния (например, file_created, file_processing, file_processed, file_uploading и т. Д.). Возможно, они вам действительно понадобятся для отладки.

Надеюсь, это поможет и удачи.