服務探索復原能力
透過 Azure 容器應用程式復原能力，您可以使用簡單的復原原則，主動預防、偵測服務要求失敗並從中復原。 在本文中，您會了解如何在使用 Azure 容器應用程式服務探索起始要求時設定 Azure 容器應用程式復原原則。
注意
目前，復原原則無法套用至使用 Dapr 服務叫用 API 提出的要求。
針對容器應用程式的每個要求，原則皆會生效。 您可以使用下列設定，針對接受要求的容器應用程式量身打造原則：
- 重試次數
- 重試及逾時持續時間
- 重試比對
- 斷路器連續錯誤和其他錯誤
下列螢幕擷取畫面顯示應用程式如何使用重試原則嘗試從失敗的要求中復原。
支援的復原原則
設定復原原則
無論您使用 Bicep、CLI 或 Azure 入口網站設定復原原則，每個容器應用程式只能套用一個原則。
當您將原則套用至容器應用程式時，會將規則套用至對該容器應用程式發出的所有要求，而非從該容器應用程式提出的要求。 例如，針對名為 App B 的容器應用程式套用重試原則， 則向應用程式 B 發出的所有輸入要求都會在失敗時自動重試。 不過，由應用程式 B 提出的輸出要求不保證會在失敗時重試。
下列復原範例示範所有可用設定。
resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-11-02-preview' = {
name: 'my-app-resiliency-policies'
parent: '${appName}'
properties: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
connectionTimeoutInSeconds: 5
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
httpStatusCodes: [
502
503
]
errors: [
'retriable-status-codes'
'5xx'
'reset'
'connect-failure'
'retriable-4xx'
]
}
}
tcpRetryPolicy: {
maxConnectAttempts: 3
}
circuitBreakerPolicy: {
consecutiveErrors: 5
intervalInSeconds: 10
maxEjectionPercent: 50
}
tcpConnectionPool: {
maxConnections: 100
}
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
}
原則規格
逾時
逾時可用於提前終止長時間執行的作業。 逾時原則包括下列屬性。
properties: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
connectionTimeoutInSeconds: 5
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
responseTimeoutInSeconds |
Yes | 等候容器應用程式回應逾時。 | 15 |
connectionTimeoutInSeconds |
Yes | 與容器應用程式建立連線逾時。 | 5 |
重試
定義失敗作業的 tcpRetryPolicy 或 httpRetryPolicy 策略。 重試原則包含下列設定。
httpRetryPolicy
properties: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
httpStatusCodes: [
502
503
]
errors: [
'retriable-headers'
'retriable-status-codes'
]
}
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
maxRetries |
Yes | 針對失敗的 http-request 執行重試次數上限。 | 5 |
retryBackOff |
Yes | 監視要求，並在符合逾時和重試準則時關閉受影響服務的所有流量。 | N/A |
retryBackOff.initialDelayInMilliseconds |
Yes | 第一次錯誤與第一次重試之間的延遲。 | 1000 |
retryBackOff.maxIntervalInMilliseconds |
Yes | 重試之間的延遲上限。 | 10000 |
matches |
Yes | 設定比對值以限制應用程式何時應嘗試重試。 | headers、 、 httpStatusCodeserrors |
matches.headers |
Y* | 當錯誤回應包含特定標頭時重試。 *只有在您指定 retriable-headers 錯誤屬性時，標頭才是必要屬性。 深入了解可用標頭比對。 |
X-Content-Type |
matches.httpStatusCodes |
Y* | 當回應傳回特定狀態碼時重試。 *只有在您指定 retriable-status-codes 錯誤屬性時，狀態碼才是必要屬性。 |
502, 503 |
matches.errors |
Yes | 只有在應用程式傳回特定錯誤時才會重試。 深入了解可用錯誤。 | connect-failure, reset |
標頭比對
如果您指定了 retriable-headers 錯誤，則可在回應包含特定標頭時，使用下列標頭比對屬性重試。
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
}
| 中繼資料 | 描述 |
|---|---|
prefixMatch |
重試是根據標頭值的前置詞而執行。 |
exactMatch |
重試是根據標頭值的完全相符而執行。 |
suffixMatch |
重試是根據標頭值的尾碼而執行。 |
regexMatch |
重試是根據規則運算式規則而執行，其中標頭值必須符合 RegEx 模式。 |
錯誤
您可以對下列任何錯誤執行重試：
matches: {
errors: [
'retriable-headers'
'retriable-status-codes'
'5xx'
'reset'
'connect-failure'
'retriable-4xx'
]
}
| 中繼資料 | 描述 |
|---|---|
retriable-headers |
觸發重試的 HTTP 回應標頭。 如果任何標頭比對符合回應標頭，則會執行重試。 如果您想重試任何比對標頭，則為必要項目。 |
retriable-status-codes |
應觸發重試的 HTTP 狀態碼。 如果您想重試任何比對狀態碼，則為必要項目。 |
5xx |
如果伺服器回應任何 5xx 回應碼，則會重試。 |
reset |
如果伺服器未回應，則會重試。 |
connect-failure |
如果與容器應用程式連線錯誤而導致要求失敗，則會重試。 |
retriable-4xx |
如果容器應用程式回應 400 系列回應碼 (例如 409)，則會重試。 |
tcpRetryPolicy
properties: {
tcpRetryPolicy: {
maxConnectAttempts: 3
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
maxConnectAttempts |
Yes | 設定連線嘗試次數上限 (maxConnectionAttempts) 以重試失敗連線。 |
3 |
斷路器
斷路器原則會根據連續錯誤數目等觸發程序，指定容器應用程式複本是否暫時從負載平衡集區中移除。
properties: {
circuitBreakerPolicy: {
consecutiveErrors: 5
intervalInSeconds: 10
maxEjectionPercent: 50
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
consecutiveErrors |
Yes | 容器應用程式複本暫時從負載平衡中移除之前發生的連續錯誤數目。 | 5 |
intervalInSeconds |
Yes | 指定判斷複本是否從負載平衡集區中移除或還原的時間長度。 | 10 |
maxEjectionPercent |
Yes | 從負載平衡中退出的容器應用程式複本失敗百分比上限。 無論值為何，至少會移除一部主機。 | 50 |
連線集區
Azure 容器應用程式的連線共用會維護容器應用程式已建立且可重複使用的連線集區。 此連線集區可減少為每個要求建立及卸除個別連線的額外負荷。
連線集區可讓您指定服務允許的要求或連線數目上限。 這些限制可控制每個服務的並行連線總數。 達到此限制時，除非釋出或關閉現有連線，否則不會建立與該服務的新連線。 透過此連線管理流程，可防止資源承受的要求超出負荷，並維護有效率的連線管理。
httpConnectionPool
properties: {
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
http1MaxPendingRequests |
Yes | 用於 http1 要求。 容器應用程式的開啟連線數目上限。 |
1024 |
http2MaxRequests |
Yes | 用於 http2 要求。 容器應用程式的並行要求數目上限。 |
1024 |
tcpConnectionPool
properties: {
tcpConnectionPool: {
maxConnections: 100
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
maxConnections |
Yes | 容器應用程式的並行連線數目上限。 | 100 |
復原可檢視性
您可以透過容器應用程式的計量和系統記錄檔，執行復原可檢視性。
復原記錄
從容器應用程式的 [監視] 區段中選取 [記錄]。
在 [記錄] 窗格中，撰寫並執行查詢，以透過容器應用程式系統記錄檔尋找復原。 例如，執行類似下列的查詢來搜尋復原事件，並顯示其：
- 時間戳記
- 環境名稱
- 容器應用程式名稱
- 復原類型和原因
- 記錄訊息
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s
按一下 [執行] 以執行查詢並檢視結果。
復原計量
從容器應用程式的 [監視] 功能表中選取 [計量]。 在 [計量] 窗格中，選取下列篩選條件：
- 容器應用程式名稱的範圍。
- 標準計量計量命名空間。
- 下拉式功能表中的復原計量。
- 您希望結果中的資料彙總方式 (依平均值、最大值等)。
- 持續時間 (過去 30 分鐘、過去 24 小時等)。
例如，如果您在 test-app 範圍中將復原要求重試計量設定為平均彙總，並在 30 分鐘的時間範圍內搜尋，則結果如下所示：
相關內容
了解 Azure 容器應用程式中 Dapr 元件的復原運作方式。