1. Aislamiento y degradación

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 .

Aislamiento de subprocesos : al llamar al proveedor de servicios, la persona que llama 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.

1.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.

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的支持

Lógica de degradación 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:
@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 feed-api:
@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
    return new UserClientFallbackFactory();
}
Paso 3 : use UserClientFallbackFactory en la interfaz de UserClient en el proyecto de alimentación-api:
@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:

Resumir

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

1.2 Aislamiento de hilos (modo de pared)

Implementación de 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:

aislamiento de hilo 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":

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.

Resumir

¿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

1.3, degradación 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

1.3.1, llamada lenta

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 llamada lenta

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:

2) Establecer reglas de fusibles

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

Las solicitudes que superan los 50 ms se consideran solicitudes lentas

3) prueba

Visite en el navegador: http://localhost:8088/order/101 , actualice 5 veces rápidamente, 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ó:

1.3.2 Relación anormal y 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 la relación de anomalías no es inferior a 0,4, se activará un interruptor automático.

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

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

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:

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:

2. Reglas de autorización

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

2.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 .

2.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:

@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.

2.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.

2.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:

2.5 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.

tipo 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

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

Manejo de excepciones personalizado

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

@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:

3. Persistencia de reglas

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.

3.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

modo de extracción

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.

modo de empuje

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.

3.2 Realice el modo push

modificar artículo

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

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

Modificar el código fuente de Sentinel-Dashboard

SentinelDashboard no es compatible con la persistencia de nacos de forma predeterminada y es necesario modificar el código fuente.

Abra el paquete fuente de Sentinel con IDEA

1. Modificar las dependencias de nacos

En el archivo pom del código fuente de sentinel-dashboard, nacos depende del alcance predeterminado de la prueba, que solo se puede usar durante la prueba. Aquí debe eliminarse:

Elimine el alcance del que depende sentinel-datasource-nacos:
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
2. Añadir soporte nacos

Bajo el paquete de prueba de sentinel-dashboard, se ha escrito soporte para nacos, y necesitamos copiarlo a main.

3. Modificar dirección nacos

Luego, también debe modificar la clase NacosConfig en el código de prueba:

Modifique la dirección de nacos y deje que lea la configuración en application.properties:

Agregue la configuración de dirección de nacos en application.properties de sentinel-dashboard:
nacos.addr=localhost:8848
4. Configurar la fuente de datos de nacos

Además, debe modificar la clase FlowControllerV2 en el paquete com.alibaba.csp.sentinel.dashboard.controller.v2:

Deje que la fuente de datos de Nacos que agregamos surta efecto

5. Modificar la página de inicio

A continuación, modifique la página de inicio y agregue un menú que admita nacos.

Modifique el archivo sidebar.html en el directorio src/main/webapp/resources/app/scripts/directives/sidebar/:

Activa esta parte del comentario:

Modifique el texto en él:

6. Recompilar y empaquetar el proyecto

Ejecute el complemento maven en IDEA, compile y empaquete el Sentinel-Dashboard modificado:

7. Inicio

El método de inicio es el mismo que el oficial:
java -jar sentinel-dashboard.jar
Si desea modificar la dirección de nacos, debe agregar parámetros:
java -jar -Dnacos.addr=localhost:8848 sentinel-dashboard.jar