Solucionar el problema del registro repetido de microservicios en el clúster Consul
Sin más preámbulos, comencemos con yaml
Debido al método de registro multiservidor, existe un problema cuando registramos un servicio con un agente en el clúster de cónsul. Aparecerá un mensaje de error. El mismo ID de instancia se registrará repetidamente en diferentes nodos. Este es un gran problema, lo que significa que puede haber tantas instancias de servicio duplicadas como nodos. Por supuesto, en realidad solo se necesita uno, lo que significa que las instancias redundantes deben eliminarse, pero la operación real no es tan simple como se imagina.
La documentación oficial del cónsul tiene esta descripción:
El agente es responsable de gestionar el estado de sus servicios locales y de enviar actualizaciones sobre sus servicios locales a los servidores para mantener el catálogo global sincronizado.
El significado general es que cada agente mantiene los servicios registrados en su propio nodo y los envía a otros servicios para sincronizarlos en el catálogo global.
Esto significa que cada agente en realidad mantiene servicios registrados en su propio nodo. Cuando el mismo nombre de servidor e ID de instancia se registran en diferentes nodos, se considerarán servicios diferentes, lo cual no es lo que se debe dar por sentado. Se considera que cada ID de instancia es único y se sobrescribirá cuando se registre repetidamente. De hecho, el clúster de cónsules no lo maneja de esta manera. La operación de sobrescritura solo ocurrirá cuando se registre en el mismo nodo. Esta descripción es realmente críptica, por lo que no puede ser más sencilla. No se encuentra información relevante en Internet, por lo que todo depende de la percepción. ¡Es realmente muy engañoso!
Entonces, Consul en realidad proporciona dos interfaces de registro, /agent/service/register y /catlog/register, que requieren diferentes parámetros. Para obtener más información, puede leer la documentación de Consul.
Esta idea no tiene nada de malo, pero en la práctica existen muchos riesgos.
Primero, echemos un vistazo a la interfaz API para eliminar servicios proporcionados por el cónsul
1. /agent/service/deregister/:service_id
2. /catalog/deregister
El primero se ve bien, pero en realidad lo es. Considerando la alta disponibilidad, en k8s usaremos un servicio para representar a todos los cónsules, por lo que tiene carga equilibrada, esta interfaz en realidad lo hará. solo elimine el servicio en el nodo del servidor cónsul actual y no eliminará el servicio en otros nodos, por lo que esta interfaz no se puede usar directamente
La segunda interfaz parece normal, sí, elimínela a través de catlog. De hecho, el servicio del nodo correspondiente se eliminó justo cuando estaba secretamente feliz, el servicio eliminado volvió a aparecer después de un tiempo. De hecho, simplemente eliminó el caché en catlog. Los datos dentro y el servicio en el nodo real no estaban. eliminado Después de un tiempo, el nodo sincronizó la información de este servicio.
Ya quería maldecir en este momento ¿No es esto una trampa? ! ! ! ! La idea de eliminarlo directamente solo se puede abandonar primero y ver si hay otras formas de solucionarlo.
Hay dos ideas principales:
1. Eliminar si hay demasiados
Después de mirar la interfaz proporcionada por el cónsul, mi primera reacción es en realidad esa es necesario Inventa tu propia rueda para resolver el problema. De hecho, se puede resolver a través de la interfaz API proporcionada por el cónsul. Si al final solo puedes resolverlo a través de este método, puedes hacerlo. También aprenda de él. La lógica es relativamente simple.
2. Verifique antes de registrarse
Como estoy usando SpringCloud, puedo reescribir la interfaz de registro y estará listo. /p>
Este método tiene una limitación, porque Llama directamente a la interfaz del agente correspondiente para cerrar sesión en el servicio, lo que significa que el servicio debe poder acceder directamente al agente; de lo contrario, no se puede implementar.
Como se mencionó anteriormente, Consul en realidad proporciona dos interfaces de registro. La interfaz predeterminada es /agent/service/register y la interfaz /catlog/register no se utiliza. Debido a problemas de tiempo, no procedí. Si tengo tiempo más tarde, probaré si este problema no existe a través de la interfaz catlog.