我試圖將應用程序移植到Azure平臺。我想多次運行現有的應用程序。我最初的想法如下：我有一個master_process。我有很多slave_processes。每個進程都是Azure中的輔助角色。每個slave_process將獨立運行應用程序的一個實例。我希望master_process啓動許多slave_processes併爲它們提供輸入參數。最後，master_process將收集結果。目前，我有一個工作設置從C＃封裝器調用整個應用程序。所以，爲了獲得成功，我需要兩件事：首先，我必須找到一種方法，在一名高級工人內部開始奴隸工（就像線程一樣）。其次，我需要找到一種方法來存儲從屬工作者的結果，並從主工作者處獲取這些結果文件。誰能幫我？Microsoft Azure主從工作者角色
我想我會嘗試解決問題的方式不同。部署一個全新的實例可能需要15到30分鐘。將一個額外的實例添加到已經運行的worker角色會更快一些，但不是太多。我會假定你想要比這更快的結果，而且這個過程是經常運行的。
我將只有一個工作者角色類型來運行您現有的邏輯以及您確定需要的那個工作者角色的許多實例。無論你的客戶會決定它需要將工作分解成若干部分，爲了爭論起見，假設10。它會給每件作品一個ID（例如一個GUID），然後將包含參數和ID的10條消息放入一個隊列中。你的工作者角色實例將消息帶出隊列，完成他們的工作，並將他們的結果寫入存儲的某個地方（SQL Azure，Azure表存儲，或者甚至可能是blob存儲，具體取決於結果）。客戶端輪詢該存儲器以等待所有結果完成，然後繼續。
如果這是一個不經常運行的進程，那麼您可以使用我描述過的相同方法，而不是一直部署工作者角色，但此外在獲取客戶端代碼時可以獲得deploy the worker roles當它通過管理API完成時啓動然後delete them。有關於如何使用此的samples on MSDN。
我有類似的情況可能對您有用：
我有一個大的順序分批處理我Azure上運行需要前處理和後處理。我使用的技術是使用單個多功能輔助角色的實例，但是使用「仲裁」來提名首節點，然後控制工作流程。
他們這樣做的方式是使用藍色頁面 blob作爲法定人數（基本上是一種全局互斥/鎖），因爲一旦節點抓住它來寫入它就被鎖定了。對於彈性，如果頭節點出現問題，所有節點偶爾會嘗試重新捕獲法定人數。