Dapr 元件復原能力
復原原則會主動防止、偵測容器應用程式失敗並從中復原。 在本文中，您將了解如何將復原原則套用至使用 Dapr 與不同雲端服務的應用程式，例如狀態存放區、pub/sub 訊息代理程式、秘密存放區等等。
您可以透過 Dapr 元件，針對下列輸出和輸入作業指示設定復原原則，例如重試、逾時和斷路器：
- 輸出作業：從 Dapr Sidecar 呼叫元件，例如：
- 保存或擷取狀態
- 發佈訊息
- 叫用輸出繫結
- 輸入作業：從 Dapr Sidecar 呼叫容器應用程式，例如：
- 傳遞訊息時的訂用帳戶
- 傳遞事件的輸入繫結
下列螢幕擷取畫面顯示應用程式如何使用重試原則嘗試從失敗的要求中復原。
支援的復原原則
設定復原原則
您可以選擇使用 Bicep、CLI 或 Azure 入口網站來建立復原原則。
下列復原範例示範所有可用設定。
resource myPolicyDoc 'Microsoft.App/managedEnvironments/daprComponents/resiliencyPolicies@2023-11-02-preview' = {
name: 'my-component-resiliency-policies'
parent: '${componentName}'
properties: {
outboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
inboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
}
重要
套用所有復原原則之後，您必須重新啟動 Dapr 應用程式。
原則規格
逾時
逾時可用於提前終止長時間執行的作業。 逾時原則包括下列屬性。
properties: {
outbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
inbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
responseTimeoutInSeconds |
Yes | 等候 Dapr 元件回應逾時。 | 15 |
重試
定義失敗作業的 httpRetryPolicy 策略。 重試原則包含下列設定。
properties: {
outbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
inbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
maxRetries |
Yes | 針對失敗的 http-request 執行重試次數上限。 | 5 |
retryBackOff |
Yes | 監視要求，並在符合逾時和重試準則時關閉受影響服務的所有流量。 | N/A |
retryBackOff.initialDelayInMilliseconds |
Yes | 第一次錯誤與第一次重試之間的延遲。 | 1000 |
retryBackOff.maxIntervalInMilliseconds |
Yes | 重試之間的延遲上限。 | 10000 |
斷路器
定義 circuitBreakerPolicy 監視導致失敗率升高的要求，並在符合特定準則時關閉受影響服務的所有流量。
properties: {
outbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
},
inbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
intervalInSeconds |
No | 斷路器用於清除其內部計數的週期期間 (以秒為單位)。 如果未提供，間隔會設定為與提供給 timeoutInSeconds 相同的值。 |
15 |
consecutiveErrors |
Yes | 線路跳脫和斷開之前允許發生的要求錯誤數目。 | 10 |
timeoutInSeconds |
Yes | 發生失敗後立即處於開啟狀態的時間週期 (以秒為單位)。 | 5 |
斷路器流程
指定 consecutiveErrors (線路跳脫條件為 consecutiveFailures > $(consecutiveErrors)-1) 設定線路跳脫和中途斷開之前允許發生的錯誤數目。
線路以半斷開狀態等待 timeoutInSeconds 時間量，在此期間要求的 consecutiveErrors 數目必須連續成功。
- 如果要求成功，則線路關閉。
- 如果要求失敗，則線路仍處於半斷開狀態。
如果您未設定任何 intervalInSeconds 值，則不論連續要求成功或失敗，線路都會在您為 timeoutInSeconds 設定的時間量之後，重設為關閉狀態。 如果您將 intervalInSeconds 設定為 0，則線路永遠不會自動重設，只會藉由順利完成資料列中的 consecutiveErrors 要求，從半斷開狀態移至關閉狀態。
如果您已設定 intervalInSeconds 值，則該值決定線路重設為關閉狀態之前的時間量，與半斷開狀態下傳送的要求是否成功無關。
復原記錄
從容器應用程式的 [監視] 區段中選取 [記錄]。
在 [記錄] 窗格中，撰寫並執行查詢，以透過容器應用程式系統記錄檔尋找復原。 例如，尋找是否已載入復原原則：
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Loading Resiliency configuration:"
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
按一下 [執行] 來執行查詢，並使用指出正在載入原則的記錄訊息來檢視結果。
或者，您可以在元件上啟用偵錯，並使用類似下列範例的查詢來尋找實際的復原原則：
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Resiliency configuration ("
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
按一下 [執行] 以執行查詢，並使用原則設定檢視產生的記錄訊息。
相關內容
了解使用服務探索內建的 Azure 容器應用程式進行服務對服務通訊的復原運作方式