Byteface 3: ¿Sabes qué es Eureka?

¿Qué es el registro de servicios?

Primero, comprendamos la relación entre el registro de servicios, el descubrimiento de servicios y el registro de servicios.

Por ejemplo, la relación entre los tres es como la de un proveedor, un cliente y una tienda.

Primero, los proveedores de todo el mundo suministran productos a la tienda y luego los clientes van a la tienda a comprar los productos cuando los necesitan.

El centro de registro es como una tienda. El comportamiento del proveedor es el registro del servicio y el producto es el servicio registrado.

Cuando se activa un servicio implementado, se registrará en el centro de registro, y cuando los consumidores necesiten cualquier tipo de servicio, acudirán al centro de registro para recuperarlo ellos mismos.

Entonces, ¿qué es exactamente el registro de servicios y por qué necesitamos registrar servicios en el registro?

El registro del servicio significa que el servicio se registra en el registro cuando se inicia. El registro gestiona todos los servicios registrados de forma unificada.

Ahora pensemos en ello, si eres consumidor y necesitas comprar un artículo, puedes acudir a una tienda o acudir directamente al proveedor para comprarlo.

Pero si necesita comprar muchos artículos hoy y no sabemos la dirección del proveedor de cada artículo, entonces tendrá que ir puerta a puerta al proveedor para comprar los artículos.

¿No sería problemático si hubiera una tienda que reuniera artículos de varios proveedores, de modo que pudieras ir a esa tienda y conseguir todos los artículos que necesitabas?

Esto es conveniente.

Por ejemplo, en nuestro desarrollo real, cuando necesitamos obtener información del usuario y nuestro servicio de usuario solo implementa un nodo en este momento, podemos usar el formulario de puerto IP para acceder al servicio.

Cuando nuestro servicio se implementa en 10 nodos en este momento, podemos acceder al servicio a través del nombre de dominio, y el nombre de dominio se reenvía a un nodo a través de nginx para acceder al servicio en ese nodo.

Todos los que han usado nginx saben que cada vez que necesitamos agregar un nuevo nodo, debemos modificar el archivo de configuración de nginx. Una vez que el servicio se implementa con demasiados nodos, la modificación frecuente del archivo de configuración se vuelve. una tarea extremadamente difícil.

En este momento, nuestro centro de registro debería hacer su debut.

Una vez establecido el centro de registro, implementamos el nodo de servicio. Una vez completada la implementación y iniciado el servicio, la información del servicio se registrará en el centro de registro, por lo que ya no tendremos que preocuparnos. modificando el archivo de configuración.

¿Qué es el descubrimiento de servicios?

Hay dos modos de descubrimiento de servicios: modo de descubrimiento de cliente y modo de descubrimiento de servidor.

El modelo de descubrimiento del lado del cliente es como si yo fuera un cliente propietario de un terreno: voy a la tienda y compro todos los artículos, luego los llevo a casa y luego miro los artículos cuando los necesito. .

Como soy un magnate, ciertamente no soporto tener nuevos productos en la tienda y no lo hago, así que almaceno gradualmente de vez en cuando para obtener los artículos más nuevos.

Este es el Registro Fetch de Eureka, que busca información de registro.

El cliente Eureka obtiene información de registro del servidor Eureka y la almacena en caché localmente.

Tenga en cuenta que el cliente Eureka no obtiene datos directamente del registro del servicio, sino del caché de solo lectura.

Para ello, obtiene actualizaciones incrementales entre el ciclo de recuperación anterior y el ciclo de recuperación actual, que se actualizan periódicamente (una vez cada 30 segundos).

El scraping puede devolver la misma instancia y el cliente Eureka maneja la información duplicada automáticamente.

Debido a mi comportamiento de magnate, el dueño de la tienda me registró en su lista VVIP. Desafortunadamente, estoy arruinado y ya no puedo ser tan generoso.

No tuve más remedio que decirle al dueño de la tienda que estaba en quiebra. El dueño de la tienda me escuchó y borró mi nombre de su lista VVIP sin siquiera pensar en ello.

Esta es la cancelación de Eureka, cancelación.

Cuando se cierra cada nodo de microservicio, el cliente Eureka envía una solicitud de cancelación al servidor Eureka.

Una vez que el servidor Eureka reciba tu solicitud de cancelación, te eliminará del registro del servicio.

La dueña de la tienda es una persona arrogante y tiene como regla que si estás en su lista VVIP, debes ir a la tienda a comprar artículos de vez en cuando.

Una vez que no compres por un tiempo, ella sentirá que ya no tienes el poder adquisitivo para estar en su lista VVIP.

Entonces ella te eliminará de su lista VVIP sin piedad.

Esto es Renew en Eureka

Hay un equilibrador de carga integrado dentro del cliente Eureka, que utiliza un algoritmo de carga por turnos.

Una vez iniciado el servicio, se enviará un latido al servidor Eureka de vez en cuando (el valor predeterminado es 30 segundos).

Si el servidor Eureka no recibe un latido del cliente Eureka dentro de múltiples ciclos de latido (90 segundos de forma predeterminada), el servidor Eureka eliminará el nodo del registro de servicios.

Por supuesto, el descubrimiento de servicios ingresa al registro para obtener la información del servicio, y luego necesita obtener la información del nodo en el que se implementa el servicio a partir de la información del servicio y luego acceder al servicio en ese nodo. a través de la dirección del dominio.

Esto es como una tienda, ya que el espacio es muy pequeño, solo almacena un modelo en miniatura de un determinado producto. La dirección del proveedor del producto está escrita en el modelo. para obtener el modelo y verificar el suministro. La dirección del proveedor, luego podemos ir directamente al proveedor para comprar los productos.

¿Qué es el registro y su función?

El registro es un administrador en el que los proveedores de servicios registran sus servicios, y el registro almacena y administra estos servicios de manera unificada.

El registro también puede determinar si los servicios están disponibles y eliminar los servicios no disponibles.

Más adelante se explicará en detalle cómo determinar si un servicio está disponible y cómo eliminar los servicios no disponibles.

¿Qué es Eureka y para qué sirve?

Eureka adopta la arquitectura CS y se divide en dos partes principales.

Uno es el Eureka Server, el servidor de registro.

Cuando se inicia cada nodo de microservicio, el servidor Eureka almacena la información del servicio registrada por el proveedor del servicio y proporciona un mecanismo de almacenamiento en caché de dos capas para mantener todo el registro.

El otro es el cliente Eureka, el cliente de registro.

Eureka Client es un cliente Java que simplifica la interacción con el servidor Eureka.

El cliente Eureka busca, actualiza y almacena en caché información en el servidor Eureka.

Por lo tanto, cuando todos los nodos del servidor Eureka están inactivos, los consumidores de servicios aún pueden usar la información almacenada en caché para encontrar proveedores de servicios, pero se producirán inconsistencias cuando los servicios cambien.

Descripción de la arquitectura Eureka

Como se muestra en la figura siguiente, este es el diagrama de la arquitectura Eureka que nos proporcionó el sitio web oficial: servidor Eureka y cliente Eureka. Eureka Client se divide en servicio de aplicación (Servicio de aplicación) y cliente de aplicación (Cliente de aplicación), donde el servicio de aplicación es un proveedor de servicios y el cliente de aplicación es un consumidor de servicios.

En la aplicación nos apoyaremos primero en el cliente Eureka. Una vez iniciado el proyecto, el cliente Eureka enviará una solicitud de registro al servidor Eureka y parte de su información al servidor Eureka.

Después de un registro exitoso, el cliente Eureka enviará un latido al servidor Eureka de vez en cuando para actualizar el servicio, es decir, informar el estado de salud. Si el cliente no se actualiza durante mucho tiempo, el servidor Eureka eliminará la información del cliente del registro del servidor en aproximadamente 90 segundos.

El cliente Eureka también extrae periódicamente información de registro del servidor Eureka y luego obtiene el objetivo y realiza llamadas remotas de acuerdo con el algoritmo de equilibrio de carga, que se presentará en detalle en el componente Ribbon más adelante en esta lección. .

Cuando la aplicación se detiene, también se notificará al servidor Eureka para que elimine la información relacionada. Una vez que la información se elimina con éxito, el cliente correspondiente actualizará la información relevante del servicio, de modo que no se llamará al servicio fuera de línea. Sin embargo, por supuesto, habrá un retraso y también es posible llamar al servicio fallido. entonces el cliente habilitará la función de conmutación por error para evitar esta pregunta.

El servidor Eureka tiene múltiples nodos que forman un clúster para garantizar una alta disponibilidad, y el servidor Eureka no integra ningún otro almacenamiento de terceros, sino que lo almacena en la memoria.

Por lo tanto, Eureka Server replica la información de registro entre todos los nodos de Eureka Server en el clúster.

De esta forma, los datos se pueden habilitar a través de **** y cualquier cliente Eureka puede consultar la información de registro en cualquier nodo del servidor Eureka.

Flujo de trabajo de Eureka

Mecanismo de autoprotección de Eureka

¿Qué es la autoprotección?

Oficialmente hablando, la autoprotección es una medida de seguridad. contra fluctuaciones anormales de la red. El modo de autoprotección es una medida de seguridad para evitar fluctuaciones en la red y se utiliza para hacer que el clúster Eureka sea más potente y estable.

¿Por qué habilitar la autoprotección?

Si el servidor Eureka no recibe el latido del nodo de servicio dentro de un cierto período de tiempo (el valor predeterminado es 90) (se puede optimizar), el servidor Eureka eliminará la instancia del servicio.

Sin embargo, en algunos casos, la partición de la red falla y el nodo de servicio se encuentra en un estado de supervivencia normal, pero no puede comunicarse normalmente con el servidor Eureka en este momento, si no hay un mecanismo de autoprotección. Introducido, Eureka Server eliminará el nodo de servicio.

Cómo funciona el modo de autoprotección

Si más de 85 nodos cliente no tienen un latido normal en 15 minutos, el servidor Eureka considerará que el cliente y el registro están experimentando un Fallo de la red. El servidor Eureka entrará en un estado de autoprotección.

Desventajas del mecanismo de autoprotección

Si un nodo de servicio se desconecta de forma anormal durante el mecanismo de autoprotección, pero Eureka Server no rechaza el nodo de servicio, el consumidor del servicio obtendrá una instancia de servicio no válida.

Solución

①: Apague el mecanismo de autoprotección (no recomendado)

②: Cambie las solicitudes o disyuntores, use el equilibrio de carga y configure el solicitud después de no responder La cantidad de segundos, la rapidez con la que la solicitud cambia al siguiente servicio registrado, como el uso de Ribbon Hystrix. Configurar el equilibrio de carga y los disyuntores.

Después de que Eureka Server ingrese al mecanismo de autoprotección

1. Eureka Server ya no eliminará los nodos de servicio del registro porque no han renovado el contrato de registro durante mucho tiempo

2. El servidor Eureka aún puede aceptar solicitudes de registro y consulta para nuevos servicios, pero estas solicitudes no se sincronizarán con otros nodos del servidor Eureka

3. Cuando la red es normal, la actual El nodo del servidor Eureka enviará solicitudes a otros servidores Eureka. El nodo del servidor Eureka sincroniza la información del nuevo nodo de servicio

Cómo habilitar la autoconservación

Pasar

eureka.server.enable-self-preservation=true/false para activar o desactivar el mecanismo de autoprotección.

Otras configuraciones clave:

Intervalo de tiempo para limpiar los nodos de servicio fallidos:

eureka.server.evacuation-interval-timer-in-ms tiene como valor predeterminado 60 s

Intervalo de renovación del contrato de arrendamiento:

eureka.instance.lease-renewal-interval-in-segundos tiene como valor predeterminado 30 s

Tiempo de vencimiento de la renovación:

p>

eureka.instance.lease-expiration-duration tiene como valor predeterminado 30 segundos. instancia.lease-expiration-duration-in-segundos predeterminado 90s

Eche un vistazo a cómo Eureka activa el mecanismo de autoprotección a través del código fuente

En el primer paso, Introduzca la dependencia del servidor Eureka.

En el segundo paso, encontramos la ruta al paquete de registro en el paquete jar eureka-core en com.netflix.eureka

En el tercer paso, ingresamos a la clase AbstractInstanceRegistry, y busque el método de desalojo, que finalmente lo ejecuta el hilo que borra la tarea periódicamente.

En el cuarto paso, encontramos la implementación del método isLeaseExpirationEnabled()

En el quinto paso, notamos que

la variable numberOfRenewsPerMinThreshold es muy crítica Representa el número mínimo de renovaciones por minuto

Esta variable se actualiza de la siguiente manera en los métodos de registro y cancelación del servicio:

Este es todo el proceso lógico para que Eureka se inicie automáticamente. -protección.

Desactivar el mecanismo de autoprotección

1. Cuando se resuelva el fallo de la partición de red del servicio y el cliente pueda interactuar con el servicio, el número de renovaciones por minuto aumentará Se actualizará durante el proceso de renovación y se cancelará automáticamente cuando el número de renovaciones por minuto supere las 85.

2. Reinicie el servicio

Comprobación de estado en Eureka

De hecho, muchos marcos gestionan el seguimiento del estado de salud a través del actuador y amplían el punto final de salud.

Esto significa que solo necesitamos integrar Actuator en el proyecto para gestionar el seguimiento del estado del proyecto.

Lo mismo ocurre con Eureka. Podemos indicarle a Eureka Server el estado de ciertos nodos de servicio en mal estado y luego Eureka Server los desconectará activamente.

Este es el chequeo de salud de Eureka.

¿Cómo implementar el control de estado de Eureka-Actuator?

Primero, debemos depender de

spring-boot-starter-actuator en pom

Segundo paso, agregarlo en la configuración

<. p> eureka.client.healthcheck.enabled=true configuración<

Análisis de principios:

Primero, de acuerdo con el valor de eureka.client.healthcheck.enabled, configure eureka.client. Healthcheck .enabled se agrega a EurekaDiscoveryClientConfiguration. valor habilitado para decidir si ensamblar EurekaHealthCheckHandler y luego registrar HealthCheck en EurekaClientAutoConfiguration, pero después del registro, llamaremos a la tarea para la actualización de estado, que se completará en com.netflix.discovery.InstanceInfoReplicator.run().

Mecanismo de almacenamiento en caché multinivel de Eureka

¿Qué es un mecanismo de almacenamiento en caché multinivel?

El servidor Eureka utiliza un mecanismo de almacenamiento en caché multinivel para mejorar el tiempo de respuesta de solicitudes de servicio para evitar Leer datos de la memoria al mismo tiempo causa conflictos de concurrencia.

El almacenamiento en caché del servidor Eureka se completa mediante caché de solo lectura y caché de lectura y escritura.

Caché de primer nivel: concurrentHashMaplt; clave, valorgt; El mapa de caché de solo lectura es esencialmente un HashMap sin tiempo de vencimiento, que se utiliza para guardar información de datos de salida externa.

readOnlyCacheMap se basa en actualizaciones del temporizador y, al comparar valores con readWriteCacheMap, readWriteCacheMap tiene prioridad.

ResponseCacheUpdateIntervalMs: intervalo de actualización de caché de readOnlyCacheMap, el valor predeterminado es 30 s

Caché de segundo nivel: clave LoaDinglt, valuegt; Incluye un mecanismo de conmutación por error para proteger los datos y la información de ser exportados al mundo exterior.

respuestaCacheAutoExpirationInSeconds: tiempo de caducidad de la caché de readWriteCacheMap, el valor predeterminado es 180 segundos.

Cuando el nodo de servicio está registrado, fuera de línea, caduca, cambia de estado, etc.

1. Actualice la información de registro en la memoria

2. Mientras el El caché readWriteCacheMap caduca, el borrado del caché solo borrará el caché readWriteCacheMap, el caché de solo lectura readOnlyCacheMap no se actualizará, es decir, cuando la información del cliente cambie, el caché de solo lectura no se detectará de inmediato.

3.

3. Después de un período de tiempo (el valor predeterminado es 30 segundos), el hilo en segundo plano descubre que el caché readWriteCacheMap está vacío, por lo que el caché en readOnlyCacheMap también se borrará.

4. Cuando el consumidor del servicio llama a la información de registro, el hilo en segundo plano borrará el caché de solo lectura.

Cuando el consumidor del servicio extrae información de registro, llama al método de carga de ClassLoader para cargar la información de registro desde la memoria a las cachés de todos los niveles.

Hay dos subprocesos en el servidor Eureka. Un subproceso sincroniza los datos en las dos cachés periódicamente (30 segundos de forma predeterminada) y el otro subproceso detecta fallas de latido periódicamente (90 segundos de forma predeterminada).

Extracción de servicio

1. De forma predeterminada, el consumidor del servicio extrae la información del registro cada 30 segundos

2.> Si la recuperación está vacía, se recuperará de readOnlyCacheMap Obtenga información

3. Si readWriteCacheMap todavía está vacío, obtenga información de readWriteCacheMap

4. Llame al método de carga de ClassLoader para cargar la información del registro en la memoria en el caché jerárquico. e información del registro de devolución.

Configuración regional de Eureka

Cuando los usuarios están ampliamente distribuidos geográficamente, por ejemplo, cuando una empresa tiene sucursales en Shanghai, Hangzhou, Qingdao, etc., generalmente hay varias salas de máquinas.

Entonces, los usuarios, por supuesto, quieren llamar a microservicios desde la sala de servidores de la sucursal local.

Por ejemplo, si el usuario A en Shanghai llama al servicio OAuth2, entonces el usuario A ciertamente quiere llamar a la aplicación de microservicio en la sala de servidores de Shanghai. Si el usuario A en Shanghai llama al servicio OAuth2 en la sala de computadoras de Hangzhou, el tiempo de demora aumentará.

Por lo tanto, esperamos que los servicios en una sala de servidores llamen preferentemente a los servicios en la misma sala de servidores. Cuando los servicios en la misma sala de servidores no estén disponibles, se llamará a los servicios en otras salas de servidores para reducir las demoras.

Por este motivo, eureka proporciona dos conceptos de área y zona para particiones. Eureka está diseñado en base a Amazon, por lo que es consistente con Amazon en términos de diferenciación geográfica, es decir, está dividido en múltiples regiones y cada región contiene múltiples zonas. Entre regiones, se pueden priorizar las solicitudes de servicios en la misma región que el servicio solicitado.

Configuración básica

En este momento, no importa cuántas veces llamemos, se llama al servicio de la zona 1 en Shanghai.

En términos generales, usamos Ribbon para equilibrar la carga de microservicios. Ribbon tiene algunos algoritmos de política de carga especiales, pero como dijimos, priorizaremos las solicitudes de instancias de servicio en la zona especificada.

Pero en algunos casos, por ejemplo, cuando no hay una zona disponible en Región=shanghai, el sistema cargará DEFAULT_ZONE de forma predeterminada, o si la carga del servicio en la misma región es demasiado alta..., el sistema también habrá un cambio automático a otro servicio en la misma región.

Si no hay un área disponible en Shanghai, el sistema cambiará automáticamente a otras áreas.

Mecanismo de reintento de Eureka

Dado que el mecanismo de gobernanza del servicio implementado por Spring Cloud Eureka enfatiza los principios CAP de AP, disponibilidad y confiabilidad, y sacrifica un cierto grado de coherencia (en casos extremos, preferiría aceptar una instancia fallida que perder una instancia "sana" (esto es como el mecanismo de autoprotección que describimos anteriormente).

Sin embargo, ya sea que se active el mecanismo de protección o haya un retraso en la eliminación del servicio, lo que hace que el servicio llame a uno de los servicios con formato incorrecto, la llamada fallará y otros servicios no funcionarán.

Obviamente, esto no es lo que queremos ver y todavía queremos mejorar la tolerancia a fallos para hacer frente a este tipo de problemas. Por lo tanto, generalmente agregamos algún tipo de mecanismo de reintento al implementar llamadas de servicio.

A partir de la versión Camden SR2, Spring Cloud integra Spring Retry para mejorar la función de reintento de RestTemplates, de modo que los desarrolladores solo necesitan configurar el acceso al servicio implementado inicialmente a través de RestTemplates, y la política de reintento se puede implementar automáticamente en función de la configuración.

Habilitar el mecanismo de reintento de Eureka es muy simple. Primero, introducimos la dependencia Spring Retry en el pom:

Luego configúrelo en el archivo de configuración

spring. cloud El parámetro .loadbalancer.retry.enabled controla la apertura/cierre del mecanismo de reintento. Debido a que Spring Retry está habilitado de forma predeterminada, solo necesitamos introducir dependencias. Si queremos desactivar el mecanismo de reintento, solo necesitamos cambiar Spring. .cloud.loadbalancer.retry habilitado está configurado en falso.

De hecho, entre los componentes de la arquitectura SpringCloud, ya sea Fegin, Ribbon o Zuul, todos proporcionan mecanismos de reintento, no los mencionemos por ahora. detalle.

Implementación práctica del registro de Eureka

Construcción del proyecto Eureka Server

1. Cree el proyecto springcloud-eureka-server y agréguelo al pom

spring-cloud-starter-netflix-eureka-server depende de ello.

2. Agregue la dependencia spring-cloud-starter-netflix-eureka-server en el archivo pom.xml

3. En la clase de inicio

p>

Utilice @EnableEurekaServer en SpringcloudEurekaServerApplication para habilitar el ensamblaje automático de EurekaServer.

4. Agregue el archivo de configuración application.properties

5. Inicie el proyecto y acceda a la dependencia flix-eureka-client.

2. Utilice @EnableEurekaClient en la clase de inicio para activar el ensamblaje automático de EurekaServer

SpringcloudEurekaClientApplication.

Configuración

La dirección de eureka.client.serviceUrl.defaultZone es la dirección del servidor Eureka recién iniciado, http://localhost:8761/eureka/.

Inicie el cliente y actualice la página de inicio de Eureka recién abierta, veremos que el servicio se ha registrado correctamente.

Agregar verificación de contraseña en el registro de Eureka

Arriba, vimos que después de configurar el servidor Eureka, accedimos a http://localhost:8761/ y pudimos iniciar sesión. , verá la página de administración de Eureka.

En la práctica, si la dirección registrada tiene una IP pública, entonces se accederá directamente a ella, lo cual no es seguro.

Por lo tanto, necesitamos transformar Eureka, integrar Spring-Security para lograr la verificación de seguridad y agregar verificación de permisos para garantizar la seguridad.

Primero, introduzca la dependencia Spring-Security en pom.xml

Luego agregue información de configuración de autenticación en application.properties

Finalmente, agregue la clase Spring Security Configuration

De esta manera, iniciamos Eureka. Una vez que el servidor esté en funcionamiento, visite http://localhost:8761/. El navegador le pedirá que ingrese su nombre de usuario y contraseña. Continúe visitando la página de administración proporcionada por Eureka.

Resumen

En este capítulo, aprendimos sobre Eureka. Aunque Eureka ha sido descontinuado, muchas empresas todavía lo utilizan y es lo suficientemente estable como para proporcionar una funcionalidad adecuada para la mayoría de las empresas. Como resultado, los temas relacionados con Eureka todavía surgen con frecuencia en las entrevistas. En resumen, si lo aprendes, es asunto tuyo.

Deseo que todos se conviertan en maestros pelinegros lo antes posible.