Resistencia de los componentes de Dapr (versión preliminar)
Las directivas de resistencia ayudan a evitar, detectar y recuperarse de forma proactiva de los errores de las aplicaciones de contenedor. En este artículo, aprenderá a aplicar directivas de resistencia para las aplicaciones que usan Dapr a fin de integrarse con diferentes servicios en la nube, como almacenes de estado, agentes de mensajes pub/sub, almacenes de secretos y muchos más.
Puede configurar directivas de resistencia como reintentos, tiempos de espera y disyuntores para las siguientes instrucciones de operación saliente y entrante a través de un componente Dapr:
- Operaciones de salida: llama desde el sidecar de Dapr a un componente, como:
- Conservación o recuperación del estado
- Publicación de un mensaje
- Invocación de un enlace de salida
- Operaciones de entrada: llama desde el sidecar de Dapr a la aplicación de contenedor, como:
- Suscripciones al entregar un mensaje
- Enlaces de entrada que entregan un evento
En la captura de pantalla siguiente se muestra cómo usa una aplicación una directiva de reintentos para intentar recuperarse de solicitudes con error.
Directivas de resistencia admitidas
Configuración de directivas de resistencia
Puede elegir si quiere crear directivas de resistencia mediante Bicep, la CLI o Azure Portal.
En el ejemplo de resistencia siguiente se muestran todas las configuraciones disponibles.
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
}
}
}
}
Importante
Una vez que haya aplicado todas las directivas de resistencia, debe reiniciar las aplicaciones Dapr.
Especificaciones de directiva
Tiempos de espera
Los tiempos de espera se usan para finalizar con antelación las operaciones de larga duración. La directiva de tiempo de espera incluye las siguientes propiedades.
properties: {
outbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
inbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
}
| Metadatos | Obligatorio | Descripción | Ejemplo |
|---|---|---|---|
responseTimeoutInSeconds |
Sí | Tiempo de espera para obtener una respuesta del componente Dapr. | 15 |
Retries
Defina una estrategia httpRetryPolicy para las operaciones con errores. La directiva de reintentos incluye las siguientes configuraciones.
properties: {
outbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
inbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
}
| Metadatos | Obligatorio | Descripción | Ejemplo |
|---|---|---|---|
maxRetries |
Sí | Número máximo de reintentos que se ejecutarán para una solicitud HTTP con errores. | 5 |
retryBackOff |
Sí | Supervise las solicitudes y apague todo el tráfico al servicio afectado cuando se cumplen los criterios de tiempo de espera y reintento. | N/D |
retryBackOff.initialDelayInMilliseconds |
Sí | Retraso entre el primer error y el primer reintento. | 1000 |
retryBackOff.maxIntervalInMilliseconds |
Sí | Retraso máximo entre los reintentos. | 10000 |
Interruptores
Defina un circuitBreakerPolicy para supervisar las solicitudes que provocan tasas de error elevadas y apague todo el tráfico al servicio afectado cuando se cumple un determinado criterio.
properties: {
outbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
},
inbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
| Metadatos | Obligatorio | Descripción | Ejemplo |
|---|---|---|---|
intervalInSeconds |
No | Período cíclico de tiempo (en segundos) utilizado por el disyuntor para borrar sus recuentos internos. Si no se proporciona, el intervalo se establece en el mismo valor que se proporciona para timeoutInSeconds. |
15 |
consecutiveErrors |
Sí | Número de errores de solicitud que se pueden producir antes de que se abra el circuito. | 10 |
timeoutInSeconds |
Sí | Período de tiempo (en segundos) del estado abierto, directamente después del error. | 5 |
Proceso del disyuntor
Al especificar consecutiveErrors (la condición de recorrido de circuito como consecutiveFailures > $(consecutiveErrors)-1) se establece el número de errores que se pueden producir antes de que se realicen los viajes del circuito y se abra a mitad de camino.
El circuito espera la mitad de la apertura del tiempo timeoutInSeconds, durante el cual el número de solicitudes consecutiveErrors debe realizarse de forma consecutiva.
- Si las solicitudes se realizan correctamente, se cierra el circuito.
- Si se produce un error en las solicitudes, el circuito permanece en estado medio abierto.
Si no estableció ningún valor de intervalInSeconds, el circuito se restablece a un estado cerrado después del período de tiempo establecido para timeoutInSeconds, independientemente de que la solicitud se haya realizado correctamente o no. Si establece intervalInSeconds en 0, el circuito nunca se restablece automáticamente, solo se mueve de medio abierto al estado cerrado completando correctamente las solicitudes de una fila consecutiveErrors.
Si estableció un valor intervalInSeconds, que determina la cantidad de tiempo antes de que el circuito se restablezca al estado cerrado, independientemente de si las solicitudes enviadas en estado medio abierto se realizaron correctamente o no.
Registros de resistencia
En la sección Supervisión de la aplicación de contenedor, seleccione Registros.
En el panel Registros, escriba y ejecute una consulta para encontrar resistencia a través de los registros del sistema de aplicaciones de contenedor. Por ejemplo, para averiguar si se ha cargado una directiva de resistencia:
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
Haga clic en Ejecutar para ejecutar la consulta y ver el resultado con el mensaje de registro que indica que la directiva se está cargando.
O bien, puede encontrar la directiva de resistencia real habilitando los registros de depuración en la aplicación de contenedor y consultando para ver si se carga un recurso de resistencia.
Una vez habilitados los registros de depuración, use una consulta similar a la siguiente:
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
Haga clic en Ejecutar para ejecutar la consulta y ver el mensaje de registro resultante con la configuración de directiva.
Contenido relacionado
Consulte cómo funciona la resistencia para la Comunicación entre servicios con la detección de servicios integrada de Azure Container Apps