spring-cloud - spring boot microservicios ejemplo
Cómo enrutar entre microservicios utilizando Spring Cloud y Netflix OSS (1)
Al establecer un número de versión en los metadatos, puede hacer que su Svc1 obtenga la última versión de Svc2, es decir, obtener siempre la instancia con el número de versión más reciente. Ver esta esencia como guía.
Durante nuestro desarrollo de microservicios utilizando Spring Cloud, comenzamos a usar Zuul como proxy para cualquier conexión desde el exterior a microservicios, y para cualquier microservicio que necesite contactar a otro microservicio.
Después de algún tiempo, llegamos a la conclusión de que Zuul estaba diseñado para ser un servicio de vanguardia (solo para el tráfico de proxy desde el exterior a los microservicios), y no debería utilizarse para la comunicación intermicroservicios. Especialmente la forma en que Spring Cloud recomienda el uso de eureka para hacer una conexión directa (potencialmente equilibrada con la carga) a otro servicio nos hizo ir en contra de tener a Zuul entre todo.
Por supuesto, todo funciona bien como se esperaba (como siempre ocurre con Spring Cloud), pero no tenemos idea de cómo realizar un determinado caso de uso con esta configuración.
Al implementar una nueva versión de un microservicio, nos gustaría tener una implementación azul / verde con la versión anterior y la nueva. Sin embargo, al no tener Zuul entre los microservicios, la comunicación entre dos servicios separados continuará hasta la versión anterior hasta que se elimine de eureka.
Estamos pensando en cómo podemos lograr esto. En la siguiente imagen he dibujado lo que creo que podría ser una opción.
En la primera parte de la imagen, Zuul llama a eureka para obtener el registro para crear las rutas. Además, el servicio 1 está llamando a eureka para que el registro se enrute al servicio 2. Dado que el servicio 2 está en el registro de eureka, el enrutamiento se realiza con éxito.
En la segunda parte de la imagen, se implementa una actualización del servicio 2 (servicio 2.1). También se registra con eureka, lo que hace que el servicio 1 ahora pase al servicio 2 y al servicio 2.1. Esto no se quiere con el despliegue azul / verde.
En la tercera parte se muestra una solución potencial a este problema con otra instancia de eureka implementada solo para este propósito. Esta instancia no es consciente de los pares y no se sincronizará con la primera instancia de eureka. A diferencia de la primera instancia, el único propósito de este es facilitar el despliegue azul / verde. El servicio 2.1 se registra con la segunda instancia de eureka, y el servicio 1 se cambia su configuración para obtener su registro no desde la primera instancia de eureka, sino desde la segunda.
La pregunta principal que enfrentamos es si esta es una solución viable. Tener la flexibilidad de Zuul para enrutar es una gran ventaja que no tenemos en este escenario. ¿Deberíamos volver al enrutamiento de cada llamada de servicio a servicio a través de Zuul o hay alguna otra solución (tal vez configuración de cinta de algún tipo) más apropiada? ¿O es la segunda instancia de eureka la mejor solución para este tipo de implementaciones?
Cualquier comentario sería muy apreciado.
Un cordial saludo, Andreas