多台服務器上的數據處理-Azure

Question

我們有WebApi雲服務，該服務接收提要URL的列表作為參數，並從這些提要中返回已解析的實際文章的HTML文件...因此，處理邏輯如下所示：

• 下載所有提要
• 解析提要中的所有文章
• 獲取所有實際文章鏈接
• 下載所有文章html
• 解析所有文章html
• 返回結果

在一台機器（4核）上進行並行處理可以很好地處理帶有少量文章的1個或2個Feed。 但是我們需要能夠同時處理20-30個提要和300-500個文章的體系結構。

這是我們目前的想法。 托管兩個雲服務（Feed解析和Article解析）。

提要解析服務公開給正在向其發送提要列表作為參數的用戶。 該服務將列表拆分成較小的塊，然后將其發送給文章分析服務進行處理。

文章解析服務將在一個雲服務下具有幾個虛擬機實例，默認情況下，Azure將在不同實例上執行每個請求過程（完成負載平衡）

因此結果應該是所有文章都並行處理。

但是我認為，還有其他更聰明的方法可以在Azure上完成此操作嗎？

另外，也不可以進行后台預處理。

非常感謝。

Answer 1

還有其他一些未說明的要求（即，用戶提交請求的響應能力和總處理時間）。 但是，做出一些假設（稍后會異步響應）可能會引起猜測。 我首先想到的是您不需要2個雲服務。 您可能有1個可以接受用戶請求，並將工作單元放置在一個天藍色隊列中。 然后，您可以讓N個工作人員在隊列中等待並獲取下一個可用項目。 完成后，他們可以將結果存儲在持久性存儲（SQL Azure，表/ Blob存儲）中，並將完成通知放在另一個隊列中。 這里有更多的推測，但是除非您已經概要介紹了此工作的樣本集，否則您可能對大部分時間都花在哪里上不正確。 換句話說，可能沒有必要將工作分為兩個階段（提取鏈接，然后分析文章），並且可能足夠快，只需一個工作單元即可包含兩個步驟。 我總是先嘗試使用更簡單的解決方案，然后如果需要更高的性能，則可以對其進行重構。 但是，如果這不滿足您對處理時間的要求，並且您想要更多的並行化，那么您仍然可以使用我概述的基本方法，但是有2個隊列，每個階段1個。 它甚至可能是同一工作進程，只是在不同的線程中等待兩個隊列，或者可能是完全獨立的進程。 其他設計約束可能會規定（例如，成本，總吞吐量）。