Comment faire le trajet entre les microservices en utilisant Spring Cloud & Netflix OSS

lors de notre développement de microservices en utilisant Spring Cloud, nous avons commencé à utiliser Zuul comme un proxy pour toute connexion de l'extérieur vers microservices, et pour tout microservice nécessitant de contacter un autre microservice.

après un certain temps nous avons fait la conclusion que Zuul était conçu pour être un service de bord (seulement le trafic proxy de l'extérieur vers les microservices), et ne devrait pas être utilisé pour la communication intermicroservices. En particulier, la façon dont Spring Cloud recommande l'utilisation d'eureka pour faire une connexion directe (potentiellement équilibrée) à un autre service nous a fait aller contre avoir Zuul entre tout.

bien sûr, tout fonctionne comme prévu (comme il le fait toujours avec Spring Cloud), mais nous ne savons pas comment effectuer un cas d'utilisation avec cette configuration.

Lors du déploiement d'une nouvelle version d'un microservice, nous aimerions avoir un déploiement bleu / vert avec l'ancienne et la nouvelle version. Cependant, n'ayant pas de Zuul entre les microservices, la communication entre deux services distincts continuera de passer à l'ancienne version jusqu'à ce qu'elle soit retirée d'eureka.

nous réfléchissons à la façon d'y parvenir. Dans l'image ci-dessous j'ai dessiné ce que je pense pourrait être une option.

Dans la première partie de l'image, Zuul appelle eureka pour obtenir le registre pour créer les routes. Aussi le service 1 appelle eureka pour obtenir le Registre pour route au service 2. Depuis le service 2 est dans le eureka registry, le routage est effectué avec succès.

Dans la deuxième partie de l'image, une mise à jour de service 2 (2.1) est déployé. Il enregistre avec eureka, qui rend service 1 route à la fois de service 2 et 2.1. Ce n'est pas voulu avec le déploiement bleu/vert.

dans la troisième partie, une solution potentielle à ce problème est présentée avec un autre exemple d'eureka déployé juste à cette fin. Cette instance n'est pas consciente par les pairs et ne la synchronisation avec le premier eureka instance. Contrairement au premier cas, le seul but de celui-ci est de faciliter le déploiement bleu/vert. Service 2.1 enregistre avec la seconde instance d'eureka, et service 1 sa configuration est modifiée pour récupérer son registre non pas de la première, mais de la seconde instance d'eureka.

la principale question à laquelle nous sommes confrontés est de savoir s'il s'agit d'une solution viable. Avoir la flexibilité de Zuul à route est un grand plus qui nous n'avons pas dans ce scénario. Devrions-nous revenir à l'acheminement de chaque appel service-à-service par Zuul ou y a-t-il une autre solution (peut-être une configuration de ruban quelconque) plus appropriée? Ou la seconde instance d'eureka est-elle la meilleure solution pour ce type de déploiements?

toute rétroaction serait grandement appréciée.

salutations, Andreas