Capítulo avanzado de microservicios [1] Protección de microservicios

prefacio

• Este artículo se aprendió de un programador de caballos oscuros, ¡y la mayor parte del contenido proviene del curso de microservicios! ! !
• La importancia de este artículo radica en los registros de aprendizaje. Aunque los documentos de aprendizaje de Dark Horse son muy detallados, debido a que los cursos no siempre pueden estar actualizados, existen ciertas diferencias en las versiones de las herramientas y el contenido que se utilizan para el aprendizaje. !
• ¡Este artículo se basa en el tutorial de Dark Horse y registrará y complementará los detalles para los estudiantes posteriores! ! !
• Hay deficiencias en el artículo, ¡gracias por tus correcciones! ! !
• ¡En la segunda mitad del artículo, el editor no repetirá la parte sobre la operación real! ! ! Para la parte operativa, ¡asegúrate de ensuciarte las manos! ! !

Centinela por primera vez

1.1 Problema de avalancha

• En los microservicios, la relación de llamadas entre los servicios es compleja y un microservicio a menudo depende de muchos otros microservicios.
  

• Como se muestra en la figura, si el proveedor de servicios I falla, parte del negocio de la aplicación actual también se bloqueará porque depende del servicio I. En este momento, otros servicios que no dependen del Servicio I parecen no verse afectados.
  

• Sin embargo, la solicitud comercial que depende del servicio I está bloqueada y el usuario no obtendrá una respuesta, por lo que el subproceso de Tomcat no se liberará, por lo que llegan cada vez más solicitudes de usuarios y se bloquearán cada vez más subprocesos:
  

• El número de subprocesos y la concurrencia admitidos por el servidor son limitados. Si la solicitud está bloqueada todo el tiempo, los recursos del servidor se agotarán y todos los demás servicios no estarán disponibles, por lo que el servicio actual tampoco estará disponible. Luego, otros servicios que dependen del servicio actual eventualmente dejarán de estar disponibles con el tiempo, formando fallas en cascada y se produce una avalancha.

• Una falla de servicio en el enlace de llamada de microservicio hace que todos los microservicios en todo el enlace no estén disponibles, lo que es una avalancha.
  

1.2 Soluciones

• Hay cuatro formas comunes de resolver el problema de las avalanchas:
  • Procesamiento de tiempo de espera : configure el período de 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
  • Bulkhead mode : Limita la cantidad de hilos que puede usar cada negocio para evitar agotar los recursos de todo el tomcat, por lo que también se le llama aislamiento de hilos.
  • Degradación del fusible : 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.
  • 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. Procesamiento de tiempo de espera
   • Establezca el período de 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
     

---

2. modo silo
   • El modo de pared de la cabina proviene del diseño de la cabina: la cabina estará separada en múltiples espacios independientes por particiones. Cuando el casco está dañado, solo entrará una parte del espacio, y la falla se controlará dentro de un cierto rango para evitar todo el casco se sumerja.
   • Limite la cantidad de subprocesos que cada empresa puede usar para evitar agotar los recursos de todo el tomcat, por lo que también se denomina aislamiento de subprocesos.
     

---

3. interruptor automático
   • 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 para acceder a un determinado servicio y la relación anormal.Cuando la relación anormal de solicitudes para acceder al servicio D se encuentra demasiado alta, cree que el servicio D tiene el riesgo de causar una avalancha, y interceptará todas las solicitudes de acceso al servicio D para formar un disyuntor.
     

---

4. control de flujo
   • QPS que restringe el acceso comercial para evitar fallas en el servicio debido a picos de tráfico.
     

1.3 Resumen

• Problema de avalancha: los microservicios se llaman entre sí, porque una falla en el servicio en la cadena de llamadas hace que todo el enlace sea inaccesible.
• 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.4 Comparación de tecnologías de protección de servicios

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

• netfix hystrix
• Centinela
• Resiliencia4J

El framework Hystrix fue más popular en los primeros días, pero actualmente 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.5 Introducción 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
• 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 Llenado de valles, control de flujo de grupos, 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.6 Instalación de centinela

1. Selección de la versión de Sentinel:
   • Si el JDK que está usando es 1.8, puede usar el paquete jar en los datos
   • Si su JDK es más nuevo, vaya a GitHub para descargar la última versión. ! !
2. correr
   • Coloque el paquete jar en cualquier directorio que no sea chino y ejecute el comando:

   java -jar sentinel-dashboard-x.x.x.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-x.x.x.jar
  

3. acceso
   • Visite la página http://localhost:8080, puede ver la consola centinela
   • 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: porque no se ha integrado con microservicios
     

1.7 Centinela de integración de microservicios

• Para integrar Sentinel en el proyecto de microservicio y conectarse 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. consola de configuración
   • Modifique el archivo application.yaml y agregue el siguiente contenido

   server:
     port: 8088
   spring:
     cloud: 
       sentinel:
         transport:
           dashboard: localhost:8080 #连接到sentinel 如果你的sentinel是在linux中启动的，请修改为linux的IP
   

3. Acceda a cualquier punto final de un proyecto de microservicio
   • Abra el navegador y visite http://localhost:8088/order/101, para activar el monitoreo de Sentinel.
   • Luego visita la consola centinela para ver el efecto.
     

---

• Para las pruebas de seguimiento, la herramienta de prueba utilizada es Jmeter, así que aprenda la siguiente instalación y uso de Jmeter

Dos herramientas de prueba: Jmeter

• Jmeter depende de JDK, por lo que debe asegurarse de que JDK esté instalado en la computadora actual y que las variables de entorno estén configuradas

2.1 Instalación y configuración de Jmeter

1. Se puede descargar desde el sitio web oficial de Apache Jmeter, dirección
   
2. abrir la cremallera
   
   • El directorio bin es el script ejecutado, que contiene el script de inicio:
3. Haga doble clic para ejecutar, pero hay dos puntos a tener en cuenta:
   • La velocidad de inicio es relativamente lenta, así que tenga paciencia
   • La ventana negra no se puede cerrar después del inicio, de lo contrario, Jmeter también se cerrará
     

2.2 Inicio rápido de JMeter

2.2.1 Establecer idioma chino

- 方式一：永久中文，打开jmeter文件夹，在bin目录中找到 **jmeter.properties**，添加下面配置：
- **注意：前面不要出现#，#代表注释，另外这里是下划线，不是中划线**

- Método 2: Configuración temporal, seleccione Pociones->Elegir idioma->Inglés en la interfaz gráfica

2.2.2 Establecer el icono de acceso directo del escritorio de Jmeter

1. Para el directorio bin del archivo jmeter—>archivo jmeter.bat, haga clic con el botón derecho para crear un acceso directo en el escritorio
   
2. Modificar propiedades de acceso directo
   
3. Crear icono de acceso directo de jmeter
   • Ingrese apache-jmeter-5.5\docs\imagesal directorio, elija un icono adecuado y luego abra el sitio web del icono ICO transparente de generación en línea
   • Cargue una imagen, cree un ícono ico y colóquelo en apache-jmeter-5.5\docs\imagesel directorio
   • Finalmente, haga clic derecho en el acceso directo en el escritorio, modifique propiedades->cambiar icono->busque apache-jmeter-5.5\docs\imagesel directorio y seleccione el archivo de icono ico
     

2.3 El problema de que Jmeter no puede guardar la prueba

1. Establezca la apariencia de la ventana en jmeter5.4.1 y reinícielo para resolverlo
2. No existe tal problema en el último jmeter5.5, se recomienda que pruebe la última versión
   • El plan de prueba se puede guardar normalmente en el estilo predeterminado de Darcula
     

2.4 Uso básico de jmeter

• Haga clic con el botón derecho en el plan de prueba y seleccione Agregar > Subproceso (Usuario) > Grupo de subprocesos:
  
• En el grupo de hilos recién agregado, complete la información del hilo:
  
• Haga clic derecho en el grupo de subprocesos y agregue una muestra http:
  
• Escribir contenido de muestra:
  
• Añadir informe de seguimiento:
  
• Agregar árbol de resultados de monitoreo:
  
• Resultados del informe resumido:
  
• árbol de resultados resultado
  

Control de tres flujos

3.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 final en OrderController en el servicio de pedidos que acaba 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

3.2 Inicio rápido

1. Haga clic en el botón de control de flujo detrás de resource/order/{orderId} para abrir el formulario
   
2. Las reglas de limitación se pueden completar en el formulario
   
3. prueba con jmeter
   
   

• Nota: No haga clic en el botón Ejecutar en el menú para ejecutar

4. Resultados de la
   

3.3 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

• 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

• Tenga en cuenta que después de reiniciar el servicio, recuerde visitarlo una vez antes de que Sentinel pueda mostrar el enlace del punto de clúster
  
  

• Reinicie el servicio y vea el enlace del clúster de la consola Sentinel:
  
• Configurar reglas de control de flujo
  
  
• Prueba en Jmeter
  
  • 1000 usuarios, 100 segundos, por lo que el QPS es 10, lo que supera el umbral que establecimos: 5
  • Ver solicitud http:
    
• El objetivo de la solicitud es /order/update, por lo que este punto de interrupción activará el umbral, pero el objetivo del límite actual es /order/query
  
• El modo de asociación se puede utilizar si se cumplen las siguientes condiciones:
  • dos recursos en competencia
  • Uno con mayor prioridad y otro con menor prioridad

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

1. Por ejemplo: establezca dos enlaces para acceder al mismo recurso
   
2. Agregar reglas de control de flujo
   
3. Prueba Jmeter
   
   • Una solicitud http es para acceder a /order/save:
     
   • El resultado de la operación: completamente inafectado.
     
   • La otra es acceder a /pedir/consultar:
     
   • Resultado de ejecución: solo 2 pasadas cada vez
     

3.5 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

3.5.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.
  
• Configurar reglas de control de flujo
  
• Prueba Jmeter
  
• Consola Sentinel para ver el monitoreo en tiempo real:
  

3.5.2 Esperando en la fila

• Poner en cola 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:
  
• Explicación de la animación:
  
• Agregar reglas de control de flujo
  
• Resultados de la prueba de la prueba Jmeter
  
  • 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.

3.6 Limitación de corriente de los parámetros del punto de acceso

• La limitación actual del parámetro Hotspot consiste en contar las solicitudes con el mismo valor de parámetro por separado para determinar si supera el umbral de QPS.

3.6.1 Límite de corriente de parámetro global

• En la solicitud para acceder a /bienes/{id}, el valor del parámetro id cambiará, y el límite actual del parámetro del punto de acceso contará los QPS respectivamente de acuerdo con el valor del parámetro. El resultado estadístico: cuando se activa la solicitud con id=1 el umbral para ser limitado, el valor de identificación no es 1, las solicitudes no se ven afectadas.
  
• Ejemplo de configuración:
  • Realice 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
    

3.6.2 Limitación actual de los parámetros del punto de acceso

• 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 más alto. Luego, debe configurar las opciones avanzadas del límite actual del parámetro del punto de acceso
  

4 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 la 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 degradado : agregue un disyuntor en el lado de la persona que llama para contar las llamadas al proveedor de servicios. Si la tasa de fallas de la llamada es demasiado alta, el servicio se interrumpirá y no se permitirá el acceso al proveedor de servicios.
  

• Ya sea que se trate de aislamiento de subprocesos o de 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.

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

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

4.1.2 Lógica de degradación de errores 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, no puede manejar excepciones de llamadas remotas
  ② Método 2: FallbackFactory, puede manejar excepciones de llamadas remotas [Adoptado]

• Aquí hay una demostración del 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:
  

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

4.2 Aislamiento de hilos (modo de mamparo)

4.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)
    
• 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:
  

4.2.2 Aislamiento de subprocesos de centinela

• Al agregar una regla de limitación, puede elegir dos tipos de umbral:
  
• QPS: el número de solicitudes por segundo
• Número de subprocesos: el número máximo de subprocesos Tomcat que puede utilizar este recurso. Es decir, al limitar el número de subprocesos, se logra el aislamiento de subprocesos (modo bulkwall)

4.3 Degradación del fusible

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

• A continuación se muestra el diagrama de ejecución del interruptor automático:
  
  la máquina de estado incluye 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.
  - Si la solicitud tiene éxito: cambia al estado cerrado
  - Si la solicitud falla: cambia al estado abierto

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

4.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.
• manifestación
  
  • 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 de 5, la tasa de umbral de falla es de 0,4 y la duración del interruptor de circuito es de 5. Las solicitudes que superan los 50 ms se consideran solicitudes lentas.

4.3.2 Proporció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 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.

Cinco reglas de autorización

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

5.1 Reglas de autorización

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

• Demostración: [omitir operaciones de microservicios]
  

  • Solo la puerta de enlace puede acceder al servicio
    
  • error de acceso directo
    
  • Acceso a través de la pasarela:
    

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

1. tipo de excepción
   • 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 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

5.3 Manejo personalizado de excepciones

@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 + "}");
    }
}

• Intercepción de autorización:
  

Seis reglas para la persistencia

• Todas las reglas de centinela 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.

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

6.2 modo de tracció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.
  

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

6.4 Modo de empuje del implemento

6.4.1 Descargar y descomprimir el código fuente de Sentinel

• Dirección de descarga de Sentinel
  
• Luego abre el proyecto con IDEA, la estructura es la siguiente:
  

6.4.2 Modificar dependencias nacos

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

6.4.3 Añadir soporte nacos

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

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

6.4.4 Configurar fuente de datos nacos

6.4.5 Modificar la página de inicio

• Tambié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/
  

• modificar el texto en

  <li ui-sref-active="active" ng-if="entry.appType==0">
     <a ui-sref="dashboard.flow({app: entry.app})">
       <i class="glyphicon glyphicon-filter"></i>&nbsp;&nbsp;流控规则-NACOS</a>
   </li>
  

6.4.6 Recompilar y empaquetar el proyecto

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

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