我們需要Azure中的API來存儲通過HTTP發送給它（代理）的消息，以防我的系統（雲服務）不可用或數據庫繁忙。改變準確的消息將被髮送並不容易。什麼方法可以在Azure上創建這樣的代理？如何在Azure上爲匿名HTTP API消息創建代理？
服務總線隊列看起來很有趣，但據我所知，它需要Shared Access Signatures。
另一個WebRole應該是一個解決方案，但它需要時間來實現。
帶一些工具（MSMQ？）的虛擬機似乎是一種方式，但它需要維護。
您認爲如何？
您的場景是應用隊列中心工作模式的主要候選人。
如果任你的工人（S）或數據庫變得不可用，消息仍然處於持久存儲和以後消耗。
任務隊列可以採取Azure存儲隊列或服務總線隊列的形式。在每一個偉大的設計中，做這項工作的最不復雜的部件都是勝利的。在這種情況下，這將是Azure存儲隊列，耐用，可靠，移動部件非常少。除非你絕對需要精確的FIFO排序，在這種情況下，你需要使用服務總線。
從https://msdn.microsoft.com/en-us/library/dn568101.aspx：
此解決方案具有以下優點：
它使得固有負載調平系統，它可以在由應用程序實例發送請求量處理寬的變化。隊列充當應用程序實例與使用者服務實例之間的緩衝區，這有助於最大限度地降低應用程序和服務實例的可用性和響應性的影響（如基於隊列的負載均衡模式所述）。處理需要執行一些長時間運行的處理的消息不會阻止消費者服務的其他實例同時處理其他消息。
它提高了可靠性。如果生產者直接與消費者溝通而不是使用這種模式，但不監督消費者，消費者失敗的可能性很大，即消息可能丟失或無法處理。在這種模式下，消息不會發送到特定的服務實例，失敗的服務實例不會阻止生產者，並且消息可以由任何工作服務實例處理。
它不需要消費者之間或生產者與消費者實例之間的複雜協調。消息隊列確保每條消息至少被傳遞一次。
它是可擴展的。隨着消息量的波動，系統可以動態地增加或減少消費者服務的實例的數量。
如果消息隊列提供事務性讀操作，它可以提高彈性。如果消費者服務實例將消息作爲事務操作的一部分進行讀取和處理，並且此消費者服務實例隨後失敗，則此模式可確保將消息返回隊列以供拾取並由另一個消費者服務。
給您不能更改客戶端，我想代理呼叫。使用Azure中的API管理服務重新創建API，並將網址更改爲指向API管理服務代理。
代理就可以輕鬆地委派到function application像亞拉文在評論你的問題中提到使用API Management Service policies.
感謝您指向API管理服務和功能應用程序。到目前爲止，我們沒有太多的負擔。看起來API管理服務會讓事情複雜化並增加成本。所以，當webrole充當這些調用的代理時，隊列中心工作模式看起來就足夠了。 – Artyom
不喜歡使用WebRole。這是ASM /經典Azure，所以你會寫遺產。 Azure正在轉向ARM /資源管理器。雲服務成爲AppService。另外，如果您可以運行Developer SKU，則可以以低於App Service的成本運行它。用API管理服務替換Web角色，並使用相同的隊列中心工作模式。爲API管理編寫策略比爲Web角色編寫代碼更簡單。 （你只需要花幾個小時來學習它）。無論您選擇哪種方式，我都希望它順利。 –
你可以存儲在隊列中的消息，甚至Blob存儲，並有一個函數應用該消息被觸發作爲一個事件，然後處理該消息，並將其發送到任何你想要的地方.. – Aravind
@Aravind如果我不能修改我的客戶，我將如何在隊列（服務總線，對吧？謝謝！ – Artyom
它可以是服務總線或存儲隊列。您必須至少修改您的客戶端應用程序以將消息發送到特定的新端點。 – Aravind