Azure功能 - 限制服務總線觸發

Question

我目前正在評估使用服務總線和天藍色功能來觸發某些需要通過下游api調用完成的工作。除了我無法很好地處理下游系統過載和/或將報頭返回到節流狀態（即每分鐘最大呼叫數/等）時，會發生什麼情況。我們似乎沒有對隊列觸發器強制調節的任何動態控制。

我知道我們可以手動設置max concurrency，但這並不一定能解決問題，因爲我們無法控制下游系統，需要考慮隨時可能處於脫機狀態或緩慢狀態。

此外，我們可以創建消息，使它們按照一定的速率流入，但下游系統仍然可以飽和或返回速率限制。

選項1：

假設消費計劃，從解決方案的角度來看，這是一個方式，我能想到的：

• 隊列1 - 全速或最高速度。如果我們開始獲得速率限制，請設置緩存值。如果設置了緩存值，則不處理該消息，將其克隆並放入隊列2
• Queue2 - 每個最大併發/預取計數下限。與上面相同的過程，但推入隊列3。
• 隊列3 - 最大每最大併發/預取計數。我們只是慢慢地處理它們。

基本上，當下遊系統飽和時，隊列1成爲隊列2和隊列3的控制器。

選項2：

我們可以克隆的消息，並在未來進行重新排隊，並繼續這樣做，直到他們的所有進程。保持一個隊列，只需要等待，直到我們得到處理。

方案3：

假設我們有我們的是專用的，而不是消耗自己的應用程序的計劃，我想我們可以Thread.Sleep，如果他們越來越接近成爲速率限制或向下，並不斷重試功能。這可能可能是最大併發性，實例和速率限制的計算。我不會在消費計劃中考慮這一點，因爲睡眠可能會大幅增加成本。

我不知道如果我失去了一些東西以最好的方式簡單處理下游飽和或節流隊列觸發（可能是服務總線或存儲隊列）

編輯： 我想補充一點，我將100萬條消息抽入服務總線隊列，該隊列在發送時計劃。我觀察Azure功能（消費計劃）規模達到每秒1500次左右，以提供良好的指標。我不確定這些專用的程序如何執行。

它看起來可以即時修改主機文件，並且設置立即生效。雖然這是針對所有功能的，但在特定情況下可能會起作用（更新設置並根據速率限制每隔一分鐘重新檢查一次）。

This看起來它可能是一個正確的方向，當它被功能團隊實現時邁出的一步，但即便如此，我們仍然需要一種方法來管理下游錯誤。

Answer 1

不幸的是，您需要的背壓功能目前無法使用服務總線觸發器（以及更一般的Azure功能），因此您需要自己處理。

您所描述的方法可行，您只需要在不同的功能應用程序中處理它，因爲服務總線設置適用於整個應用程序，而不僅僅是一個功能。

在您的場景中可能不是一個巨大的幫助，但對於處理隊列2或3的應用程序，您還可以嘗試使用預覽標誌，以限制應用程序的擴展實例數：WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT。請注意，這是在預覽中，並沒有保證。

我鼓勵你在記錄你的場景的functions repo上打開一個問題。這類問題絕對是我們想要解決的問題，我們獲得的反饋越多越好。

Answer 2

就這樣，除了正常的api端點之外，您是否可以要求下游的人提供隊列端點？ 然後你可以淹沒他們的隊列，他們可以在閒暇時處理它。