AWS可扩展架构设计

Question

我目前正在使用AWS基础架构实现我的第一个Web应用程序并学习基础知识。我遇到了一个设计问题所以想出了以下场景来说明我的问题：

假设我正在制作一个网站应用程序，将网站保存/打印为pdf并将其存储在S3上。前端有一个单一的形式。用户可以键入要保存为pdf的站点的URL，然后单击“提交”。应用程序应将给定网址的页面打印为pdf，并将文件显示给用户。

为了使应用程序可扩展，我想象点击提交会将SQS消息发送到具有要处理的URL的队列。然后，一队工人可以从这个队列消费，创建pdfs＆amp;将它们存储在S3中，然后将S3密钥/路径存储到SimpleDB。我遇到的麻烦是工作人员如何通知网络应用程序处理完成？

示例设计：

我想Web应用程序可以继续轮询SimpleDB，直到S3键的条目出现，但这个解决方案看起来有点笨拙。我觉得这是一个必须经常遇到的模式/问题。有人能提供一种解决这个问题的常用方法吗？

此外，云中常见设计模式的任何推荐资源都将非常有用。

Answer 1

除非你使用像WebSockets这样的东西，否则我不认为这是一个问题。当用户发出请求时，Web应用程序将轮询SimpleDB（如您所述）以检查处理是否完成（或者是否存在错误）。使用类似WebSockets的东西，然后您可以拥有Web应用程序订阅的另一个队列，以便在处理完成时得到通知，然后通知浏览器它已完成。

Answer 2

正如您所说，除了前端之外，您基本上已经解决了所有问题，前端需要轮询我们的后端API以查看媒体是否已准备就绪。在我的公司，我们按照上面的说法进行操作，提供网页截图，还有PDF，办公文档和处理编码视频和音频的jpg快照。

我们使用ajax进行更新，并将它们设置为每秒ping几次然后逐渐回退到每秒一次，每隔几秒就不会对我们的服务器造成太大的压力。另一个选项，正如提到的另一个答案，将使用websockets，这是一个与服务器的持久连接，您可以“推”和“拉”数据。大多数人都使用ajax轮询方法。使用像Apache这样的老技术，对于成千上万的连接来说这可能是一个大问题，但是对于Nginx，Node和中间缓存这样的事情并不是什么大问题。

Answer 3

您可以在S3中存储对象（如标记），然后轮询S3而不是简单的DB。通过这种方式，您可以避免对SimpleDB施加压力，并且您的轮询性能将更加稳定。

您可以从您的Web应用程序实例进行轮询，甚至可以从ajax层轮询。 （虽然后者不是最佳选择，因为这些调用中的任何错误都不会记录在您的服务器中）