AWS Scalable Architecture Design

Question

В настоящее время я реализую свое первое веб-приложение, использующее инфраструктуру AWS и изучаю основы. Я столкнулся с проблемой дизайна, поэтому придумал следующий сценарий, чтобы проиллюстрировать мою проблему:

Предположим, я делаю веб-приложение, которое сохраняет/печатает веб-сайт в формате pdf и сохраняет его на S3. Передняя часть имеет одну форму. Пользователь набирает URL-адрес для сайта, который они хотят сохранить в формате pdf, и нажмите «Отправить». Приложение должно распечатать страницу с заданным URL-адресом в pdf и представить файл пользователю.

Чтобы сделать приложение масштабируемым, я предположил, что нажатие кнопки отправки отправит сообщение SQS в очередь с URL-адресом для обработки. Затем из этой очереди может быть задействован флот рабочих, создайте pdfs &, сохраните их в S3, затем сохраните ключ/путь S3 в SimpleDB. Проблема, с которой я столкнулся, заключается в том, как рабочий уведомляет веб-приложение о завершении обработки?

Пример дизайн:

Я представляю Web App может постоянно опрос SimpleDB, пока не появится запись для ключа S3, однако это решение кажется немного неуклюжим. Я чувствую, что это шаблон/проблема, с которой обычно приходится сталкиваться. Может ли кто-нибудь предоставить общий способ решения этой проблемы?

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

Answer 1

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

Answer 2

Как вы уже заявили, вы в основном решили все свои проблемы, кроме front-end, которые должны были бы опросить наш API-интерфейс, чтобы узнать, готов ли носитель. В моей компании мы делаем то, что вы сказали выше, предоставляя скриншоты веб-страниц, а также снимки JPG для PDF-файлов, офисных документов и обработки кодирования видео и аудио.

Мы используем ajax для обновлений и устанавливаем их так, чтобы они выполняли ping несколько раз в секунду, а затем постепенно отбрасывали один раз в секунду и каждые несколько секунд, чтобы не накладывать слишком много нагрузки на наши серверы. Другой вариант, как упоминалось в другом упоминании, будет использовать websockets, который является постоянным соединением с сервером, с которого вы можете «вытолкнуть» и «вытащить» данные. Тем не менее, большинство из них использует подход опроса ajax. Благодаря старым технологиям, таким как Apache, это может быть большой проблемой для тысяч подключений, но с такими вещами, как Nginx, Node и промежуточное кэширование, это не имеет большого значения.

Answer 3

Вы можете сохранить объект (как маркер) в S3, а затем опросить S3 вместо простой БД. Таким образом, вы можете избежать стресса на вашем SimpleDB, и ваши результаты голосования будут более стабильными.

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