Spring Cloud を使用したマイクロサービスの開発中に、外部からマイクロサービスへの接続、および別のマイクロサービスに接続する必要があるマイクロサービスのプロキシとして Zuul の使用を開始しました。
しばらくして、Zuul はエッジ サービス (外部からマイクロサービスへのトラフィックのプロキシのみ) として設計されており、マイクロサービス間通信には使用すべきではないという結論に達しました。特に、Spring Cloud が eureka を使用して別のサービスに直接 (潜在的に負荷分散された) 接続を行うことを推奨している方法は、すべての間に Zuul を配置することに反対しました。
もちろん、すべてが期待どおりにうまく機能します (Spring Cloud では常にそうです) が、このセットアップで特定のユースケースを実行する方法についてはわかりません。
マイクロサービスの新しいバージョンをデプロイするときは、古いバージョンと新しいバージョンでブルー/グリーン デプロイを行いたいと考えています。ただし、マイクロサービス間に Zuul がないため、2 つの個別のサービス間の通信は、eureka から削除されるまで古いバージョンに進みます。
私たちはこれをどのように達成できるかを考えています。下の図では、オプションと思われるものを描きました。
図の最初の部分では、Zuul が eureka を呼び出してレジストリを取得し、ルートを作成します。また、サービス 1 は、レジストリを取得してサービス 2 にルーティングするために eureka を呼び出しています。サービス 2 は eureka レジストリにあるため、ルーティングは正常に行われます。
図の 2 番目の部分では、サービス 2 (サービス 2.1) の更新がデプロイされています。これは eureka にも登録され、サービス 1 がサービス 2 とサービス 2.1 の両方にルーティングされるようになります。これは、Blue/Green デプロイメントでは望ましくありません。
3 番目の部分では、この問題に対する潜在的な解決策が、この目的のためだけにデプロイされた eureka の別のインスタンスとともに紹介されます。このインスタンスはピア対応ではなく、最初の eureka インスタンスと同期しません。最初のインスタンスとは対照的に、このインスタンスの唯一の目的は、Blue/Green デプロイを容易にすることです。サービス 2.1 は 2 番目の eureka インスタンスに登録し、サービス 1 の構成は変更されて、最初からではなく 2 番目の eureka インスタンスからレジストリを取得します。
私たちが直面している主な問題は、これが実行可能な解決策であるかどうかです。Zuul のルーティングの柔軟性は、このシナリオにはない大きなプラスです。すべてのサービス間呼び出しを Zuul 経由でルーティングすることに戻すべきでしょうか、それともより適切な別のソリューション (おそらく何らかのリボン構成) がありますか? それとも、2 番目の eureka インスタンスは、このタイプの展開に最適なソリューションですか?
どんなフィードバックでも大歓迎です。
よろしく、アンドレアス