AWS可伸縮架構設計

我目前正在實施我的第一個使用AWS基礎架構並學習基礎知識的Web應用程序。我遇到了一個設計問題，所以想出了以下場景來說明我的問題：AWS可伸縮架構設計

假設我正在製作一個網絡應用程序，將網站保存/打印爲pdf並將其存儲在S3上。前端有一個單一的形式。用戶可以輸入他們想要保存爲pdf的網站的網址，然後點擊提交。該應用程序應打印在給定的網址的PDF格式的頁面，並呈現給用戶。

爲了使應用具有可伸縮性，我想象點擊提交會發送一個SQS消息到一個隊列中並且要處理這個url。然後一隊工人可以從這個隊列中消耗，創建pdfs &將它們存儲在S3中，然後將S3密鑰/路徑存儲到SimpleDB。我遇到的麻煩是工作人員如何通知Web應用程序處理完成？

示例設計： Example Design

我想象中的Web應用程序可能持續調查的SimpleDB，直到出現了S3鍵的條目但是這種解決方案似乎有點笨拙。我覺得這是一個必須經常遇到的模式/問題。任何人都可以提供一種解決這個問題的常用方

此外，雲中常見設計模式的任何推薦資源都將非常有益。

來源

2012-04-07 Derek Gourlay

+1 [AWS Simple Icons]（http://aws.amazon.com/architecture/icons/ ）基礎架構圖已經很好:) – 2012-04-07 12:28:31

謝謝。在其中一個AWS博客上找到了他們的鏈接。絕對有用！ – 2012-04-15 05:25:57

除非你使用類似WebSockets的東西，否則我不認爲這是一個問題。當用戶發出請求時，Web應用程序將輪詢SimpleDB（如您所述）以檢查處理是否完成（或者是否有錯誤）。通過WebSockets之類的東西，您可以擁有另一個Web應用程序將訂閱的隊列，以在處理完成時得到通知，然後通知瀏覽器它已完成。

來源

2012-04-07 07:49:16

感謝Greg的想法。我不確定訂閱隊列的前端是否合理，因爲在ELB後面可能會運行多個Web應用程序實例。然而讓他們都訂閱SNS話題可能是有道理的。然而，我在前端編程的經驗很少，並且不確定在接收到SNS通知後我會如何刷新頁面。每個Web應用程序在收到SNS消息時都必須檢查某種會話ID，並驗證它是否與該機器上當前活動的會話相關。除此之外，我有點卡住了：P – 2012-04-07 08:56:44

我認爲反覆輪詢SimpleDB並不是_that_不好，但是我認爲可能有更優雅的解決方案。 – 2012-04-07 08:57:25

一旦用戶的瀏覽器使請求開始處理，您立即返回響應。除非您保持連接對瀏覽器開放，否則用戶將不得不輪詢Web服務器以檢查處理是否已完成。對SimpleDB的請求相當便宜（與使用WebSockets或類似方法支持即時頁面刷新所需的操作相比）。您可以在後臺使用AJAX請求輪詢結果，然後在處理完成後更新頁面。 – 2012-04-07 11:55:49

正如你所說的，你基本上已經解決了除前端之外的所有問題，這需要輪詢我們的後端API以查看媒體是否準備就緒。在我的公司，我們按照上述說法進行操作，呈現網頁截圖，還可以製作PDF，辦公文檔和處理編碼視頻和音頻的jpg快照。

我們使用ajax進行更新，並設置它們以便它們每秒ping幾次，然後逐漸回退到每秒一次，並且每隔幾秒鐘一次，以免在我們的服務器上造成太大的壓力。另一個選項，正如提到的其他答案一樣，將使用websockets，它是一個到服務器的持久連接，您可以「推送」和「拉取」數據。儘管大多數人都使用ajax輪詢方法。對於像Apache這樣的老技術來說，這對於數千個連接來說可能是一件大事，但對於像Nginx，Node和中間緩存這樣的事情來說，這並不是什麼大不了的事情。

來源

2013-02-06 06:34:56

您可以在S3中存儲一個對象（如標記），然後輪詢S3而不是簡單的數據庫。這樣可以避免對SimpleDB施加壓力，並且您的輪詢性能會更穩定。

您可以通過您的web應用程序實例進行輪詢，或者甚至可以從ajax圖層進行輪詢。（儘管後者不是最好的選擇，因爲這些調用中的任何錯誤都不會記錄在您的服務器中）

來源

2015-05-22 11:38:07 Daniel777

AWS可伸縮架構設計

回答

相關問題