Spring Cloud: Microservicios y componentes centrales de Spring Cloud

Spring Cloud: Microservicios y componentes centrales de Spring Cloud

Introducción al Marco de Microservicios

Antes de ingresar al marco de Spring Cloud, debemos aprender algunos conceptos básicos. En primer lugar, necesitamos saber qué son los microservicios y luego cómo hacemos llamadas remotas a servicios en microservicios en nuestra vida diaria.

microservicio

Introducción:

La arquitectura de microservicios es una forma o enfoque para desarrollar una sola aplicación utilizando un conjunto de pequeños servicios. Cada servicio se crea en función de una única capacidad comercial, se ejecuta en su propio proceso y se comunica mediante un mecanismo ligero, generalmente API HTTP, y puede aprobar Mecanismo de implementación automatizado para implementar de forma independiente. Estos servicios se pueden implementar utilizando diferentes lenguajes de programación, así como diferentes tecnologías de almacenamiento de datos, y mantener la gestión centralizada al mínimo.

Diagrama de estructura:

Nota: API Gateway es un servidor y la única entrada al sistema. La puerta de enlace proporciona servicios de acceso RESTful/HTTP. El servidor registra y administra los servicios a través del centro de registro de servicios.

Características:

• Responsabilidad única: cada servicio en el microservicio corresponde a una capacidad comercial única y logra una responsabilidad única.
• Orientado a servicios: Orientado a servicios significa que cada servicio debe exponer la API de interfaz de servicio al mundo exterior, y no le importa la implementación técnica del servicio, de modo que la plataforma y el lenguaje sean independientes, y no hay limitación en lo que se utiliza la tecnología para la implementación, siempre que se proporcione la interfaz REST.
• Autonomía: los servicios son independientes entre sí y no interfieren entre sí
  • Independencia del equipo: cada servicio puede ser un equipo de desarrollo independiente
  • Independencia de la tecnología: debido a que está orientada a servicios, siempre que se proporcione la interfaz REST correspondiente, qué tecnología usar no es el punto clave
  • Separación de front-end y back-end: desarrollo separado de front-end y back-end, proporcionando una interfaz REST unificada, y el back-end no necesita desarrollar diferentes interfaces para PC y dispositivos móviles
  • Separación de bases de datos: cada servicio utiliza su propia fuente de datos sin interferir entre sí

Resumir:

A través de las características de los microservicios, podemos saber que cuando un terminal accede a un proyecto de microservicio, el proyecto de microservicio coincide con la interfaz REST correspondiente a través de la puerta de enlace API, ingresa al servicio correspondiente y luego realiza la función. Cada servicio en el microservicio hace lo suyo de forma independiente. El marco de microservicio es equivalente a un agregador que integra varios servicios en un proyecto para lograr una variedad de funciones, y cada función es relativamente independiente sin interferir entre sí. No solo se ajusta a el estándar de desarrollo débilmente acoplado, pero también hace que el proyecto sea más fácil de expandir y mantener.

Método de llamada remota

En los microservicios, los servicios se conectan en su conjunto a través de llamadas remotas

Los métodos comunes de llamadas remotas son los siguientes:

• RPC: Llamada a procedimiento remoto Llamada a procedimiento remoto, similar a RMI. Formato de datos personalizado, basado en comunicación TCP nativa, rápido y eficiente. Los primeros servicios web y el popular Dubbo son típicos de RPC.
• HTTP: HTTP es en realidad un protocolo de transmisión de red, basado en TCP, que especifica el formato de transmisión de datos. Ahora, el navegador del cliente y el servidor utilizan básicamente el protocolo HTTP para la comunicación. También se puede utilizar para realizar llamadas de servicio remoto. La desventaja es que el paquete de mensajes está inflado. Ahora el popular estilo REST se puede realizar a través del protocolo HTTP.

RPC

RPC, o Remote Procedure Call (Llamada a procedimiento remoto), es un protocolo de comunicación informática. Este protocolo permite que un programa que se ejecuta en una computadora llame a una subrutina en otra computadora sin que el programador tenga que programar adicionalmente para esta interacción. En pocas palabras: la computadora A proporciona un servicio y la computadora B puede llamar al servicio de la computadora A como si llamara a un servicio local.

El diagrama de flujo de llamadas remotas de RPC es el siguiente:

Resumen:
como se puede ver en las dos figuras anteriores, en la llamada remota RPC, el cliente y el servidor serializan los datos que deben comunicarse y luego se comunican a través de la red a través del Socket, luego reciben los datos del resultado y luego regresan a través de la deserialización el resultado de.

HTTP

HTTP es en realidad un protocolo de transmisión de red, basado en TCP, que trabaja en la capa de aplicación y especifica el formato de transmisión de datos. Ahora, el navegador del cliente y el servidor utilizan básicamente el protocolo HTTP para la comunicación, y también se puede utilizar para llamadas de servicio remoto. La desventaja es que el paquete de mensajes está inflado y la ventaja es que no hay restricciones técnicas sobre el proveedor del servicio y la persona que llama, lo que es gratuito y flexible, y está más en línea con el concepto de microservicios. Ahora el popular estilo REST se puede realizar a través del protocolo HTTP.

Observación:

• Porque RPC se define según la API del lenguaje, no según la aplicación basada en la red. Entonces, cuando toda nuestra arquitectura de microservicios utiliza la misma pila de tecnología (por ejemplo, Java) para la implementación, Dubbo puede convertirse en una buena arquitectura de microservicios.
• Si la pila de tecnología utilizada no es uniforme, entonces Spring Cloud puede ser una mejor opción para construir una arquitectura de microservicio.En este momento, HTTP se usa para implementar llamadas entre servicios.

Introducción a Spring Cloud

Introducción:

Spring Cloud es uno de los proyectos de Spring, que proporciona principalmente las funciones de los microservicios.

Lo que mejor hace Spring es la integración: toma el mejor marco del mundo y lo integra en sus propios proyectos.

Lo mismo ocurre con Spring Cloud, que integra algunas tecnologías muy populares e implementa funciones como: gestión de configuración, descubrimiento de servicios, enrutamiento inteligente, equilibrio de carga, fusibles, bus de control, estado del clúster, etc.

Los principales componentes involucrados incluyen:

netflix

• Eureka: Registro
• Zuul: puerta de enlace de servicio
• Cinta: equilibrio de carga
• Fingir: llamada de servicio (proxy dinámico)
• Hystrix: Fusible

Nube de primavera

• Gateway: puerta de enlace de servicios, desarrollada por la familia Spring, integrada en el marco
• Config: centro de configuración distribuida

El diagrama de la arquitectura es el siguiente:

Versión:

Spring Cloud tiene varias versiones, y cada versión corresponde a una versión de SpringBoot diferente, por lo que cuando usamos Spring Cloud en un proyecto, debemos prestar atención a la versión de springboot correspondiente en el archivo pom.xml, para evitar errores innecesarios debido a error de desajuste de versión.

El nombre de la versión de Spring Cloud corresponde principalmente al nombre de la estación de metro de Londres en Inglaterra:

Correspondencia entre las versiones de Spring Cloud y Spring Boot:

Tren de lanzamiento	Versión de arranque
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
edgware	1.5.x
Dalston	1.5.x

Componentes principales de Spring Cloud

Hay cinco componentes principales de Spring Cloud, a saber, el centro de registro, el equilibrio de carga, el disyuntor, la puerta de enlace de servicio y el centro de configuración distribuida.Entre ellos, la puerta de enlace de servicio se presenta principalmente por Gateway en el marco de Spring Cloud como ejemplo.

Registro - Netflix Eureka

Equilibrio de carga - Cinta de Netflix

Disyuntor - Netflix Hystrix

Puerta de enlace de servicio : Spring Cloud Gateway (Netflix Zuul)

Centro de configuración distribuida - Spring Cloud Config

Además, se añaden dos componentes más importantes:

Proxy dinámico - Fingir
bus de servicio - Spring Cloud Bus

Registro Eureka

Introducción:

Cuando se inicia cada servicio, Eureka Client registrará el servicio en Eureka Server, y Eureka Client también puede extraer el registro de Eureka Server a su vez, para saber dónde están otros servicios. El Cliente de Eureka incluye proveedores de servicios y personas que llaman al servicio, y Eureka es responsable de administrar y registrar la información del proveedor de servicios. Las personas que llaman al servicio no necesitan encontrar los servicios por sí mismos, sino que le dicen a Eureka sus necesidades, y luego Eureka le dirá los servicios que satisfacen sus necesidades.

Al mismo tiempo, el proveedor de servicios y Eureka son monitoreados a través del mecanismo de "latidos" . Cuando un proveedor de servicios tiene un problema, Eureka naturalmente lo eliminará de la lista de servicios.

Esto permite el registro automático, el descubrimiento y la supervisión del estado de los servicios.

Esquemático:

• Eureka: Es el registro de servicios (puede ser un clúster), que expone su dirección al mundo exterior
• Proveedor: Registre su propia información con Eureka después del inicio (dirección, qué servicios brindar)
• Consumidores: suscríbase a Eureka, y Eureka enviará una lista de todas las direcciones de los proveedores de los servicios correspondientes a los consumidores y las actualizará periódicamente.
• Heartbeat (renovación): el proveedor actualiza periódicamente su estado a Eureka a través de HTTP

Infraestructura:

Tres roles centrales en la arquitectura Eureka:

• Registro de servicios

  La aplicación de servidor de Eureka, que proporciona funciones de detección y registro de servicios, es el servidor eureka que acabamos de establecer.

• proveedor de servicio

  La aplicación que brinda el servicio puede ser una aplicación Spring Boot o puede implementarse mediante cualquier otra tecnología, siempre que brinde servicios de estilo REST al mundo exterior.

• consumidor de servicios

  La aplicación del consumidor obtiene la lista de servicios del centro de registro, para conocer la información de cada proveedor de servicios y saber dónde llamar al proveedor de servicios.

Servidor Eureka de alta disponibilidad:

Introducción:

• Eureka puede ser un solo centro o un clúster, cuando nuestro Eureka es un clúster, lo llamamos un centro Eureka de alta disponibilidad.
• El llamado centro de registro de alta disponibilidad en realidad registra EurekaServer como un servicio, de modo que múltiples EurekaServers puedan descubrirse entre sí y formar un clúster.
• Eureka Server es una aplicación web que puede iniciar múltiples instancias (configurar diferentes puertos) para garantizar una alta disponibilidad de Eureka Server

Sincronización de servicios:

Varios servidores Eureka también se registrarán entre sí como servicios. Cuando un proveedor de servicios se registra con un nodo en el clúster de Eureka Server, el nodo sincronizará la información del servicio con cada nodo en el clúster para lograr la sincronización de datos. Por lo tanto, independientemente de que el cliente acceda a cualquier nodo del clúster de Eureka Server, puede obtener la información completa de la lista de servicios.

Como cliente, debe registrar información en cada Eureka

​ Si hay tres Eurekas, cada EurekaServer debe registrarse con varios otros servicios Eureka.

Por ejemplo: hay tres respectivamente 10086, 10087, 10088, entonces:

​ 10086 debe estar registrado en 10087 y 10088

​ 10087 debe estar registrado en 10086 y 10088

​ 10088 debe estar registrado en 10086 y 10087

Mapa abstracto de Eureka de alta disponibilidad:

Representaciones reales de la aplicación:

Configuración de cliente y servidor Eureka:

• Ingeniería de clientes de Eureka
  • proveedor de servicios de servicio al usuario
  • La dirección del servicio utiliza el método ip.
• renovar
  • consumo de servicio de demostración del consumidor
  • Con qué frecuencia obtener la dirección del servicio
• Proyecto de servidor Eureka eureka-server
  • rechazo de falla
  • protección personal

El proveedor de servicios debe registrar el servicio con EurekaServer y completar la renovación del servicio y otros trabajos.

registro de servicio

Cuando el proveedor de servicios se inicie, detectará si el parámetro en la propiedad de configuración: eureka.client.register-with-erueka=true es verdadero, de hecho, es verdadero por defecto. Si el valor es verdadero, iniciará una solicitud Rest a EurekaServer con su propia información de metadatos, y EurekaServer guardará esta información en una estructura de mapa de dos capas.

• La clave de la primera capa del mapa es la identificación del servicio, que generalmente es el atributo spring.application.name en la configuración, servicio de usuario
• La clave del mapa de la segunda capa es la identificación de la instancia del servicio. General host+ serviceId + puerto, por ejemplo: localhost:user-service:8081
• El valor es el objeto de instancia del servicio, es decir, un servicio, por lo que se pueden iniciar varias instancias diferentes al mismo tiempo para formar un clúster.

De forma predeterminada, el nombre de host o localhost se utiliza para el registro.Si desea registrarse con ip, puede agregar la configuración en el servicio de usuario de la siguiente manera:

eureka: 
  instance: 
    ip-address: 127.0.0.1 # ip地址 
    prefer-ip-address: true # 更倾向于使用ip，而不是host名

Renovación del servicio:

Una vez que se completa el servicio de registro, el proveedor de servicios mantendrá un latido (iniciará regularmente una solicitud de descanso a EurekaServer), diciéndole a EurekaServer: "Todavía estoy vivo". A esto lo llamamos la renovación del servicio (renew);

Hay dos parámetros importantes para modificar el comportamiento de la renovación del servicio; puede agregar los siguientes elementos de configuración en el servicio de usuario:

eureka: 
  instance: 
    # 服务续约(renew)的间隔，默认为30秒 
    lease-expiration-duration-in-seconds: 90
    # 服务失效时间，默认值90秒 
    lease-renewal-interval-in-seconds: 30 

Es decir, por defecto, el servicio enviará un latido al registro cada 30 segundos para comprobar que sigue vivo. Si no se envía ningún latido durante más de 90 segundos, EurekaServer pensará que el servicio está caído y se eliminará de la lista de servicios.Estos dos valores no deben modificarse en el entorno de producción, y el valor predeterminado está bien.

Obtener lista de servicios

Cuando se inicie el consumidor del servicio, detectará el valor del parámetro eureka.client.fetch-registry=true. Si es verdadero, extraerá la copia de seguridad de solo lectura de la lista de servicios del servidor Eureka y luego la almacenará en caché localmente. . Y los datos se volverán a extraer y actualizar cada 30 segundos. Puede ser modificado por los siguientes parámetros en el proyecto de demostración del consumidor:

eureka: 
  client: 
    # 重新拉取服务的时间
    registry-fetch-interval-seconds: 30

Rechazo de fallos y autoprotección

Las siguientes configuraciones se realizan en el lado del servidor Eureka Server:

Servicio fuera de línea

Cuando el servicio realiza una operación de apagado normal, activará una solicitud REST para que el servicio se desconecte del servidor Eureka, diciéndole al centro de registro del servicio: "Me estoy desconectando". Después de recibir la solicitud, el centro de servicio pone el servicio fuera de línea

rechazo de falla

A veces, nuestro servicio puede no funcionar correctamente debido a un desbordamiento de la memoria o una falla en la red, pero el centro de registro del servicio no ha recibido la solicitud de "servicio fuera de línea". En comparación con la operación de "renovación del servicio" del proveedor de servicios, el registro del servicio creará una tarea cronometrada al inicio y, de forma predeterminada, el tiempo de espera en la lista actual (90 segundos de forma predeterminada) no se renovará de forma predeterminada. llamado sacrificio de invalidación. Puede ser modificado por el parámetro eureka.server.eviction-interval-timer-in-ms en milisegundos.

protección personal

Cuando cerramos un servicio, veremos una advertencia de letra roja en el panel de Eureka, que activa el mecanismo de autoprotección de Eureka. Cuando un servicio no logra renovar el latido a tiempo, Eureka contará si la proporción de instancias de servicio con fallas en los latidos en los últimos 15 minutos supera el 85 % Cuando el nodo EurekaServer pierde demasiados clientes en un período corto de tiempo (una partición de red puede ocurrir una falla). En un entorno de producción, debido a demoras en la red y otras razones, es probable que la proporción de instancias de falla de latido exceda el estándar, pero no es apropiado eliminar el servicio de la lista en este momento, porque es posible que el servicio no esté inactivo. Eureka protegerá la información de registro de la instancia actual y no la eliminará. Esto funciona bien en un entorno de producción, lo que garantiza que la mayoría de los servicios sigan estando disponibles.

Durante el desarrollo, para facilitar la autoevaluación, la autoprotección generalmente se desactiva.

Cinta de equilibrio de carga

Introducción:

• Cuando se inicia una solicitud entre servicios, el equilibrio de carga se realiza en función de la cinta de opciones y se selecciona una máquina adecuada entre varias máquinas de un servicio para ejecutar el servicio.
• Ribbon proporciona principalmente algoritmos de ecualización de software del lado del cliente.
• El componente del cliente Ribbon proporciona una serie de opciones de configuración completas, como tiempo de espera de conexión, reintento, algoritmo de reintento, etc. Ribbon tiene componentes integrados de equilibrio de carga conectables y personalizables.

Esquemático:

Estrategia de equilibrio de carga:

• Equilibrio de carga Round Robin simple
• Equilibrio de carga de tiempo de respuesta ponderado
• Equilibrio de carga por turnos con reconocimiento de zonas (la estrategia por turnos se usa de manera predeterminada)
• equilibrio de carga aleatorio

Método para realizar:

Debido a que Ribbon ya está integrado en Eureka, no necesitamos introducir nuevas dependencias. Agregue la anotación @LoadBalanced directamente al método de configuración de RestTemplate:

@Bean 
@LoadBalanced 
public RestTemplate restTemplate() { 
	return new RestTemplate(); 
}

Cómo modificar la estrategia de equilibrio de carga:

# 默认为轮询负载均衡，修改为随机负载均衡
user-service: 
  ribbon: 
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

Rompedor Hystrix

Introducción:

Hystix es una biblioteca de tolerancia a fallas y demoras de fuente abierta de Netflix, que se utiliza para aislar el acceso a servicios remotos y evitar fallas en cascada.

La solicitud se inicia a través del grupo de subprocesos de Hystrix. Diferentes servicios usan diferentes grupos de subprocesos, lo que permite el aislamiento de diferentes llamadas de servicio y evita el problema de la avalancha de servicios.

principio:

Básicamente, la relación entre las llamadas de servicio es la siguiente: (En los microservicios, una solicitud comercial llama a cuatro servicios A, H, I y P)

Cuando todos los microservicios se ejecutan normalmente, la solicitud finaliza normalmente después de recibir la respuesta y se libera el subproceso.

En este punto, hay un problema con el microservicio I, lo que hace que no se responda la solicitud.

Se produce una excepción en el microservicio I, la solicitud se bloquea y la solicitud del usuario no se responderá, 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, y las solicitudes se bloquean 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, formando un efecto de avalancha.

solución:

Los medios para que Hystrix resuelva el problema de las avalanchas incluyen principalmente:

• aislamiento de subprocesos
• degradación del servicio

aislamiento de subprocesos

Esquemático:

analizar:

• Hystrix asigna un pequeño grupo de subprocesos para cada llamada de servicio dependiente. Si el grupo de subprocesos está lleno, la llamada se rechazará de inmediato. De manera predeterminada, no se utiliza la cola para acelerar el tiempo de evaluación de fallas.
• La solicitud del usuario ya no accederá directamente al servicio, pero accederá al servicio a través del subproceso inactivo en el grupo de subprocesos. Si el grupo de subprocesos está lleno o se agota el tiempo de espera de la solicitud, el servicio se degradará.

degradación del servicio

Ventajas:
los servicios principales se pueden garantizar primero

Cuando la solicitud del usuario falla, no se bloqueará y no esperará interminablemente ni verá que el sistema falla, al menos puede ver un resultado de ejecución (como devolver un mensaje de aviso amistoso). Aunque la degradación del servicio hará que la solicitud falle, no provocará el bloqueo y, como máximo, afectará a los recursos en el grupo de subprocesos correspondiente al servicio dependiente y no responderá a otros servicios. Circunstancias que desencadenan la degradación del servicio de Hystrix:

• el grupo de subprocesos está lleno
• Tiempo de espera agotado

El tiempo predeterminado de tiempo de espera de la solicitud es 1S, podemos usar el siguiente código para modificarlo en el archivo de configuración

# 默认超时时长为1S，修改为2S
hystrix:
  command:
    default: 
      execution: 
        isolation:
          thread:
            timeoutInMilliseconds: 2000

Disyuntor de servicio

principio:

​ En el servicio de fusibles, el fusible utilizado también se denomina disyuntor, su palabra en inglés es: Circuit Breaker. Después de la fusión del servicio de la aplicación en un sistema distribuido, la persona que llama al servicio puede juzgar qué servicios responden lentamente o tienen una gran cantidad de tiempos de espera, y puede fusionar activamente estos servicios para evitar que todo el sistema se vea afectado.

El mecanismo de fusión de servicios de Hystrix puede lograr una tolerancia elástica a fallas; cuando la situación de la solicitud de servicio mejora, puede volver a conectarse automáticamente. Por medio de la interrupción del circuito, las solicitudes de seguimiento se rechazan directamente y algunas solicitudes pueden pasar después de un período de tiempo (predeterminado 5 segundos).Si la llamada es exitosa, el interruptor automático volverá al estado cerrado, de lo contrario, seguirá abriendo y rechazando el servicio solicitado.

Esquemático:

Los 3 estados de la máquina de estados:

• Cerrado : Estado cerrado (disyuntor cerrado), se puede acceder a todas las solicitudes con normalidad.
• Abierto : en el estado abierto (el disyuntor está abierto), todas las solicitudes se degradarán. Hystrix contará el estado de la solicitud. Cuando el porcentaje de solicitudes fallidas alcanza el umbral dentro de un cierto período de tiempo, se activará un fusible y el disyuntor se abrirá por completo. El umbral de proporción de errores predeterminado es del 50 % y el número de solicitudes debe ser de al menos 20.
• Semiabierto : estado semiabierto, no permanente, entrará en el tiempo de suspensión después de que se abra el disyuntor (el valor predeterminado es 5S). El disyuntor entrará entonces automáticamente en el estado semiabierto. En este momento, se liberarán algunas solicitudes para pasar. Si estas solicitudes están en buen estado, el disyuntor se cerrará; de lo contrario, permanecerá abierto y el temporizador de suspensión se ejecutará nuevamente.

Establezca los parámetros del fusible, que se pueden modificar en el archivo de configuración:

hystrix: 
  command: 
    default:
      circuitBreaker: 
        errorThresholdPercentage: 50 		# 触发熔断错误比例阈值，默认值50% 
        sleepWindowInMilliseconds: 10000 	# 熔断后休眠时长，默认值5秒 
        requestVolumeThreshold: 10			# 熔断触发最小请求次数，默认值是20

Simulación de proxy dinámico

Introducción:

• Fingir es un cliente de servicio web declarativo, que facilita las llamadas entre microservicios, de forma similar a cómo un controlador llama a un servicio.

• Basado en el mecanismo de proxy dinámico de Feign, de acuerdo con la anotación y la máquina seleccionada, empalme la dirección URL de la solicitud, inicie la solicitud y realice la función de proxy dinámico de la dirección URL.

• Feign ha integrado automáticamente el equilibrio de carga de Ribbon y Hystrix, por lo que cuando configuramos el proxy dinámico de Feign, podemos modificar directamente el archivo de configuración para lograr

Al introducir las dependencias de Feign, podemos usar Ribbon e Hystrix

<dependency> 
	<groupId>org.springframework.cloud</groupId> 
	<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

Principio de implementación:

Cree un cliente cliente anotando @FeignClient (value="user-service"), luego llame al cliente cliente en la clase del controlador, use una dirección de solicitud personalizada en la clase del controlador, cuando llamemos a la clase del controlador para implementar el usuario Cuando - se utiliza la función de servicio, se utiliza la función de proxy dinámico.

Es decir, se puede acceder al servicio deseado sin usar la dirección de acceso real, y la función de acceder dinámicamente al servicio se realiza usando la dirección proxy.

Equilibrio de carga en Fingir

Fingir integra la función de balanceo de carga de Ribbon por defecto, y podemos realizar la función de balanceo de carga a través del archivo de configuración

# 当我们要针对某个服务进行负载均衡的时候，仅需要在ribbon的上级目录中添加相应的服务名即可
ribbon:
  ConnectTimeout: 1000 # 连接超时时长 
  ReadTimeout: 2000 # 数据通信超时时长 
  MaxAutoRetries: 0 # 当前服务器的重试次数
  MaxAutoRetriesNextServer: 0 # 重试多少次服务
  OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试

Fusionar a Hystrix en Fingir

Feign también hereda el fusible Hystrix.Cuando necesitamos usar el fusible, solo necesitamos habilitar el servicio de fusible en el archivo de configuración.

feign: 
  hystrix:
    enabled: true # 开启Feign的熔断功能

solicitar compresión

Spring Cloud Feign admite la compresión GZIP para solicitudes y respuestas para reducir la pérdida de rendimiento durante la comunicación. La función de compresión de solicitudes y respuestas se puede habilitar mediante los siguientes parámetros:

feign: 
  compression: 
    request: 
      enabled: true 	# 开启请求压缩 
      mime-types: text/html,application/xml,application/json 	# 设置压缩的数据类型 
      min-request-size: 2048 	# 设置触发压缩的大小下限
    response：
      enabled: true 	# 开启响应压缩

Puerta de enlace de servicio

Introducción:

• Spring Cloud Gateway proporciona funciones básicas de puerta de enlace basadas en la cadena de filtro: seguridad, puntos de monitoreo/entierro, limitación de corriente, etc.
• Spring Cloud Gateway proporciona un método de gestión de enrutamiento API simple, eficaz y unificado para la arquitectura de microservicios.
• Spring Cloud Gateway es un conjunto de soluciones para reemplazar Netflix Zuul.
• El núcleo del componente Spring Cloud Gateway es una serie de filtros a través de los cuales las solicitudes enviadas por el cliente se pueden reenviar (enrutar) a los microservicios correspondientes. Spring Cloud Gateway es un firewall y un proxy agregado al frente de todo el microservicio, que oculta la información del puerto IP del nodo del microservicio, lo que mejora la protección de la seguridad. Spring Cloud Gateway en sí también es un microservicio que debe registrarse en el registro de servicios de Eureka.

Una breve comprensión de la función de Gateway es: si el front-end quiere llamar al sistema back-end, entonces todas las solicitudes de front-end provienen del Gateway, y el Gateway reenvía la solicitud al servicio correspondiente después del filtrado.

Las funciones principales de la puerta de enlace son: filtrado y enrutamiento

Esquemático:

Idea principal:

• Enrutamiento ( ruta ) La composición de la información de enrutamiento: consta de una ID, una URL de destino, un conjunto de fábricas de aserciones y un conjunto de filtros. Si la afirmación de la ruta es verdadera, la URL de la solicitud coincide con la ruta configurada.
• Aserción ( predicado ) El tipo de entrada de la función de aserción en Spring Cloud Gateway es ServerWebExchange en el marco Spring 5.0. La función de aserción de Spring Cloud Gateway permite a los desarrolladores definir la coincidencia de cualquier información de la solicitud HTTP, como los encabezados y los parámetros de la solicitud.
• Filtro ( Filter ) Un Spring WebFilter estándar. El filtro en Spring Cloud Gateway se divide en dos tipos de filtro, a saber, filtro de puerta de enlace y filtro global. Filter Filter modificará la solicitud y la respuesta.

Utilice un fragmento de código directamente para mostrar la función de la puerta de enlace:

spring：
  application: 
    name: api-gateway 
  cloud: 
    gateway: 
      routes: 
        # 路由id，可以随意写 
        - id: user-service-route 
        # 代理的服务地址（lb表示负载均衡）
        uri: lb://user-service 
        # 路由断言，可以配置映射路径 
        predicates: 
          - Path=/api/user/** 
        filters: 
        # 添加请求路径的前缀 
        - PrefixPath=/user
        # 表示过滤1个路径，2表示两个路径，以此类推 
          - StripPrefix=1
          # 自定义过滤器 
          - MyParam=name 
        # 默认过滤器，对所有路由都生效 
        default-filters: 
          - AddResponseHeader=X-Response-Foo, Bar 
          - AddResponseHeader=myname
        # 跨域配置
        globalcors: 
          corsConfigurations: 
            '[/**]': 
            #allowedOrigins: * # 这种写法或者下面的都可以，*表示全部
            allowedOrigins: - "http://docs.spring.io" 
            allowedMethods: - GET

analizar:

• La identificación de la ruta se puede escribir libremente
• En la dirección de servicio del proxy , lb significa LoadBanlance y el nombre del servicio se usa para la configuración del balanceo de carga.
• Aserción de enrutamiento : Tome el ejemplo en el código, es decir, la solicitud que comienza con /api/usuario/** en la ruta será enviada al puerto correspondiente del nombre del servicio servicio-usuario y el servicio-usuario/api /usuario/** se ejecutará el servicio de solicitud
• Filtro (agregar y eliminar ruta de prefijo): PrefixPath=/usuario, lo que significa agregar un prefijo de ruta de usuario al extremo frontal de la dirección de solicitud, es decir, cuando la dirección de solicitud es servicio-usuario/1, la dirección a la que se accede realmente es user-service/user/ 1; StripPrefix=1, lo que significa que cuando usamos la solicitud que comienza con /api/user/**, filtrar la primera ruta en la ruta de la solicitud. Por ejemplo, en este ejemplo, eliminar directamente el ruta api y ejecutar servicio de usuario/usuario /** servicio
• Filtro personalizado y filtro global : el caso en el ejemplo es principalmente para agregar la información de identificación correspondiente a los datos del encabezado de la solicitud
• Configuración entre dominios : allowOrigins indica la dirección de solicitud a la que se permite acceder; allowMethods indica el método de solicitud que permite el acceso. Como en el código anterior, la puerta de enlace solo permite el paso de solicitudes cuya dirección sea http://docs.spring.io y cuyo método de solicitud sea GET.

Los escenarios de aplicación comunes del filtro de puerta de enlace Gateway son los siguientes:

• Solicitar autenticación: generalmente, antes de que GatewayFilterChain ejecute el método de filtro, si encuentra que no hay derecho de acceso, regresará directamente vacío.
• Manejo de excepciones: generalmente, después de que GatewayFilterChain ejecuta el método de filtro, registra la excepción y la devuelve.
• Estadísticas de duración de la llamada de servicio: GatewayFilterChain realiza estadísticas basadas en el tiempo antes y después de ejecutar el método de filtro.

Centro de configuración distribuida Config

Introducción:
un componente de configuración distribuida que coloca los archivos de configuración en el almacén local o remoto del servicio de configuración para la administración centralizada. Por ejemplo, los archivos de configuración como application.yml se pueden colocar en un almacén Git remoto para su administración.
Diagrama esquemático:

config Información de configuración principal:

spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        #  此处使用的远程仓库为git
        git:
          uri:  				# 仓库地址，根据项目的地址来导入对应的项目
          # 因为仓库为私有，所以此处需要配置用户名和密码
          username:      # 仓库用户名
          password:       # 仓库密码

El centro de configuración distribuida también es un microservicio, por lo que debe registrarse en el centro de registro.
Después de configurar el centro de configuración, también se deben modificar otros archivos de configuración de microservicios que necesitan colocar los archivos de configuración en el almacén remoto:
Pasos:

1. Transfiera el archivo de configuración application.yml al almacén remoto y el formato de nombre es application-profile.yml
2. Elimine el archivo de configuración local application.yml
3. Cree un nuevo archivo de configuración llamado bootstrap.yml

configuración bootstrap.yml:

# 采用bootstrap.yml配置文件，从git仓库的配置中心中获取对应配置文件，而不在本地进行配置
# bootstrap.yml相较application.yml：bootstrap.yml更常用于系统配置，即基本不进行修改，application.yml更常用于动态调整的配置
spring:
  cloud:
    config:
      # 与git仓库中配置文件的application名一致
      name: user
      # 与git仓库中配置文件的profile名一致
      profile: dev
      # 与git仓库中配置文件存放的分支一致
      label: master
      discovery:
        # 使用配置中心
        enabled: true
        # 配置中心服务名，项目中连接配置中心模块的名称
        service-id: config-server
# 同样需要在注册中心进行注册
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

A través de la configuración anterior, hemos completado la configuración del centro de configuración Spring Cloud config. Este método de configuración nos permite obtener estáticamente los parámetros de configuración deseados del almacén remoto, y cuando el archivo de configuración cambia cada vez, necesitamos Los datos modificados pueden solo se puede recuperar reiniciando el servicio local, por lo que sigue siendo un poco inconveniente.
Para realizar la adquisición dinámica de archivos de configuración en el almacén remoto, necesitamos introducir el bus de servicio Bus y

Autobús de servicio Spring Cloud Bus

Introducción:

• Spring Cloud Bus utiliza un intermediario de mensajes ligero para conectar nodos distribuidos, que se pueden utilizar para transmitir cambios en los archivos de configuración o la supervisión y gestión de servicios. Es decir, el bus de mensajes puede monitorear microservicios y comunicarse entre sí entre aplicaciones. Los intermediarios de mensajes opcionales para Spring Cloud Bus incluyen RabbitMQ y Kafka.
• La capa inferior de Spring Cloud Bus se implementa en base a RabbitMQ y el servicio de cola de mensajes local se usa de manera predeterminada. Por lo tanto, al usarlo, debe habilitar el servicio RabbitMQ con anticipación para realizar una actualización dinámica de la información en forma de mensaje. colas

Después de introducir la función de bus Spring Cloud Bus, el diagrama esquemático de la llamada de servicio es el siguiente:

Uso:

• centro de configuración de configuración: introduzca las dependencias de Spring Cloud Bus y RabbitMQ; modifique el archivo de configuración, agregue parámetros de RabbitMQ para realizar la función de cola de mensajes y exponga la dirección que activa el bus de mensajes.
• Microservicio (servicio de usuario): importe las dependencias Spring Cloud Bus, RabbitMQ y Spring Boot Actuator; modifique el archivo de configuración bootstrap.yml, agregue parámetros RabbitMQ para implementar el código de importación de la función de cola de mensajes
  :

# config配置文件

spring:
  # 配置rabbitmq信息；如果是都与默认值一致则不需要配置，rabbitmq访问地址为127.0.0.1:15672，此处使用的port只有后四位5672即可
  # 以下配置即为默认配置，可删
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
management:
  endpoints:
    web:
      exposure:
        # 暴露触发消息总线的地址
        include: bus-refresh

# user-service配置文件

spring：
  # 配置rabbitmq信息；如果是都与默认值一致则不需要配置，rabbitmq访问地址为127.0.0.1:15672，此处使用的port只有后四位5672即可
  # 以下配置即为默认配置，可删
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

Después de la configuración anterior, el servicio de bus Spring Cloud Bus se introdujo con éxito y la adquisición dinámica de archivos de configuración en el almacén remoto se realizó mediante el uso de la función de cola de mensajes.

Diagrama de arquitectura completa de Spring Cloud