La protección de tráfico integra las capacidades de protección de Microservices Engine (MSE) en Serverless App Engine (SAE) y controla el tráfico que llega a una aplicación a nivel de API. Utilice reglas de limitación, aislamiento de concurrencia, corte de circuito y protección de parámetros hotspot para mantener la disponibilidad de una aplicación ante picos de tráfico o inestabilidad en dependencias posteriores. La protección de tráfico analiza la distribución del tráfico con granularidad de segundos.
Requisitos previos
Cuenta con deployed an application.
Cuenta con activated MSE Microservices Governance Enterprise Edition.
El uso de MSE genera cargos por separado. Para obtener más información sobre la facturación de MSE, consulte Billing of MSE Microservices Governance.
Límites
Los siguientes límites aplican a la protección de tráfico:
Aplicaciones compatibles: La protección de tráfico solo aplica a aplicaciones de microservicios creadas a partir del 8 de noviembre de 2023.
Rendimiento de cola: Cuando las solicitudes limitadas se ponen en cola, no establezca el QPS en un valor superior a 1,000, lo cual corresponde a un intervalo de solicitud de 1 milisegundo.
Versiones de Apache Dubbo: Las versiones 2.7.0 a 2.7.3 de Apache Dubbo no admiten comportamientos personalizados. En estas versiones, una solicitud limitada devuelve
java.lang.RuntimeException, y el contenido incluyeSentinelBlockedExceptionjunto con la información de limitación.Tipos de respuesta personalizada: Una respuesta personalizada no admite tipos de objeto que contengan genéricos con tipos indefinidos, como
Map<K, V>yList<T>.
Elegir un tipo de regla de protección
La protección de tráfico ofrece cinco tipos de reglas, cada una con su propia pestaña en la consola de SAE. La siguiente tabla describe qué controla cada tipo de regla y dónde se configura.
|
Tipo de regla |
Qué controla |
Dimensión estadística |
Pestaña de la consola |
|
Limitación a nivel de interfaz |
Las consultas por segundo (QPS) de una aplicación o servicio. El tráfico se bloquea en cuanto el QPS alcanza el umbral. |
QPS |
Interface-level Throttling |
|
Aislamiento de concurrencia |
El número de hilos concurrentes de una API o sus dependencias. |
Hilos concurrentes |
Concurrency Isolation |
|
Corte de circuito |
Llamadas a una API inestable o dependencia posterior, basadas en el tiempo de respuesta o la tasa de errores. |
Proporción de llamadas lentas o proporción anómala |
Circuit Breaking Rules |
|
Protección de parámetros hotspot (RPC) |
Llamadas a recursos que contienen parámetros invocados frecuentemente. Un parámetro se identifica por su posición de índice en el punto de instrumentación. |
Número de solicitudes o número concurrente, por parámetro hotspot |
Hotspot Parameter Protection (RPC) |
|
Protección de parámetros hotspot (solicitud HTTP) |
Solicitudes de acceso a una aplicación que proporciona servicios web, basadas en propiedades de la solicitud como dirección IP del cliente, Host, Header y parámetro URL. |
Recuento de solicitudes, por parámetro hotspot |
Hotspot Parameter Protection (HTTP Request) |
Las reglas de limitación a nivel de interfaz y las reglas de protección de parámetros hotspot también permiten elegir cómo manejar el tráfico limitado. Fast failure bloquea las solicitudes excedentes de inmediato. Waiting in line pone en cola las solicitudes excedentes para que pasen a una tasa constante, y se utiliza típicamente para el desplazamiento de carga pico. Si pone solicitudes en cola, respete el límite de rendimiento de cola descrito en Limits.
Ir a la pestaña de protección de tráfico
En la lista de aplicaciones de SAE, seleccione la región y el espacio de nombres en la parte superior de la página, y luego haga clic en el Application ID de la aplicación para ir a la página de detalles de la aplicación.
En el panel de navegación izquierdo, elija Microservices Governance > Traffic Governance, y luego haga clic en la pestaña Traffic Protection.
Configurar reglas de protección
Para los tipos de reglas cuyo flujo de creación incluye el asistente Configure Protection Behavior, el último paso consiste en seleccionar un Associated Behavior, que define la respuesta que recibe una solicitud tras activar la regla. Seleccione el comportamiento predeterminado si no necesita una respuesta personalizada para las solicitudes rechazadas. Para conocer los parámetros de comportamiento y los pasos de creación, consulte Manage behaviors.
Para las reglas de limitación a nivel de interfaz, las reglas de aislamiento de concurrencia y las reglas de protección de parámetros hotspot, Whether to open está desactivado de forma predeterminada. Estas reglas solo surten efecto después de activar este interruptor.
Configurar reglas de limitación a nivel de interfaz
Una regla de limitación a nivel de interfaz monitorea las consultas por segundo (QPS) de una aplicación o servicio. Cuando el QPS alcanza el umbral especificado, la regla bloquea el tráfico inmediatamente. Esto evita que los picos momentáneos de tráfico saturen la aplicación y garantiza la alta disponibilidad (HA).
Haga clic en la pestaña Interface-level Throttling y luego en Create Throttling Rule.
-
En el cuadro de diálogo Create Throttling Rule, complete los siguientes asistentes:
En el asistente Select Protection Scenario, seleccione API Type, Traffic Type y API Name, y luego haga clic en Next.
En el asistente Configure Protection Rule, configure los parámetros descritos en la siguiente tabla y luego haga clic en Next.
En el asistente Configure Protection Behavior, seleccione un Associated Behavior y luego haga clic en Create.
La siguiente tabla describe los parámetros del asistente Configure Protection Rule.
|
Elemento de configuración |
Descripción |
|
Whether to open |
Si activa este interruptor, la regla entra en vigor inmediatamente después de su creación. El interruptor está desactivado de forma predeterminada. |
|
Per-instance QPS threshold |
El umbral de QPS del objeto en la dimensión estadística de la API limitada. |
|
Flow control effect |
Seleccione cómo se maneja el tráfico limitado. Fast failure: Al alcanzar el umbral, las solicitudes se bloquean inmediatamente. El contenido de la respuesta depende de la configuración del módulo adaptador en los ajustes del sistema de la aplicación. Waiting in line: Las solicitudes pasan a una tasa constante y las excedentes se ponen en cola. Este método se usa típicamente para el desplazamiento de carga pico. Debe establecer un periodo de tiempo de espera. Una solicitud falla rápidamente cuando alcanza dicho periodo. |
La regla aparece en la pestaña Interface-level Throttling, donde puede editarla o eliminarla.
Ejemplo: Desplazar cargas pico para que el tráfico pase a una tasa constante
El tráfico de solicitudes tiene picos y valles. La limitación retrasa el tráfico pico al poner en cola las solicitudes y procesarlas posteriormente. Este enfoque atiende tantas solicitudes como sea posible y mantiene la experiencia del usuario. Configure la regla de limitación con los siguientes ajustes:
Establezca Stand-alone QPS threshold en 5 para el modo de tasa constante.
Establezca Flow control effect en Waiting in line.
-
Establezca Timeout en 5 segundos.
El sistema procesa una solicitud cada 200 milisegundos y pone en cola las tareas excedentes. Dado que el tiempo de espera es de 5 segundos, una tarea cuyo tiempo estimado en cola supere los 5 segundos falla rápidamente y devuelve directamente la respuesta de limitación predeterminada, como un mensaje de texto o una página estática.
Configurar reglas de aislamiento de concurrencia
Una regla de aislamiento de concurrencia controla el número de hilos concurrentes de una API o sus dependencias para mantener la estabilidad del sistema.
Haga clic en la pestaña Concurrency Isolation y luego en Create Isolation Rule.
-
En el cuadro de diálogo Create Isolation Rule, complete los siguientes asistentes:
En el asistente Select Protection Scenario, seleccione API Type, Traffic Type y API Name, y luego haga clic en Next.
En el asistente Configure Protection Rule, configure los parámetros descritos en la siguiente tabla y luego haga clic en Next.
En el asistente Configure Protection Behavior, seleccione un Associated Behavior y luego haga clic en Create.
La siguiente tabla describe los parámetros del asistente Configure Protection Rule.
|
Elemento de configuración |
Descripción |
|
Whether to open |
Si activa este interruptor, la regla entra en vigor inmediatamente después de su creación. El interruptor está desactivado de forma predeterminada. |
|
Concurrency threshold |
El umbral para el número de hilos concurrentes del recurso, es decir, la cantidad de hilos en ejecución para dicho recurso. |
La regla aparece en la pestaña Concurrency Isolation, donde puede editarla o eliminarla.
Ejemplo: Garantizar recursos suficientes para su aplicación
Cuando aumenta el tiempo de respuesta de una solicitud, crece el número de hilos concurrentes. Una vez que la concurrencia supera el umbral, el sistema rechaza las solicitudes excedentes hasta que se completan las tareas acumuladas y disminuye el número de hilos concurrentes. Esto aísla fallos y reduce la inestabilidad.
Por ejemplo, una sentencia SQL tarda 20 milisegundos en ejecutarse y se esperan 20 solicitudes por segundo para esta petición. Configure la regla de aislamiento con los siguientes ajustes:
Introduzca el Interface Name.
-
Establezca el Concurrency threshold en 10.
Con esta configuración, si la sentencia SQL encuentra un bloqueo o problemas de rendimiento y se convierte en una consulta lenta, ocupará solo 10 hilos aunque sigan llegando solicitudes. Por lo tanto, las solicitudes continuas, que no pueden finalizar en poco tiempo, no agotarán los hilos activos del proceso. Cuando la sentencia SQL vuelve a la normalidad, la concurrencia disminuye rápidamente. Al caer la concurrencia por debajo del umbral preestablecido, el sistema deja de rechazar solicitudes y la capacidad de procesamiento de la aplicación se recupera velozmente. Este método ajusta la capacidad automáticamente según el tiempo de respuesta y aísla las aplicaciones inestables.
Configurar reglas de corte de circuito
Una regla de corte de circuito monitorea el tiempo de respuesta o la tasa de errores de su aplicación o sus dependencias posteriores. Al alcanzar el umbral especificado, el sistema reduce inmediatamente la prioridad de la dependencia posterior. Durante el periodo de tiempo indicado, el sistema no llama al recurso inestable. Esto evita que la aplicación funcione en un estado inestable y garantiza la alta disponibilidad. Transcurrido dicho periodo, el sistema reanuda las llamadas al recurso.
Haga clic en la pestaña Circuit Breaking Rules y luego en Create Circuit Breaking Rule.
-
En el cuadro de diálogo Create Circuit Breaking Rule, complete los siguientes asistentes:
En el asistente Select Protection Scenario, seleccione API Type y API Name, y luego haga clic en Next.
En el asistente Configure Protection Rule, configure los parámetros descritos en la siguiente tabla y luego haga clic en Create.
La siguiente tabla describe los parámetros del asistente Configure Protection Rule.
|
Elemento de configuración |
Descripción |
|
Statistical window duration |
La duración de la ventana de tiempo para estadísticas. Valores válidos: de 1 segundo a 120 minutos. |
|
Minimum number of requests |
El número mínimo de solicitudes que activa el corte de circuito. Si la cantidad de solicitudes en la ventana estadística actual es menor que este valor, la regla no se activa aunque se cumpla la condición de corte de circuito. |
|
Threshold Type |
Seleccione Slow call ratio (%) o Abnormal proportion (%) como umbral. Si selecciona Slow call ratio como umbral, debe especificar el Slow call RT permitido, que representa el tiempo máximo de respuesta. Una solicitud con un tiempo de respuesta superior a este valor se cuenta como llamada lenta. En el campo Circuit Breaking Ratio Threshold, establezca la proporción de llamadas lentas que activa el corte de circuito. Una vez habilitada la regla, si el número de solicitudes en una ventana estadística supera el Minimum number of requests y la proporción de llamadas lentas excede el umbral, las solicitudes subsiguientes se bloquean automáticamente durante la Circuit Breaking Duration (s). Tras finalizar la duración del corte de circuito, el disyuntor entra en estado de recuperación por sondeo. Si el tiempo de respuesta de la siguiente solicitud es inferior al Slow call RT especificado, termina el corte de circuito. Si el tiempo de respuesta supera el Slow call RT especificado, se activa nuevamente el corte de circuito. Si selecciona Abnormal proportion como umbral, debe configurar la tasa de errores que activa el corte de circuito en el campo Circuit Breaking Ratio Threshold. Una vez habilitada la regla, si la cantidad de errores de negocio en una ventana estadística supera el Minimum number of requests y la tasa de errores excede el umbral, las solicitudes subsiguientes se bloquean automáticamente durante la Circuit Breaking Duration (s). |
|
Circuit Breaking Duration (s) |
Haga clic en Show Advanced Options para configurar este parámetro. Es la duración del corte de circuito tras su activación. Cuando un recurso entra en estado de corte de circuito, las solicitudes fallan rápidamente dentro de la duración especificada. |
|
Circuit Breaking Policy |
Haga clic en Show Advanced Options para configurar este parámetro. Define la política de recuperación que usa el disyuntor al entrar en la fase de recuperación (estado semiabierto). Single detection recovery: Tras la duración del corte de circuito, el disyuntor sondea la siguiente solicitud. Si cumple las expectativas (no es llamada lenta ni error), finaliza el corte de circuito. De lo contrario, el disyuntor regresa a la fase de corte. Progressive recovery: Debe establecer el Number of recovery phases y el Minimum number of passes per step . Tras la duración del corte de circuito, el disyuntor se recupera progresivamente según el número de fases especificado. Si el número de solicitudes en una fase alcanza el mínimo de aprobaciones por paso, se activa una comprobación. Si ninguna solicitud verificada supera el umbral, el sistema incrementa gradualmente la proporción de solicitudes permitidas hasta recuperar totalmente el tráfico. Si alguna métrica en uno de los pasos supera el umbral, el disyuntor regresa a la fase de corte. La proporción de solicitudes es T = 100/N, donde N es el número de fases de recuperación. La proporción en la primera fase es T, en la segunda es 2T, y así sucesivamente hasta llegar al 100%. Por ejemplo, si hay 3 fases de recuperación y el mínimo de aprobaciones por paso es 5, las solicitudes pasarán en proporciones de 33%, 67% y 100% en las tres fases. Cuando el número de solicitudes en una fase es mayor o igual a 5, se realiza una comprobación. Si las métricas no superan el umbral, el disyuntor avanza a la siguiente fase de recuperación hasta restaurar completamente el tráfico. |
La regla aparece en la pestaña Circuit Breaking Rules, donde puede editarla o eliminarla.
Ejemplo: Activar corte de circuito por llamadas lentas o errores
Aplique el corte de circuito cuando la llamada a un servicio de terceros responda demasiado lento y afecte la API actual, o cuando su sistema devuelva errores al mostrar contenido de terceros. Ambos casos usan el mismo tipo de regla y solo difieren en el Threshold Type seleccionado.
|
Elemento de configuración |
Ejemplo: llamadas lentas |
Ejemplo: errores |
|
Interface Name |
test |
test |
|
Statistical window duration |
1 |
1 |
|
Minimum number of requests |
10 |
10 |
|
Threshold Type |
Slow call ratio |
Abnormal proportion |
|
Slow call RT |
1000 |
No obligatorio |
|
Circuit Breaking Ratio Threshold |
80% |
80% |
|
Circuit Breaking Duration (s) |
10 |
10 |
|
Circuit Breaking Policy |
Single detection recovery |
Single detection recovery |
Con cualquiera de estas configuraciones, la ventana estadística es de 1 segundo, la regla no se activa a menos que la ventana contenga al menos 10 solicitudes, y el corte de circuito dura 10 segundos. En el ejemplo de llamadas lentas, una solicitud que tarda más de 1000 milisegundos se considera lenta, y la proporción que activa el corte de circuito es del 80%. En el ejemplo de errores, la tasa de errores que activa el corte de circuito es del 80%.
Configurar reglas de protección de parámetros hotspot (RPC)
Al configurar reglas de hotspot para una aplicación, el sistema analiza los parámetros estadísticos, es decir, aquellos invocados frecuentemente durante las llamadas a recursos. Según las reglas de hotspot, el sistema limita las llamadas a recursos que contienen estos parámetros para proteger la estabilidad del sistema. Utilice este tipo de regla para llamadas a recursos RPC, donde un parámetro hotspot se identifica por su posición de índice en el punto de instrumentación.
Haga clic en la pestaña Hotspot Parameter Protection (RPC) y luego en Create Hotspot Parameter Protection Rule (RPC).
-
En el cuadro de diálogo Create Hotspot Parameter Protection Rule (RPC), complete los siguientes asistentes:
En el asistente Select Protection Scenario, seleccione API Name y luego haga clic en Next.
En el asistente Configure Protection Rule, configure los parámetros descritos en la siguiente tabla y luego haga clic en Next.
En el asistente Configure Protection Behavior, seleccione un Associated Behavior y luego haga clic en Create.
La siguiente tabla describe los parámetros del asistente Configure Protection Rule.
|
Elemento de configuración |
Descripción |
|
Parameter position Index |
La posición de índice del parámetro pasado en el recurso del punto de instrumentación. Corresponde a la posición del índice del parámetro en |
|
Statistical dimension |
Puede medir el número de solicitudes o el número de hilos concurrentes. Number of requests: Limita el número de llamadas dentro de un periodo de tiempo. Concurrent number: Limita el número de llamadas concurrentes al recurso. |
|
Statistical cycle time |
La duración de la ventana estadística, en segundos. Por ejemplo, si la ventana estadística es de 10 segundos y el umbral de QPS es 5, cada parámetro hotspot podrá accederse como máximo 5 veces en 10 segundos. |
|
Single machine threshold |
El umbral que aplica a cada parámetro hotspot. |
|
Flow control effect |
Si la Statistical dimension está configurada como Number of requests, puede seleccionar cómo manejar el tráfico limitado. Fast failure: Al alcanzar el umbral, las solicitudes se bloquean inmediatamente. En este modo, también puede establecer un Number of buffered requests, que es la cantidad de solicitudes adicionales permitidas para ráfagas de tráfico. Waiting in line: Las solicitudes pasan a una tasa constante y las excedentes se ponen en cola. Este método se usa típicamente para el desplazamiento de carga pico. Debe establecer un periodo de tiempo de espera. Cuando una solicitud se pone en cola, el sistema calcula su tiempo estimado de espera. Si este supera el tiempo máximo de espera, la solicitud se rechaza. Por ejemplo, si el Single machine threshold es 5, solo pasa una solicitud cada 200 milisegundos y las excedentes se encolan. Si el Timeout es de 1000 milisegundos, las nuevas solicitudes se rechazan cuando ya hay más de 5 en cola, lo que equivale a un tiempo de espera superior a 1000 milisegundos. |
|
Whether to open |
Si activa este interruptor, la regla entra en vigor inmediatamente después de su creación. El interruptor está desactivado de forma predeterminada. |
La regla aparece en la pestaña Hotspot Parameter Protection (RPC), donde puede editarla o eliminarla.
Ejemplo: Poner en cola solicitudes para un artículo hotspot durante una venta relámpago
Durante ventas relámpago y otros eventos de compra masiva, el alto tráfico puede ralentizar las respuestas del sistema o incluso colapsarlo. Para mantener la estabilidad, puede configurar una regla de hotspot de modo que el sistema ponga en cola el tráfico de artículos populares tras superar un umbral. Este ejemplo pone en cola las solicitudes excedentes a una API RPC en lugar de rechazarlas: si las solicitudes de compra del mismo artículo superan 100 en 1 segundo, el resto se pone en cola.
Introduzca el Interface Name.
Establezca la Statistical dimension en Number of requests.
Establezca el Statistical cycle time en 1 segundo y el Single machine threshold en 100.
Establezca el Flow control effect en Waiting in line.
-
Establezca el Timeout en 30 milisegundos.
Si esta API se llama más de 100 veces en 1 segundo, las solicitudes excedentes se ponen en cola. Una solicitud que espere más de 30 milisegundos fallará inmediatamente.
Ejemplo: Limitar llamadas frecuentes que consumen recursos excesivos del sistema
En una venta relámpago, a veces los clientes también necesitan cambiar la dirección de entrega de un pedido. Un gran volumen de estas solicitudes de cambio consume importantes recursos de escritura en la base de datos. Puede limitar las llamadas concurrentes que llevan el mismo parámetro hotspot para que los clientes realicen el cambio más tarde.
Introduzca el Interface Name.
Establezca la Statistical dimension en Concurrent number.
-
Establezca el Statistical cycle time en 1 segundo y el Single machine threshold en 100.
Esta configuración permite un máximo de 100 llamadas concurrentes para cada parámetro hotspot. Las solicitudes excedentes se rechazan.
Configurar reglas de protección de parámetros hotspot (solicitud HTTP)
Las reglas de protección de parámetros hotspot para solicitudes HTTP aplican a aplicaciones que proporcionan servicios web. Estas reglas realizan un modelado de tráfico granular sobre parámetros específicos en las solicitudes de acceso. Puede moldear el tráfico de llamadas a recursos basándose en dimensiones de solicitud como dirección IP, Host, Header y URL Param para mantener la estabilidad del negocio y del sistema.
Haga clic en la pestaña Hotspot Parameter Protection (HTTP Request) y luego en Create Hotspot Parameter Protection Rule (HTTP Request).
-
En el cuadro de diálogo Create Hotspot Parameter Protection Rule (HTTP Request), complete los siguientes asistentes:
En el asistente Select Protection Scenario, seleccione API Name y luego haga clic en Next.
En el asistente Configure Protection Rule, configure los parámetros descritos en la siguiente tabla y luego haga clic en Next.
En el asistente Configure Protection Behavior, seleccione un Associated Behavior y luego haga clic en Create.
La siguiente tabla describe los parámetros del asistente Configure Protection Rule.
|
Elemento de configuración |
Descripción |
|
Parameter Properties |
Moldea el tráfico según las propiedades de parámetro de la API seleccionada. Client IP: La dirección IP del cliente. Si una solicitud pasa por un proxy, el sistema intenta primero obtener la IP del encabezado de solicitud |
|
Threshold Type |
El valor predeterminado es Request count. |
|
Threshold |
El umbral de QPS del objeto en la dimensión estadística de la API limitada. Al establecer el umbral, debe seleccionar un intervalo estadístico. Los intervalos admitidos son segundo, minuto, hora y día. Por ejemplo, si establece el umbral en 10 y selecciona minute como intervalo, no se permitirán más de 10 solicitudes por minuto. |
|
Whether to open |
Si activa este interruptor, la regla entra en vigor inmediatamente después de su creación. El interruptor está desactivado de forma predeterminada. |
|
Throttling method |
Haga clic en Show Advanced Options para configurar este parámetro. Fast failure: Si el tipo de umbral es QPS, el tráfico limitado falla rápidamente, lo que significa que las solicitudes se bloquean inmediatamente al alcanzar el umbral. Las solicitudes rechazadas reciben la respuesta personalizada configurada en la gestión de comportamientos. Si no hay respuesta personalizada, aplica el comportamiento predeterminado, que devuelve el código de error 429 y el mensaje de texto por defecto. Waiting in line: Si el tipo de umbral es QPS, las solicitudes limitadas pasan a una tasa constante y pueden ponerse en cola. Debe establecer un periodo de tiempo de espera. Una solicitud que previsiblemente alcance dicho periodo falla inmediatamente en lugar de encolarse. Por ejemplo, si el QPS es 10, solo pasa una solicitud cada 100 milisegundos y las excedentes se encolan. El periodo de tiempo de espera es el tiempo máximo en cola. Las solicitudes que superen este máximo se rechazan. Para el límite de QPS aplicable cuando las solicitudes se encolan, consulte Limits. |
|
Burst size |
Haga clic en Show Advanced Options para configurar este parámetro. Si Throttling method está configurado como Fast failure, puede establecer un tamaño de ráfaga, que es la cantidad de solicitudes adicionales permitidas para ráfagas de tráfico. |
|
Timeout |
Haga clic en Show Advanced Options para configurar este parámetro. Si Throttling method está configurado como Waiting in line, debe establecer un periodo de tiempo de espera en milisegundos. Por ejemplo, si el QPS es 5, solo pasa una solicitud cada 200 milisegundos y las excedentes se encolan. El periodo de tiempo de espera es el tiempo máximo en cola. Las solicitudes que superen este máximo se rechazan. |
La regla aparece en la pestaña Hotspot Parameter Protection (HTTP Request), donde puede editarla o eliminarla.
Ejemplo: Venta relámpago de un producto hotspot
Durante ventas relámpago y otros eventos de compra masiva, el alto tráfico puede ralentizar las respuestas del sistema o incluso colapsarlo. Para mantener la estabilidad, puede configurar una regla de protección de parámetros hotspot de modo que el sistema rechace el tráfico excedente de artículos populares tras superar un umbral. Este ejemplo aplica a una API HTTP y rechaza las solicitudes excedentes en lugar de ponerlas en cola.
Por ejemplo, para rechazar las solicitudes excedentes después de que las peticiones del mismo producto superen 100 en 1 segundo, configure los siguientes parámetros. Esta regla permite un máximo de 100 solicitudes de pedido por segundo para cada ID de producto individual y rechaza las solicitudes excedentes para ese producto con una respuesta personalizada.
Establezca Parameter Properties en URL parameter.
Introduzca
stockIdpara URL parameter name.Introduzca 100 solicitudes por second para Threshold.
Establezca Throttling method en Fast failure.
En las propiedades del parámetro, seleccione el campo de parámetro que corresponde al ID del producto hotspot. Por ejemplo, si un campo stockId en los parámetros URL lleva el ID del producto solicitado, puede establecer la propiedad del parámetro como URL parameter e introducir el nombre del campo de la propiedad en la solicitud como nombre del parámetro.
Ejemplo: Prevenir pedidos maliciosos
Durante un evento promocional, un gran número de solicitudes de pedido maliciosas ocupa inventario de productos o recursos del servidor. En este caso, puede poner en cola las solicitudes según sus direcciones IP de origen para que las solicitudes de acceso pasen a una tasa constante. Esto evita que el exceso de solicitudes afecte la estabilidad del servicio. Configure la siguiente regla:
Establezca Parameter Properties en Client IP.
Mantenga el valor predeterminado Request count para Threshold Type.
Introduzca 100 solicitudes por second para Threshold.
Establezca Throttling method en Waiting in line.
Introduzca 30 milisegundos para Timeout.
-
Active Whether to open.
Con esta regla, las solicitudes de cada dirección IP de origen pasan a una tasa de una solicitud cada 10 milisegundos (1 segundo/100 = 10 milisegundos), y las excedentes se ponen en cola. Una solicitud en cola que espere más de 30 milisegundos fallará inmediatamente.
Gestión de comportamientos
Un comportamiento web devuelve una respuesta personalizada después de que se activa una regla en un resource de punto de instrumentación web. Por ejemplo, una API web puede devolver el mensaje Blocked by Sentinel tras activar una regla de limitación.
Crear un comportamiento
Haga clic en la pestaña Behavior Management y luego en Create Behavior.
-
En el cuadro de diálogo Create Behavior, configure los parámetros descritos en las siguientes tablas y haga clic en Create.
La siguiente tabla describe los parámetros aplicables cuando Resource Type está establecido en Web.
|
Parámetro |
Descripción |
Valor de ejemplo |
|
Behavior Name |
Nombre del comportamiento. Puede tener hasta 128 caracteres y debe ser único dentro de la aplicación. |
Test behavior |
|
Resource Type |
Seleccione Web. |
Web |
|
**Web throttling handler Web Throttling Policy |
Define cómo responde el sistema cuando el acceso a una API web activa una regla. Respuesta personalizada: Debe establecer el código de estado HTTP, el formato del contenido devuelto y el contenido mismo. La API web devuelve este contenido personalizado al activarse la regla. |
Custom response |
|
HTTP Status Code |
El valor predeterminado es 429. Este parámetro es obligatorio cuando Web throttling handler se establece en Custom response. |
429 |
|
Returned Content-Type |
Establezca el formato del contenido devuelto como Plain text o JSON. |
JSON string |
|
Returned HTTP Text |
Introduzca el contenido que se devuelve cuando el acceso a la API web activa una regla. Este parámetro es obligatorio cuando Web throttling handler se establece en Custom response. |
|
La siguiente tabla describe los parámetros aplicables cuando Resource Type está establecido en RPC.
|
Parámetro |
Descripción |
Valor de ejemplo |
|
Behavior Name |
Nombre del comportamiento. Puede tener hasta 128 caracteres y debe ser único dentro de la aplicación. |
Test behavior |
|
Resource Type |
Seleccione RPC. Para conocer las versiones de Apache Dubbo que no admiten comportamientos personalizados, consulte Limits. |
Rpc |
|
RPC throttling handler |
Define cómo responde el sistema cuando el acceso a una API RPC activa una regla. Custom response: Devuelve un resultado personalizado. Debe establecer el código de estado HTTP, el formato del contenido devuelto y el contenido mismo. La API RPC devuelve este contenido personalizado al activarse la regla. Custom exception: Lanza una excepción personalizada. Debe especificar el nombre de la clase de excepción y el texto de la misma. El sistema devuelve la información de excepción indicada cuando el acceso a la API RPC activa la regla. |
Custom response/Custom exception |
|
Custom response class name |
Obligatorio cuando RPC throttling handler se establece en Custom response. Introduzca la ruta del nombre de la clase. Para consultar los tipos de objeto no compatibles con la respuesta personalizada, vea Limits. |
|
|
Custom response content (JSON) |
Obligatorio cuando RPC throttling handler se establece en Custom response. Introduzca el contenido del objeto que se devuelve cuando el acceso a la API RPC activa una regla. |
|
|
Exception class name |
Obligatorio cuando RPC throttling handler se establece en Custom exception. Introduzca la ruta del nombre de la clase de excepción. |
|
|
Exception message |
Obligatorio cuando RPC throttling handler se establece en Custom exception. Introduzca el texto de la excepción personalizada que se lanza cuando el acceso a la API RPC activa una regla. |
|
El comportamiento creado aparece en la pestaña Behavior Management, donde puede modificarlo o eliminarlo.
Asociar un comportamiento con una regla existente
Un comportamiento se asocia con una regla mediante el asistente Configure Protection Behavior durante la creación de dicha regla. Para cambiar el comportamiento de una regla ya existente, edite la regla.
Haga clic en la pestaña Traffic Protection y luego en la pestaña correspondiente al tipo de regla.
Localice la regla y haga clic en Edit en la columna Actions.
Complete los asistentes Select Protection Scenario y Configure Protection Rule.
En el asistente Configure Protection Behavior, seleccione el comportamiento en la lista desplegable Associated Behavior. También puede hacer clic en Create Behavior para crear uno nuevo y asociarlo a la regla.
-
Haga clic en Save.
Antes de asociar un comportamiento, tenga en cuenta lo siguiente:
Comportamiento predeterminado: Si no requiere un comportamiento de respaldo personalizado para solicitudes limitadas, seleccione el comportamiento predeterminado. El tipo de API de este comportamiento queda vacío.
Vinculación existente: Al crear una regla, si la API ya tiene un comportamiento vinculado, el nuevo comportamiento sobrescribe al anterior.
Tipo de API: Al seleccionar un comportamiento, se vincula el predeterminado si no elige un tipo de API. Una vez seleccionado un tipo de API y vinculado su comportamiento correspondiente, no podrá modificar dicho tipo.