我正在使用服務總線隊列消息和輔助角色測試Azure上的自動縮放功能。隊列消息自動縮放
自動縮放的簡單場景是，對於每個實例中隊列中的超過10條消息，會發生自動縮放。然而，在測試過程中，我注意到即使我在隊列中推送了超過200條消息，即使在半小時之後，也是如此。1）只有一個實例被放大（從1開始，它變成了2）
2 ）這兩個實例都不是穩定的，即處於「運行」狀態。
這讓我感到困惑，是否可能出現不一致的原因？
1）我的訂閱是公司msdn訂閱，每月限額（這當然只適用於開發工作）。
2）我在幾秒鐘的時間內推送了200封郵件..顯然這可能是一個製作場景..但它是否妨礙了...
有什麼可能性？
Azure的自動縮放工作在60分鐘的聚合期間。一旦它啓動，它通常每次增加1個實例，並且需要10-12分鐘才能將實例添加到雲服務（這正是我假設的你的實例）。
如果你想一噸多的控制和選擇，當涉及到自動縮放，認爲專注於這個第三方產品，如CloudMonix這是AzureWatch的繼任者 - 這兩個我與
相關關於爲什麼你的實例在縮放期間都未準備好的特別注意事項： 這是因爲你從1個實例開始並前往2個。如果你從2個實例開始並轉到3+，那麼你的前兩個實例會沒事的。這是Azure的負載均衡器的一個特殊問題，我忘記了微軟給出的解釋，但它在論壇的某個地方，如果你看看
服務總線將在幾秒鐘內吃掉200條消息。嘗試發送更多像20,000。
下面是一個示例，它使用F＃，但是具有相同的概念。 http://indiedevspot.com/2015/03/14/mocking-iot-telemetry-data-with-azure/
如果你可以讓我知道背後的解釋，那會很棒。這是SLA問題嗎？因爲如果您沒有2個或更多實例，SLA不在圖片中？ –
這不是一個特別的SLA問題（雖然我確信SLA也依賴於這個事實），但我認爲這是因爲它們的負載均衡器通過一種不同的模式，並且需要將您的第一個實例從本身中抽出來以便使用2+實例重建負載均衡集 – Igorek
我瞭解新實例的運行取決於一小時內的平均使用情況......但基於隊列的情況如何......例如，在優化隊列讀取之後，現在速度非常快。但仍然。當我將每個實例的標準設置爲10條消息時......並且當隊列中有超過100個未決的時候......它仍然沒有開始啓動新的實例..在一段時間後，它會做任何事情？ –