服務探索復原能力 （預覽）
使用 Azure Container Apps 復原功能，您可以使用簡單的復原原則，主動防止、偵測及復原服務要求失敗。 在本文中，您將瞭解如何使用 Azure Container Apps 服務探索起始要求時設定 Azure Container Apps 復原原則。
注意
目前，復原原則無法套用至使用 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, httpStatusCodes, errors |
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 容器應用程式的連線共用會維護容器應用程式已建立且可重複使用連線的集區。 此連線集區可減少為每個要求建立和卸載個別連線的額外負荷。
連線集區可讓您指定服務允許的要求或連線數目上限。 這些限制可控制每個服務的並行連線總數。 達到此限制時，除非釋出或關閉現有的連線，否則不會建立與該服務的新連線。 此管理連線的程式可防止要求不堪重負的資源，並維護有效率的連接管理。
HTTP連線ionPool
properties: {
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
| 中繼資料 | 必要 | 描述 | 範例 |
|---|---|---|---|
http1MaxPendingRequests |
Yes | 用於 http1 要求。 容器應用程式的開啟連線數目上限。 |
1024 |
http2MaxRequests |
Yes | 用於 http2 要求。 容器應用程式的並行要求數目上限。 |
1024 |
tcp連線ionPool
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 小時等）。
例如，如果您在測試應用程式 範圍中設定 復原要求重試 計量， 並在 30 分鐘的時間範圍內搜尋平均 匯總，結果如下所示：
相關內容
請參閱 Azure Container Apps 中 Dapr 元件的復原運作 方式。