Análisis del código fuente de Spring Cloud Eureka - cliente
EurekaServiceRegistry implementa ServiceRegistry, que es la clase de implementación específica del registro de instancia. EurekaServiceRegistry implementa ServiceRegistry, que es una clase de implementación específica de registro de instancia, e internamente completa la operación de enviar eventos de registro de servicio a través del registro.
EurekaRegistration es el objeto registrado real, que encapsula toda la información de registro del cliente. Es la implementación específica del estándar org.springframework.cloud.client.serviceregistry.ServiceInstance.
Primero cree el estado de inicialización. p> Primero cree el estado de inicialización de InstanceInfo y asigne valores a una gran cantidad de propiedades de InstanceInfo de acuerdo con la configuración.
La creación de ApplicationInfoManager encapsula internamente la información relevante de la aplicación registrada en eureka, incluida información de la instancia, configuración de parámetros, estado de la instancia, etc.
El objeto InstanceInfo también se configura en ApplicationInfoManager.
Este bean es muy importante, define internamente casi todas las operaciones del cliente y es la clase de cliente que inicia estas operaciones. La atención se centra en la implementación en el método constructor, que se analizará a continuación.
La operación de registro del cliente eureka es activada por SmartLifecycle, y la clase de implementación correspondiente es EurekaAutoServiceRegistration
Verifique el método de inicio directamente De acuerdo con los parámetros de inicialización, ingresamos directamente el método if. Hay dos métodos clave: registrar() se usa para iniciar el registro; publicarEvent se usa para publicar eventos registrados para la instancia actual.
quizásInitializeClient activará la creación de instancias de los siguientes dos beans importantes: ApplicationInfoManager y EurekaClient.
ApplicationInfoManager guarda información sobre InstanceInfo y toda la información de configuración de InstanceConfig.
EurekaClient (CloudEurekaClient) se construye registrando todo el cliente, sincronizando datos con el servidor y definiendo y abriendo tareas programadas.
El proceso de creación de estas dos clases se presentará por turno.
Los beans se definen en la configuración automática anterior
Aquí, primero se crea un objeto InstanceInfo a través de la fábrica y luego el método de creación asigna todas las configuraciones en EurekaInstanceConfig a InstanceInfo a través del constructor. patrón.
Luego, el método de creación asigna todas las configuraciones en EurekaInstanceConfig a InstanceInfo a través del patrón de construcción.
Internamente, inicializa dos propiedades: oyentes e instanciaStatusMapper.
El bean se define en la configuración automática anterior
El método superconstructor de la clase principal se llama primero
La lógica inicial del método constructor es inicializar el objeto BackupRegistry Cuando todas las URL en eureka son inaccesibles, el objeto se implementará como una clase personalizada especificada por backupRegistryImpl. El valor predeterminado es NotImplementedRegistryImpl y no se procesa nada dentro de esta clase.
El método fetchRegistry se llamará al inicio, cuando se ejecuten las tareas programadas y cuando se actualice la caché del cliente. Principalmente hace varias cosas.
La aplicación aquí es extraer la información de registro completa del servicio eureka, como se muestra a continuación
Primero, el estado actual del servicio remoto se compara con el último estado extraído, si coincide, finaliza; si no coincide, genera el evento StatusChangeEvent.
fetchRegistry devuelve verdadero si el registro se obtuvo correctamente del servidor eureka.
Aquí también debemos enfatizar la implementación de ejecución:
Scheduler.schedule pasa el tiempo de retraso, no el tiempo de programación. Tiempo de retraso en lugar de tiempo de ciclo, el ciclo de ejecución en realidad cambia dinámicamente, lo que se logra mediante la recursividad de Scheduler.schedule.
Puedes ver que en el bloque try, el valor de retraso se restablece. Si se produce un tiempo de espera, newDelay se puede establecer en 2 veces el tiempo y luego la programación se ejecuta nuevamente finalmente, con un retraso de 2 veces, esta es la implementación del cronograma periódico dinámico. Esta es una implementación de un plan de bucle dinámico.
Esta tarea en realidad llama a fetchRegistry, que recupera el registro más reciente y actualiza el caché local.
Esta tarea inicia una solicitud http que llama al método sendHearBeat, que inicia una actualización de latido.
InstanceInfoReplicator es un sincronizador de información de instancia. Su función es sincronizar información de nueva instancia con el servidor eureka cuando ocurren cambios (estado, dirección, IP, valores de parámetros de configuración, etc.).
Los siguientes son tres métodos:
start(): durante la inicialización, llame a start para abrir la tarea programada y llame a run() de vez en cuando para detectar cambios.
onDemandUpdate(): Se llama como escucha cuando se activa un cambio de estado, también llama a run() para detectar el cambio.
run(): compruebe si la InstanceInfo actual es la misma que la última vez. Si ha cambiado, llame a discoverClient.register(); sincronizará la nueva información con el servidor eureka. La base es si InstanceInfo está marcado como isDirty
La base se implementa en DiscoveryClient.refreshInstanceInfo();.