En los microservicios, la relación de llamadas entre los servicios es compleja y un microservicio a menudo depende de muchos otros microservicios. Si el proveedor del servicio I falla, parte del negocio de la aplicación actual se bloqueará porque depende del servicio I. En este momento, Otros que no dependen del servicio casi no se ven afectados, pero cuando la solicitud que depende del servicio no será respondida, el hilo del tomcat no se liberará, por lo que llegan más y más solicitudes de usuarios y más y más hilos Se bloqueará, la cantidad de subprocesos y la concurrencia admitida por el servidor es limitada, y la solicitud se bloqueará todo el tiempo, lo que provocará el agotamiento de los recursos del servidor, lo que provocará la falta de disponibilidad de todos los demás servicios, luego el servicio actual tampoco está disponible, luego seguirán otros servicios que dependen del servicio actual A medida que pasa el tiempo, eventualmente dejará de estar disponible, formando una cascada de fallas y se produce una avalancha

1. Hay 4 formas de solucionar la avalancha:

1.1.2 Procesamiento de tiempo de espera:

Establezca el tiempo de espera, la solicitud devolverá un mensaje de error si no hay respuesta después de un cierto período de tiempo y no esperará interminablemente

1.1.3 Modo de pared de almacén

El patrón de la pared del almacén proviene del diseño de la cabina:

Similar a esto, podemos limitar la cantidad de subprocesos que cada empresa puede usar para evitar agotar todo el recurso tomcat, por lo que también se denomina aislamiento de subprocesos.

1.1.4 Disyuntor

Modo de disyuntor: el disyuntor cuenta la proporción anormal de ejecución comercial Si se supera el umbral, la empresa se fusionará y todas las solicitudes de acceso a la empresa serán interceptadas.

El disyuntor contará el número de solicitudes de acceso a un servicio, la relación anormal:

Cuando se encuentra que la proporción anormal de solicitudes de acceso al servicio D es demasiado alta, se considera que el servicio D tiene el riesgo de causar una avalancha, y todas las solicitudes de acceso al servicio D serán interceptadas para formar un interruptor automático:

1.1.5 Limitación de corriente

Control de flujo : QPS para limitar el acceso comercial para evitar fallas en el servicio debido a un aumento repentino en el tráfico.

1.1.6 Resumen

¿Cuál es el problema de las avalanchas?

Los microservicios se llaman entre sí, porque una falla en el servicio en la cadena de llamadas hace que todo el enlace sea inaccesible.

Se puede considerar:

La limitación de corriente es la protección de los servicios, evitando fallas en el servicio causadas por un alto tráfico concurrente instantáneo, evitando así avalanchas. es una medida cautelar .

El procesamiento de tiempo de espera, el aislamiento de subprocesos y el fusible de degradación se utilizan para controlar la falla dentro de un cierto rango y evitar avalanchas cuando fallan algunos servicios. es un remedio

1.2 Comparación de tecnologías de protección de servicios

Spring Cloud admite varias tecnologías de protección de servicios:

El framework Hystrix fue más popular en los primeros días, pero en la actualidad, el más utilizado en China es el framework Sentinel de Alibaba, aquí hacemos una comparación:

	Centinela	Hystrix
política de aislamiento	Aislamiento de semáforo	Aislamiento de grupos de subprocesos/aislamiento de semáforos
Estrategia de reducción de disyuntores	Basado en la proporción de llamadas lentas o la proporción anormal	Basado en la tasa de fracaso
Implementación de indicadores en tiempo real	ventana deslizante	Ventana deslizante (basada en RxJava)
configuración de reglas	Soporta múltiples fuentes de datos	Soporta múltiples fuentes de datos
Escalabilidad	múltiples puntos de extensión	formulario de complemento
Soporte basado en anotaciones	apoyo	apoyo
limitando	Basado en QPS, admite limitación de corriente según la relación de llamada	soporte limitado
conformación del tráfico	Admite inicio lento, modo de cola uniforme	no apoyo
Protección adaptativa del sistema	apoyo	no apoyo
consola	De manera inmediata, puede configurar reglas, ver el monitoreo de segundo nivel, el descubrimiento de máquinas, etc.	imperfecto
Adaptación a Marcos Comunes	Servlet, Spring Cloud, Dubbo, gRPC	Servlet, Nube de primavera Netflix

1.3.Introducción e instalación de Sentinelp

1.3.1 Conociendo a Sentinel

Sentinel es un componente de control de tráfico de microservicios de código abierto de Alibaba. Dirección del sitio web oficial: home | Sentinel

Sentinel tiene las siguientes características:

Escenarios de aplicaciones enriquecidos : Sentinel ha llevado a cabo los escenarios centrales de la promoción de tráfico Double Eleven de Alibaba en los últimos 10 años, como seckill (es decir, el tráfico de ráfagas se controla dentro del rango que puede soportar la capacidad del sistema), reducción de picos de mensajes y llenado de valles y control de tráfico de clúster, fusión en tiempo real de aplicaciones no disponibles aguas abajo, etc.
Supervisión completa en tiempo real : Sentinel también proporciona funciones de supervisión en tiempo real. En la consola, puede ver los datos de segundo nivel de una sola máquina conectada a la aplicación, o incluso el estado de ejecución agregado de un clúster con una escala de menos de 500.
Amplio ecosistema de código abierto : Sentinel proporciona módulos de integración listos para usar con otros marcos/bibliotecas de código abierto, como la integración con Spring Cloud, Dubbo y gRPC. Solo necesita introducir las dependencias correspondientes y realizar configuraciones simples para acceder rápidamente a Sentinel.
Punto de extensión SPI perfecto : Sentinel proporciona una interfaz de extensión SPI completa y fácil de usar. Puede personalizar rápidamente la lógica implementando la interfaz de extensión. Por ejemplo, gestión de reglas personalizadas, adaptación de fuentes de datos dinámicas, etc.

1.3.2 Instalar Sentinel

1) Descargar

Sentinel proporciona oficialmente una consola de interfaz de usuario, lo que nos resulta conveniente para establecer el límite actual en el sistema. Puedes descargarlo en GitHub

2) correr

Coloque el paquete jar en cualquier directorio que no sea chino y ejecute el comando:

java -jar sentinel-dashboard-1.8.1.jar

Si desea modificar el puerto, la cuenta y la contraseña predeterminados de Sentinel, puede utilizar la siguiente configuración:

elemento de configuración	valores predeterminados	ilustrar
Puerto de servicio	8080	Puerto de servicio
sentinel.dashboard.auth.nombre de usuario	centinela	nombre de usuario predeterminado
sentinel.dashboard.auth.contraseña	centinela	contraseña predeterminada

Por ejemplo, para modificar el puerto:

java -Dserver.port=8090 -jar sentinel-dashboard-1.8.1.jar

3) visita

Visite la página http://localhost:8080 y podrá ver la consola de Sentinel:

Debe ingresar el número de cuenta y la contraseña, el valor predeterminado es: centinela

Después de iniciar sesión, encontré un espacio en blanco, nada:

Esto se debe a que aún no nos hemos integrado con los microservicios.

1.4 Integración de microservicios Sentinel

Integramos sentinel en order-service y nos conectamos a la consola de sentinel, los pasos son los siguientes:

1) Introducir dependencia centinela

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2) Configurar la consola

Modifique el archivo application.yaml y agregue el siguiente contenido:

server:
  port: 8088
spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8080

3) Acceder a cualquier punto final del servicio de pedidos

Abra el navegador y visite http://localhost:8088/order/101 , para activar el monitoreo de Sentinel.

Luego visite la consola centinela para ver el efecto:

2. Control de flujo

Aunque existen cuatro soluciones para el problema de las avalanchas, la limitación actual es para evitar fallas en el servicio debido al tráfico repentino y para prevenir el problema de las avalanchas de los microservicios. Primero aprendamos este patrón.

2.1 Enlace de clúster

Cuando una solicitud ingresa a un microservicio, primero accede a DispatcherServlet y luego ingresa a Controller, Service y Mapper.Esta cadena de llamadas se denomina enlace de punto de clúster . Cada interfaz monitoreada en el enlace del clúster es un recurso .

De forma predeterminada, Sentinel monitoreará cada punto final (Punto final, que es el método en el controlador) de SpringMVC, por lo que cada punto final (Punto final) de SpringMVC es un recurso en el enlace de llamada.

Por ejemplo, el punto en OrderController en el servicio de pedidos que acabamos de visitar: /order/{orderId}

El control de flujo, el fusible, etc. están configurados para los recursos en el enlace del clúster, por lo que podemos hacer clic en el botón detrás del recurso correspondiente para establecer las reglas:

control de flujo: control de flujo
Degradación: fusible de degradación
Punto de acceso: límite de corriente del parámetro de punto de acceso, que es una especie de límite de corriente
Autorización: solicitud de control de permisos

2.1 Inicio rápido

2.1.1 Ejemplos

Haga clic en el botón de control de flujo detrás de resource/order/{orderId} para abrir el formulario.

Puede completar las reglas de limitación actuales en el formulario, de la siguiente manera:

Su significado es limitar el QPS independiente del recurso /order/{orderId} a 1, es decir, solo se permite 1 solicitud por segundo, y las solicitudes en exceso se interceptarán y se informará un error.

2.1.2 Práctica:

Requisito: establezca reglas de control de flujo para el recurso /order/{orderId}, QPS no puede exceder 5 y luego pruebe.

1) Primero agregue la regla de limitación actual en la consola Sentinel

2) Use jmeter para probar

elegir:

20 usuarios, se ejecutan en 2 segundos, QPS es 10, más de 5.

Seleccione 流控入门，QPS<5el botón derecho para ejecutar:

Tenga en cuenta que no haga clic en el botón ejecutar en el menú para ejecutar.

resultado:

Como puede ver, solo hay 5 solicitudes exitosas cada vez

2.2 Modo de control de flujo

Al agregar una regla de limitación de flujo, haga clic en Opciones avanzadas para elegir entre tres modos de control de flujo :

Directo: solicitudes estadísticas de recursos actuales y limita directamente el flujo de recursos actuales cuando se activa el umbral, que también es el modo predeterminado
Asociación: cuenta otro recurso relacionado con el recurso actual y limita el flujo del recurso actual cuando se activa el umbral
Enlace: cuenta las solicitudes para acceder a este recurso desde el enlace especificado y limita el flujo del enlace especificado cuando se activa el umbral

La prueba de inicio rápido es el modo directo.

2.2.1 Modo de asociación

Modo de asociación : cuenta otro recurso relacionado con el recurso actual y limita el flujo del recurso actual cuando se activa el umbral

Reglas de configuración :

Descripción gramatical : cuando el volumen de acceso de los recursos de /escritura alcanza el umbral, el flujo de recursos de /lectura se limitará para evitar que afecte a los recursos de /escritura.

Escenario de uso : por ejemplo, el usuario necesita modificar el estado del pedido al pagar y el usuario desea consultar el pedido al mismo tiempo. Las operaciones de consulta y modificación compiten por los bloqueos de la base de datos, creando contención. El requerimiento del negocio es dar prioridad al negocio de pago y actualización de órdenes, por lo tanto, al modificar el umbral de disparo del negocio de órdenes, es necesario limitar el flujo del negocio de órdenes de consulta.

Descripción de los requisitos :

Cree dos puntos finales en OrderController: /order/query y /order/update, sin necesidad de implementar negocios
Configurar reglas de control de flujo, cuando el QPS accedido por el recurso /pedido/actualizar supere 5, limitar el flujo de solicitudes de /pedido/consulta

1) Defina el punto final /pedido/consulta para simular una consulta de pedido

@GetMapping("/query")
public String queryOrder() {
    return "查询订单成功";
}

2) Defina el punto final /order/update para simular actualizaciones de pedidos

@GetMapping("/update")
public String updateOrder() {
    return "更新订单成功";
}

Reinicie el servicio y vea el enlace del clúster de la consola Sentinel:

3) Configurar reglas de control de flujo

Para limitar la corriente de qué punto final, haga clic en el botón detrás de ese punto final. Estamos limitando la consulta de pedido/pedido/consulta, así que haga clic en el botón que se encuentra detrás:

Complete las reglas de control de flujo en el formulario:

4) Prueba en Jmeter

Seleccione "Modo de control de flujo-Asociación":

Puede ver 1000 usuarios, 100 segundos, por lo que el QPS es 10, lo que supera el umbral que establecemos: 5

Ver solicitud http:

El destino de la solicitud es /order/update, por lo que este punto de interrupción activa el umbral.

Pero el objetivo del límite actual es /order/query, visitamos en el navegador, podemos encontrar:

De hecho, es limitado.

5) Resumen

2.2.2 Modo enlace

Modo de enlace : solo haga estadísticas sobre las solicitudes para acceder a este recurso desde el enlace especificado y juzgue si excede el umbral.

Ejemplo de configuración :

Por ejemplo, hay dos enlaces de solicitud:

/prueba1 --> /común
/prueba2 --> /común

Si solo desea contar las solicitudes de /test2 a /common, puede configurarlo así:

Caso práctico

Requisitos: Existen servicios de consulta de pedidos y creación de pedidos, los cuales necesitan consultar productos básicos. Para las estadísticas de solicitudes desde la consulta de pedidos hasta la consulta de productos, y establecer un límite actual.

paso:

Agregue un método queryGoods en OrderService sin implementar negocios
En OrderController, modifique el punto final /order/query y llame al método queryGoods en OrderService
Agregue un punto final /order/save a OrderController y llame al método queryGoods de OrderService
Establezca la regla de límite actual para queryGoods, el límite de QPS del método de ingreso de queryGoods desde /order/query debe ser inferior a 2

lograr:

1) Agregar un método de producto de consulta

En el servicio de servicio de pedidos, agregue un método queryGoods a la clase OrderService:

public void queryGoods(){
    System.err.println("查询商品");
}

2) Al consultar sobre un pedido, consultar sobre el producto

En OrderController de order-service, modifique la lógica empresarial del punto final /order/query:

@GetMapping("/query")
public String queryOrder() {
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.out.println("查询订单");
    return "查询订单成功";
}

3) Agregar nuevos pedidos y consultar productos

En OrderController de order-service, modifique el punto final /order/save para simular un nuevo pedido:

@GetMapping("/save")
public String saveOrder() {
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.err.println("新增订单");
    return "新增订单成功";
}

4) Agregue una etiqueta de recurso al producto de consulta

De forma predeterminada, Sentinel no supervisa los métodos de OrderService y debemos marcar los métodos que se supervisarán mediante anotaciones.

Agregue la anotación @SentinelResource al método queryGoods de OrderService:

@SentinelResource("goods")
public void queryGoods(){
    System.err.println("查询商品");
}

En el modo de enlace, se monitorean dos enlaces de diferentes fuentes. Sin embargo, Sentinel establecerá el mismo recurso raíz para todas las solicitudes que ingresen a SpringMVC de forma predeterminada, lo que hará que el modo de enlace falle.

Necesitamos desactivar esta agregación de recursos para SpringMVC y modificar el archivo application.yml del servicio de servicio de pedidos:

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

Reinicie el servicio, visite /order/query y /order/save, y podrá ver que han aparecido nuevos recursos en las reglas de enlace de punto de clúster de Sentinel:

5) Agregar reglas de control de flujo

Haga clic en el botón de control de flujo detrás del recurso de bienes y complete la siguiente información en el formulario emergente:

Solo se cuentan los recursos que ingresan /bienes de /pedido/consulta El umbral de QPS es 2, y si lo supera, se limitará el flujo.

6) prueba Jmeter

Seleccione "Modo de control de flujo-Enlace":

Se puede ver que hay 200 usuarios aquí, y el envío se completa en 50 segundos, y el QPS es 4, lo que supera el umbral 2 que establecimos.

Una solicitud http es para acceder a /order/save:

El resultado de ejecutar:

No afectado en absoluto.

La otra es acceder a /pedir/consultar:

resultado de la operación:

Solo pasan 2 a la vez.

2.2.3 Resumen

¿Cuáles son los modos de control de flujo?

Directo: limitar los recursos actuales
Asociación: los recursos de alta prioridad desencadenan umbrales y los recursos de baja prioridad son limitados.
Enlace: al contar el umbral, solo se cuentan las solicitudes que ingresan al recurso actual desde el recurso especificado, que es el límite actual en la fuente de la solicitud

2.3 Efecto de control de flujo

En las opciones avanzadas de control de flujo, también hay una opción de efecto de control de flujo:

El efecto de control de flujo se refiere a las medidas que deben tomarse cuando la solicitud alcanza el umbral de control de flujo, incluyendo tres tipos:

Falla rápido: una vez que se alcanza el umbral, las nuevas solicitudes se rechazan inmediatamente y se lanza una FlowException. es el método de procesamiento predeterminado.
calentamiento: modo de calentamiento, las solicitudes que superan el umbral también se rechazan y se lanza una excepción. Pero este umbral de modo cambiará dinámicamente, aumentando gradualmente desde un valor pequeño hasta un umbral máximo.
Esperando en cola: permita que todas las solicitudes se ejecuten en una cola en orden, y el intervalo entre dos solicitudes no puede ser menor que el tiempo especificado

2.3.1.calentamiento

El umbral es generalmente el QPS máximo que puede realizar un microservicio. Sin embargo, cuando un servicio acaba de iniciarse, no se han inicializado todos los recursos ( arranque en frío ). Si el QPS se ejecuta directamente al valor máximo, puede causar que el servicio bajar al instante.

El calentamiento también se denomina modo de calentamiento , que es una solución para el inicio en frío de los servicios. El valor inicial del umbral de solicitud es maxThreshold/coldFactor y, después de una duración específica, aumentará gradualmente hasta el valor de maxThreshold. El valor predeterminado de ColdFactor es 3.

Por ejemplo, si configuro maxThreshold of QPS en 10 y el tiempo de calentamiento en 5 segundos, entonces el umbral inicial es 10/3, que es 3, y luego aumenta gradualmente a 10 después de 5 segundos.

el caso

Requisitos: establezca un límite actual para el recurso /order/{orderId}, el QPS máximo es 10, use el efecto de calentamiento y el tiempo de calentamiento es de 5 segundos

1) Configurar reglas de control de flujo:

2) prueba Jmeter

Seleccione "Efecto de control de flujo, calentamiento":

QPS es 10.

Cuando recién se inició, la mayoría de las solicitudes fallaron y solo 3 tuvieron éxito, lo que indica que el QPS está limitado a 3:

Con el tiempo, el porcentaje de éxitos es cada vez mayor:

Vaya a la consola de Sentinel para ver el monitoreo en tiempo real:

Al poco tiempo:

2.3.2 Esperando en la fila

Rechace rápido y caliente, rechace nuevas solicitudes y genere excepciones cuando las solicitudes excedan el umbral de QPS.

Hacer cola y esperar es permitir que todas las solicitudes entren en una cola y luego ejecutarlas secuencialmente de acuerdo con el intervalo de tiempo permitido por el umbral. Las solicitudes posteriores deben esperar a que se completen las ejecuciones anteriores y se rechazarán si el tiempo de espera previsto para la solicitud supera la duración máxima.

principio de funcionamiento

Por ejemplo: QPS = 5, significa que una solicitud en la cola se procesa cada 200 ms; timeout = 2000, significa que las solicitudes con un tiempo de espera esperado de más de 2000 ms serán rechazadas y se lanzará una excepción.

Entonces, ¿cuál es el tiempo de espera esperado?

Por ejemplo, llegan 12 solicitudes a la vez, porque se ejecuta una solicitud cada 200 ms, entonces:

Tiempo de espera esperado para la sexta solicitud = 200 * (6 - 1) = 1000ms
Tiempo de espera esperado para la solicitud número 12 = 200 * (12-1) = 2200 ms

Ahora, se reciben 10 solicitudes al mismo tiempo en el primer segundo, pero solo se recibe una solicitud en el segundo segundo. En este momento, la curva QPS se ve así:

Si usa el modo de cola para el control de flujo, todas las solicitudes entrantes deben ponerse en cola y ejecutarse en un intervalo fijo de 200 ms, y el QPS será muy fluido:

Una curva QPS suave es más amigable para el servidor.

el caso

Requisito: establezca el límite actual para el recurso/pedido/{orderId}, el QPS máximo es 10, use el efecto de control de flujo de la cola y establezca el período de tiempo de espera en 5 s.

1) Agregar reglas de control de flujo

2) prueba Jmeter

Seleccione "Efecto de control de flujo, cola":

El QPS es 15, que ha superado los 10 que establecimos.

Si es el modo de calentamiento y falla rápida anterior, las solicitudes en exceso deberían informar directamente un error.

Pero veamos los resultados de ejecución del modo de cola:

Todo pasó.

Luego vaya a centinela para ver la curva QPS de monitoreo en tiempo real:

QPS es muy fluido y se mantiene constantemente en 10, pero las solicitudes en exceso no se rechazan, sino que se ponen en cola. Entonces el tiempo de respuesta (tiempo de espera) será cada vez más largo.

Cuando la cola está llena, algunas solicitudes fallarán:

2.3.3 Resumen

¿Cuáles son los efectos del control de flujo?

Falla rápido: rechaza nuevas solicitudes cuando el QPS supera el umbral
calentamiento: cuando el QPS supera el umbral, se rechazan nuevas solicitudes; el umbral de QPS aumenta gradualmente, lo que puede evitar el tiempo de inactividad del servicio causado por la alta concurrencia durante el arranque en frío.
Esperando en cola: la solicitud ingresará a la cola y la solicitud se ejecutará secuencialmente de acuerdo con el intervalo de tiempo permitido por el umbral; si el tiempo de espera esperado de la solicitud es mayor que el tiempo de espera, se rechazará directamente

2.4 Límite actual de los parámetros del punto de acceso

La limitación actual anterior es contar todas las solicitudes para acceder a un determinado recurso y juzgar si supera el umbral de QPS. El límite actual del parámetro del punto de acceso es para contar las solicitudes con el mismo valor de parámetro por separado y juzgar si excede el umbral de QPS.

2.4.1 Limitación de corriente de parámetros globales

Por ejemplo, una interfaz para consultar productos por id:

En la solicitud de acceso a /bienes/{id}, el valor del parámetro id cambiará, y el límite actual del parámetro del punto de acceso contará el QPS por separado de acuerdo con el valor del parámetro, y los resultados estadísticos son los siguientes:

Cuando la solicitud con id=1 provoca que el umbral sea limitado, la solicitud con un valor de id distinto de 1 no se verá afectada.

Ejemplo de configuración:

El significado del representante es: hacer estadísticas sobre el parámetro 0 (el primer parámetro) del recurso activo, y la cantidad de solicitudes para el mismo valor de parámetro por segundo no puede exceder 5

2.4.2 Límite actual de los parámetros del punto de acceso

En la configuración de ahora, todos los productos de la interfaz para consultar productos se tratan por igual y el QPS está limitado a 5.

En el desarrollo real, algunos productos pueden ser productos populares, como productos de venta flash. Esperamos que el límite de QPS de estos productos sea diferente de otros productos y sea más alto. Luego, debe configurar las opciones avanzadas del límite actual del parámetro del punto de acceso:

Combinado con la configuración anterior, el significado aquí es limitar la corriente del parámetro de tipo largo del número 0, y las QPS del mismo parámetro no pueden exceder las 5 por segundo, con dos excepciones:

Si el valor del parámetro es 100, el QPS permitido por 1 segundo es 10
Si el valor del parámetro es 101, el QPS permitido por 1 segundo es 152.4.4.

Requisitos del caso : agregue un límite actual de parámetro de punto de acceso al recurso /order/{orderId}, las reglas son las siguientes:

La regla del parámetro de punto de acceso predeterminado es que la cantidad de solicitudes por segundo no debe exceder 2
Establezca una excepción para el parámetro 102: el número de solicitudes por segundo no debe exceder 4
Establezca una excepción para el parámetro 103: el número de solicitudes por segundo no debe exceder las 10

Nota : el límite actual del parámetro de punto de acceso no es válido para el recurso SpringMVC predeterminado, debe usar la anotación @SentinelResource para marcar el recurso

1) Etiquetar recursos

Agregue anotaciones al recurso /order/{orderId} en OrderController en order-service:

2) Reglas de limitación actuales para parámetros de puntos de acceso

Visite esta interfaz, puede ver que aparecen los recursos calientes que marcamos:

No haga clic en el botón detrás de caliente aquí, la página tiene un ERROR

Haga clic en el menú Reglas de Hotspot en el menú de la izquierda:

Haga clic en Agregar y complete el formulario:

3) prueba Jmeter

Seleccione "Límite de corriente del parámetro de punto de acceso QPS1":

El QPS de la solicitud aquí es 5.

Contiene 3 solicitudes http:

Parámetro común, el umbral QPS es 2

resultado de la operación:

Excepciones, el umbral de QPS es 4

resultado de la operación:

Excepciones, el umbral de QPS es 10

resultado de la operación:

3. Aislamiento y desescalada

La limitación de corriente es una medida preventiva, aunque la limitación de corriente puede tratar de evitar fallas en el servicio causadas por una alta concurrencia, los servicios también pueden fallar debido a otras razones.

Para controlar estas fallas dentro de un cierto rango y evitar avalanchas, es necesario confiar en el aislamiento de subprocesos (modo de pared) y métodos de degradación de fusibles .

El aislamiento de subprocesos se ha mencionado anteriormente: cuando la persona que llama llama al proveedor de servicios, asigna un grupo de subprocesos independiente para cada solicitud de llamada. Cuando ocurre una falla, como máximo se consumen los recursos en este grupo de subprocesos para evitar agotar todos los recursos de la persona que llama. .

Fusible de degradación : es agregar un disyuntor en el lado de la persona que llama para contar las llamadas al proveedor de servicios.Si la tasa de falla de la llamada es demasiado alta, el servicio se quemará y no se permitirá el acceso al proveedor de servicios.

Se puede ver que ya sea aislamiento de subprocesos o degradación de fusibles, es la protección del cliente (persona que llama). Es necesario realizar el aislamiento de subprocesos o la fusión de servicios cuando la persona que llama inicia una llamada remota.

Y todas nuestras llamadas remotas de microservicio se basan en Feign, por lo que debemos integrar Feign con Sentinel e implementar el aislamiento de subprocesos y el fusible de servicio en Feign.

3.1.FeignClient integra Sentinel

En Spring Cloud, todas las llamadas de microservicio se implementan a través de Feign, por lo que Feign y Sentinel deben estar integrados para la protección del cliente.

3.1.1 Modificar la configuración y habilitar la función centinela

Modifique el archivo application.yml de OrderService para habilitar la función Sentinel de Feign:

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持

3.1.2 Lógica de downgrade de error de escritura

Después de una falla comercial, no se puede informar un error directamente, pero se debe devolver al usuario un mensaje amistoso o un resultado predeterminado. Esta es la lógica de degradación de falla.

Escriba la lógica de degradación para FeignClient después de una falla

① Método 1: FallbackClass, incapaz de manejar excepciones de llamadas remotas

②Método 2: FallbackFactory, que puede manejar la excepción de las llamadas remotas, elegimos este

Aquí demostramos el procesamiento de degradación de fallas del segundo método.

Paso 1 : Defina clases en el proyecto feed-api para implementar FallbackFactory:

código:

package cn.itcast.feign.clients.fallback;

import cn.itcast.feign.clients.UserClient;
import cn.itcast.feign.pojo.User;
import feign.hystrix.FallbackFactory;
import lombok.extern.slf4j.Slf4j;

@Slf4j
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
    @Override
    public UserClient create(Throwable throwable) {
        return new UserClient() {
            @Override
            public User findById(Long id) {
                log.error("查询用户异常", throwable);
                return new User();
            }
        };
    }
}

Paso 2 : Registre UserClientFallbackFactory como Bean en la clase DefaultFeignConfiguration en el proyecto de alimentación-api:

@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
    return new UserClientFallbackFactory();
}

Paso 3 : use UserClientFallbackFactory en la interfaz de UserClient en el proyecto de alimentación-api:

import cn.itcast.feign.clients.fallback.UserClientFallbackFactory;
import cn.itcast.feign.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {

    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

Después de reiniciar, visite el servicio de consulta de pedidos una vez y luego verifique la consola centinela, puede ver el nuevo enlace del punto de clúster:

3.1.3 Resumen

Soluciones Avalanche compatibles con Sentinel:

Aislamiento de hilos (modo de pared de silo)
disyuntor de degradación

Pasos para que Fingir integre Sentinel:

Configurar en application.yml: fingir.sentienl.enable=true
Escriba un FallbackFactory para FeignClient y regístrelo como Bean
Configurar FallbackFactory para FeignClient

3.2 Aislamiento de hilos (modo de pared)

3.2.1 Implementación del aislamiento de subprocesos

El aislamiento de subprocesos se puede lograr de dos maneras:

aislamiento del grupo de subprocesos
Aislamiento de semáforo (Sentinel lo usa por defecto)

Como se muestra en la imagen:

Aislamiento del grupo de subprocesos : asigne un grupo de subprocesos a cada negocio de llamada de servicio y use el propio grupo de subprocesos para lograr el efecto de aislamiento

Aislamiento de semáforos : en lugar de crear un grupo de subprocesos, utiliza un modo de contador para registrar la cantidad de subprocesos utilizados por la empresa. Cuando se alcanza el límite superior del semáforo, se prohíben nuevas solicitudes.

Pros y contras de ambos:

3.2.2 Aislamiento de subprocesos de centinela

Instrucciones de uso :

Al agregar una regla de limitación, puede elegir dos tipos de umbral:

QPS: Es la cantidad de solicitudes por segundo, que se ha demostrado en el inicio rápido
Número de subprocesos: Es el número máximo de subprocesos de tomcat que puede utilizar este recurso. Es decir, al limitar el número de subprocesos, se logra el aislamiento de subprocesos (modo bulkwall).

Requisitos del caso : establezca reglas de control de flujo para la interfaz de usuario de consulta de UserClient en el servicio de servicio de pedidos, y la cantidad de subprocesos no puede exceder 2. Luego use jemeter para probar.

1) Configurar reglas de aislamiento

Seleccione el botón de control de flujo detrás de la interfaz fingir:

Rellenar el formulario:

2) prueba Jmeter

Seleccione "Tipo de umbral - Número de subprocesos < 2":

Si se producen 10 solicitudes a la vez, existe una alta probabilidad de que la cantidad de subprocesos simultáneos supere los 2, y las solicitudes en exceso seguirán la lógica de degradación de errores definida anteriormente.

Compruebe los resultados de la ejecución:

Se encuentra que aunque todos los resultados se pasan, la respuesta a algunas solicitudes es la información nula devuelta por la degradación.

3.2.3 Resumen

¿Cuáles son los dos medios de aislamiento de subprocesos?

Aislamiento de semáforo
aislamiento del grupo de subprocesos

¿Cuáles son las características del aislamiento del semáforo?

Basado en el modo de contador, sobrecarga simple y baja

¿Cuáles son las características del aislamiento del grupo de subprocesos?

Según el modo de grupo de subprocesos, hay una sobrecarga adicional, pero el control de aislamiento es más fuerte

3.3 Rebaja de fusibles

La degradación del fusible es un medio importante para resolver el problema de las avalanchas. La idea es que el disyuntor cuente la proporción anormal de llamadas de servicio y la proporción de solicitudes lentas, y si se supera el umbral, el servicio se interrumpirá . Es decir, todas las solicitudes de acceso al servicio son interceptadas y cuando se restablece el servicio, el disyuntor liberará la solicitud de acceso al servicio.

La fusión y liberación del control del interruptor automático se realiza a través de la máquina de estado:

La máquina de estados consta de tres estados:

cerrado: estado cerrado, el disyuntor libera todas las solicitudes y comienza a contar la proporción de excepciones y solicitudes lentas. Si se supera el umbral, cambie al estado abierto
abierto: en el estado abierto, la llamada de servicio se interrumpe y la solicitud para acceder al servicio interrumpido se rechazará, fallará rápidamente e irá directamente a la lógica de degradación. Después de 5 segundos en el estado abierto, entrará en el estado semiabierto
semiabierto: en el estado semiabierto, se libera una solicitud y la siguiente operación se juzga de acuerdo con el resultado de la ejecución.
- La solicitud es exitosa: cambiar al estado cerrado
- Solicitud fallida: cambiar a estado abierto

Hay tres tipos de estrategias de fusión de interruptores automáticos: llamada lenta, relación anormal, número anormal

3.3.1 Llamadas lentas

Llamada lenta : una solicitud cuyo tiempo de respuesta del servicio (RT) es más largo que el tiempo especificado se considera una solicitud de llamada lenta. Dentro del tiempo especificado, si el número de solicitudes excede el número mínimo establecido y la proporción de llamadas lentas es mayor que el umbral establecido, se activará un interruptor de circuito.

Por ejemplo:

Interpretación: Las llamadas con un RT de más de 500 ms son llamadas lentas. Cuente las solicitudes dentro de los últimos 10 000 ms. Si el número de solicitudes supera 10 y la proporción de llamadas lentas no es inferior a 0,5, se activará un disyuntor y el disyuntor durará 5 segundos. Luego ingrese al estado semiabierto y libere una solicitud de prueba.

el caso

Requisitos: Establezca reglas de degradación para la interfaz de usuario de consulta de UserClient. El umbral de RT para llamadas lentas es de 50 ms, el tiempo de estadísticas es de 1 segundo, el número mínimo de solicitudes es 5, la tasa de umbral de falla es 0.4 y la duración del fusible es 5

1) Establecer llamadas lentas

Modifique el servicio de la interfaz /user/{id} en user-service. Simule un tiempo de retraso durmiendo:

En este punto, el pedido con orderId=101 se asocia con el usuario cuyo id es 1 y el tiempo de llamada es de 60 ms:

El pedido con orderId=102 está asociado con el usuario cuyo id es 2, y el tiempo de llamada es muy corto;

2) Establecer reglas de fusibles

A continuación, establezca las reglas de degradación para la interfaz de fingir:

regla:

Las solicitudes que superan los 50 ms se consideran solicitudes lentas

3) prueba

Visite en el navegador: http://localhost:8088/order/101 , actualice rápidamente 5 veces, puede encontrar:

Se activó el disyuntor, la duración de la solicitud se acortó a 5 ms, falló rápidamente, se siguió la lógica degradada y se devolvió nulo

Acceso en el navegador: http://localhost:8088/order/102 , también se arruinó:

3.3.2 Relación anormal, número anormal

Proporción anormal o número anormal : cuente las llamadas dentro de un período de tiempo específico. Si el número de llamadas excede el número especificado de solicitudes y la proporción de anomalías alcanza el umbral de proporción establecido (o excede el número anormal especificado), se activará un disyuntor. motivado.

Por ejemplo, una configuración de escala inusual:

Interpretación: cuente las solicitudes dentro de los últimos 1000 ms. Si el número de solicitudes excede 10 y el índice de anormalidad no es menor a 0.4, se activará un interruptor de circuito.

Una configuración de número de excepción:

Interpretación: cuente las solicitudes dentro de los últimos 1000 ms. Si el volumen de la solicitud supera las 10 veces y la relación anormal no es inferior a 2 veces, se activará un interruptor automático.

el caso

Requisitos: establezca reglas de degradación para la interfaz de usuario de consulta de UserClient, el tiempo de estadísticas es de 1 segundo, la cantidad mínima de solicitudes es 5, la tasa de umbral de falla es 0.4 y la duración del fusible es 5 s

1) Establecer solicitud de excepción

Primero, modifique el negocio de la interfaz /user/{id} en user-service. Ejecute manualmente una excepción para activar un disyuntor con una relación anormal:

En otras palabras, cuando la identificación es 2, se activará una excepción.

2) Establecer reglas de fusibles

A continuación, establezca las reglas de degradación para la interfaz de fingir:

regla:

En 5 solicitudes, siempre que la tasa de excepción supere 0,4, es decir, haya más de 2 excepciones, se disparará el interruptor automático.

3) prueba

Visite rápidamente en el navegador: http://localhost:8088/order/102 , actualice 5 veces rápidamente y active el disyuntor:

En este punto, pasamos a la visita 103, que debería ser normal:

4. Reglas de autorización

Las reglas de autorización pueden juzgar y controlar la fuente del solicitante.

4.1 Normas de autorización

4.1.1 Reglas básicas

Las reglas de autorización pueden controlar la fuente de la persona que llama, y hay dos formas: lista blanca y lista negra.

Lista blanca: las personas que llaman cuyo origen está en la lista blanca pueden acceder
Lista negra: las personas que llaman cuyo origen está en la lista negra no pueden acceder

Haga clic en Autorización en el menú de la izquierda para ver las reglas de autorización:

Nombre del recurso: es el recurso protegido, como /order/{orderId}
Aplicación de control de flujo: es la lista de fuentes,
- Si la lista blanca está marcada, las fuentes de la lista pueden acceder.
- Si la lista negra está marcada, se prohíbe el acceso a las fuentes de la lista.

Por ejemplo:

Permitimos solicitudes desde la puerta de enlace al servicio de pedidos, y no permitimos que los navegadores accedan al servicio de pedidos, por lo que el nombre de la fuente (origen) de la puerta de enlace debe completarse en la lista blanca .

4.1.2 Cómo obtener el origen

Sentinel obtiene el origen de la solicitud a través del parseOrigin de la interfaz RequestOriginParser.

public interface RequestOriginParser {
    /**
     * 从请求request对象中获取origin，获取方式自定义
     */
    String parseOrigin(HttpServletRequest request);
}

La función de este método es obtener el valor de origen del solicitante del objeto de solicitud y devolverlo.

De manera predeterminada, sin importar de dónde provenga el solicitante, Sentinel siempre devolverá el valor predeterminado, lo que significa que la fuente de todas las solicitudes se considera que tiene el mismo valor predeterminado.

Por lo tanto, necesitamos personalizar la implementación de esta interfaz para que diferentes solicitudes puedan devolver diferentes orígenes .

Por ejemplo, en el servicio de servicio de pedidos, definimos una clase de implementación de RequestOriginParser:

package cn.itcast.order.sentinel;

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser;
import org.springframework.stereotype.Component;
import org.springframework.util.StringUtils;

import javax.servlet.http.HttpServletRequest;

@Component
public class HeaderOriginParser implements RequestOriginParser {
    @Override
    public String parseOrigin(HttpServletRequest request) {
        // 1.获取请求头
        String origin = request.getHeader("origin");
        // 2.非空判断
        if (StringUtils.isEmpty(origin)) {
            origin = "blank";
        }
        return origin;
    }
}

Intentaremos obtener el valor de origen del encabezado de solicitud.

4.1.3 Agregar un encabezado de solicitud a la puerta de enlace

Dado que la forma de obtener el origen de la solicitud es obtener el valor de origen del encabezado de solicitudes, debemos hacer que todas las solicitudes enrutadas desde la puerta de enlace al microservicio tengan el encabezado de origen .

Esto debe realizarse mediante el uso de un GatewayFilter aprendido anteriormente, AddRequestHeaderGatewayFilter.

Modifique application.yml en el servicio de puerta de enlace y agregue un filtro predeterminado:

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway
      routes:
       # ...略

De esta manera, todas las solicitudes enrutadas desde la puerta de enlace llevarán el encabezado de origen con la puerta de enlace de valor. Las solicitudes que llegan al microservicio desde otro lugar no tienen este encabezado.

4.1.4 Configurar reglas de autorización

A continuación, agregamos una regla de autorización para permitir solicitudes cuyo valor de origen sea puerta de enlace.

La configuración es la siguiente:

Ahora, nos saltamos la pasarela directamente y accedemos al servicio de atención de pedidos:

Acceso a través de la pasarela:

4.2 Resultados de excepción personalizados

De forma predeterminada, cuando se produce una limitación actual, una degradación o una intercepción de autorización, se lanzará una excepción a la persona que llama. Los resultados anormales son limitación de flujo (limitación de corriente). Esto no es lo suficientemente amigable y es imposible saber si se trata de una limitación actual, una degradación o una intercepción autorizada.

4.2.1 Tipos de excepción

Y si desea personalizar el resultado de retorno cuando ocurre una excepción, debe implementar la interfaz BlockExceptionHandler:

public interface BlockExceptionHandler {
    /**
     * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException
     */
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

Este método tiene tres parámetros:

HttpServletRequest solicitud：request对象
HttpServletResponse respuesta：respuesta对象
BlockException e: la excepción lanzada cuando es interceptada por centinela

BlockException aquí contiene varias subclases diferentes:

anormal	ilustrar
excepción de flujo	Excepción de límite actual
ParamFlowException	Límite de corriente de parámetro de punto de acceso anormal
DegradeException	excepción de degradación
Excepción de autoridad	Excepción de la regla de autorización
SystemBlockException	Excepción de la regla del sistema

4.2.2 Manejo de excepciones personalizado

A continuación, definimos una clase de manejo de excepciones personalizada en el servicio de pedidos:

package cn.itcast.order.sentinel;

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.BlockExceptionHandler;
import com.alibaba.csp.sentinel.slots.block.BlockException;
import com.alibaba.csp.sentinel.slots.block.authority.AuthorityException;
import com.alibaba.csp.sentinel.slots.block.degrade.DegradeException;
import com.alibaba.csp.sentinel.slots.block.flow.FlowException;
import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException;
import org.springframework.stereotype.Component;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
        String msg = "未知异常";
        int status = 429;

        if (e instanceof FlowException) {
            msg = "请求被限流了";
        } else if (e instanceof ParamFlowException) {
            msg = "请求被热点参数限流";
        } else if (e instanceof DegradeException) {
            msg = "请求被降级了";
        } else if (e instanceof AuthorityException) {
            msg = "没有权限访问";
            status = 401;
        }

        response.setContentType("application/json;charset=utf-8");
        response.setStatus(status);
        response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
    }
}

Reinicie la prueba y, en diferentes escenarios, se devolverán diferentes mensajes de excepción.

Limitando:

Al autorizar la interceptación:

5. Persistencia de la regla

Ahora, todas las reglas de Sentinel se almacenan en la memoria y todas las reglas se perderán después de reiniciar. En un entorno de producción, debemos asegurar la persistencia de estas reglas para evitar pérdidas.

5.1 Modo de gestión de reglas

La persistencia de las reglas depende del modo de administración de reglas. Sentinel admite tres modos de administración de reglas:

Modo original: el modo predeterminado de Sentinel, las reglas se guardan en la memoria y el servicio se perderá después de reiniciar el servicio.
modo de extracción
modo de empuje

5.1.1 Modo tirar

Modo de extracción: la consola envía las reglas configuradas al cliente Sentinel y el cliente guarda las reglas configuradas en un archivo o base de datos local. En el futuro, consultaremos regularmente archivos o bases de datos locales para actualizar las reglas locales.

5.1.2 Modo de pulsación

Modo push: la consola envía las reglas de configuración a un centro de configuración remoto, como Nacos. El cliente Sentinel monitorea Nacos, obtiene mensajes push de cambios de configuración y completa actualizaciones de configuración locales.

5.2 Realizar el modo push

1. Modificar el servicio de servicio de pedidos

Modifique OrderService para escuchar la configuración de la regla centinela en Nacos.

Los pasos específicos son los siguientes:

1. Introducir dependencias

Introducir centinela para monitorear las dependencias de nacos en el servicio de pedidos:

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

2. Configurar la dirección de nacos

Configure la dirección de nacos y la información de configuración del monitor en el archivo application.yml en order-service:

spring:
  cloud:
    sentinel:
      datasource:
        flow:
          nacos:
            server-addr: localhost:8848 # nacos地址
            dataId: orderservice-flow-rules
            groupId: SENTINEL_GROUP
            rule-type: flow # 还可以是：degrade、authority、param-flow

Conociendo a Sentinel

1. Hay 4 formas de solucionar la avalancha:

1.1.2 Procesamiento de tiempo de espera:

1.1.3 Modo de pared de almacén

1.1.4 Disyuntor

1.1.5 Limitación de corriente

1.1.6 Resumen

1.2 Comparación de tecnologías de protección de servicios

1.3.Introducción e instalación de Sentinelp

1.3.1 Conociendo a Sentinel

1.3.2 Instalar Sentinel

1.4 Integración de microservicios Sentinel

2. Control de flujo

2.1 Enlace de clúster

2.1 Inicio rápido

2.1.1 Ejemplos

2.1.2 Práctica:

2.2 Modo de control de flujo

2.2.1 Modo de asociación

2.2.2 Modo enlace

1) Agregar un método de producto de consulta

2) Al consultar sobre un pedido, consultar sobre el producto

3) Agregar nuevos pedidos y consultar productos

4) Agregue una etiqueta de recurso al producto de consulta

5) Agregar reglas de control de flujo

6) prueba Jmeter

2.2.3 Resumen

2.3 Efecto de control de flujo

2.3.1.calentamiento

1) Configurar reglas de control de flujo:

2) prueba Jmeter

2.3.2 Esperando en la fila

2.3.3 Resumen

2.4 Límite actual de los parámetros del punto de acceso

2.4.1 Limitación de corriente de parámetros globales

2.4.2 Límite actual de los parámetros del punto de acceso

1) Etiquetar recursos

2) Reglas de limitación actuales para parámetros de puntos de acceso

3. Aislamiento y desescalada

3.1.FeignClient integra Sentinel

3.1.1 Modificar la configuración y habilitar la función centinela

3.1.2 Lógica de downgrade de error de escritura

3.1.3 Resumen

3.2 Aislamiento de hilos (modo de pared)

3.2.1 Implementación del aislamiento de subprocesos

3.2.2 Aislamiento de subprocesos de centinela

1) Configurar reglas de aislamiento

2) prueba Jmeter

3.2.3 Resumen

3.3 Rebaja de fusibles

3.3.1 Llamadas lentas

1) Establecer llamadas lentas

2) Establecer reglas de fusibles

3) prueba

3.3.2 Relación anormal, número anormal

2) Establecer reglas de fusibles

3) prueba

4. Reglas de autorización

4.1 Normas de autorización

4.1.1 Reglas básicas

4.1.2 Cómo obtener el origen

4.1.3 Agregar un encabezado de solicitud a la puerta de enlace

4.1.4 Configurar reglas de autorización

4.2 Resultados de excepción personalizados

4.2.1 Tipos de excepción

4.2.2 Manejo de excepciones personalizado

5. Persistencia de la regla

5.1 Modo de gestión de reglas

5.1.1 Modo tirar

5.1.2 Modo de pulsación

5.2 Realizar el modo push

1. Modificar el servicio de servicio de pedidos

1. Introducir dependencias

2. Configurar la dirección de nacos

Supongo que te gusta