問題タブ [netflix-eureka]

私は自分のローカル マシンでspring-cloud-samplesを試しており、eureka と hystrix をサポートするシンプルな REST サービスを開発しました。

Feign クライアントへの参照を含む hystrix コマンド メソッド (@HystrixCommand 注釈付きメソッド) を介してサービスに接続するフロントエンド アプリケーションがあります。

クライアントを装う

Hystrix ラッパー

Spring MVC ProductService の 2 つのインスタンスを開始しました。最初のものは、期待どおり、指定された識別子に基づいて製品情報を提供します。一方、2 番目のものは、システムの依存関係の失敗をシミュレートするために、常に RuntimeException をスローします。

フロントエンド側では、hystrix クライアントを使用して製品情報を取得し、ProductService インスタンスが (リボンにより) ラウンド ロビン方式で呼び出されます。ProductService インスタンスの 1 つが常に例外を配信するという事実により、フロントエンドで複数の連続した呼び出しを行った後、ProductService 回路が開かれます (ProductService のインスタンスの 1 つが要求を正常に処理できる場合でも)。

ProductService の hystrix サーキット ブレークを回避するために、問題のある ProductService インスタンスのみを eureka から削除し、それらを正しく機能させ続けるにはどうすればよいですか? ProductService のヘルス インジケーター リソース "/health" の機能を変更して、システム依存関係のエラーを追加でチェックする必要があると思います。

カスタムヘルスチェックを実行できるspring-boot-starter- actuator の使用に遭遇しましたが、これは eureka からサービスインスタンスを取り出すのに役立たないようです。

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 インスタンスは、このタイプの展開に最適なソリューションですか?

どんなフィードバックでも大歓迎です。

よろしく、アンドレアス

以下の構成を持つ 2 つの eureka サーバー (ES1 と ES2 など) があります。

同期は機能しますが、本番環境へのリリース中に一方の eureka サーバー (ES2 など) が停止すると、もう一方の eureka サーバー (ES1) は古いキャッシュ情報を維持し、ES2 が再起動されると eureka クライアントを登録しますが、古いクライアントの登録は解除されます。リボン ロード バランサーによって使用される古い情報が発生することはありません。

以下の eureka クライアントの登録には、構成が使用されます。

古いインスタンスが eureka サーバーから登録解除されないのはなぜですか? このため、インフラストラクチャを完全にシャットダウンして再起動する必要があります。

新しいプロジェクトを開始しています。これは、マイクロ サービス アーキテクチャに基づいています。これについては、netflix テクノロジー スタックを検討しています。残りのサービスの開発には、dropwizard を使用します。ここまでは順調ですね。いくつか読んだ後、私はすべて混乱しています。異なるユースケースとは

• ヒストリックス
• ユーレカ
• リボン

私は質問が今非常に漠然としていることを知っています. 誰かが疑問を持っているので、詳細を追加します。

Netflix Service Discovery Server (Eureka) をさまざまなプログラミング言語 (php など) と統合する方法はありますか? たとえば、php でサービス検出クライアントを作成したいと考えています。

助けてくれてありがとう。