問題タブ [spring-cloud]

シナリオ：

dev、qa、prod 環境があり、それぞれで 2 つの eureka サーバーを実行したいと考えています。

そのため、dev,eureka1 (devserver1 上) と dev,eureka2 (devserver2 上) の 2 つのプロファイルで EurekaServer アプリケーションを実行できるようにしたいと考えています。ここで、eureka1 および eureka2 プロパティも環境固有です。

次の eureka-dev.yml を作成すると

eurekaX プロファイルをピックアップしていないようです。eureka-eureka1.yml と eureka-eureka2.yml を作成できることは理解していますが、これを行う最も効率的な方法を見つけようとしています。

spring-cloud-starter-zuul を使用しようとしています。私は Eureka をセットアップし、作成した単純なサービスを Eureka クライアントとして登録しました。2 つの異なるホストに 2 つの異なるアプリケーション名で 2 つのインスタンスを登録するので、これらは Eureka の 2 つの異なるサービスになります。私の目的は、serviceA のパフォーマンスが良く、serviceB のパフォーマンスが悪い場合に、serviceA へのプロキシが serviceB へのプロキシに失敗しても影響を受けないようにすることです。

ロード テスト serviceA を zuul を介して単独で実行すると、400 TPS のスループットを問題なく維持できます。次に、serviceB を投入して完全に過負荷にし、あちこちでタイムアウトさせると、serviceA が 400 で継続し、serviceB が失敗すると予想されますが、代わりに serviceA は 50 TPS 未満の成功率に低下し、次のように一連のエラーが発生します。良い。

RibbonRoutingFilter によって生成されたすべての RibbonCommands が hystrix で同じ回路を共有しているように見えますが、これは私には意味がありません。RibbonCommand を作成する RibbonRoutingFilter を見ると、別のものを使用するように構成する方法がわかりません。

RibbonRoutingFilter で:

restClient が serviceA と serviceB で異なることを確認したので、application.yml ファイルで指定した独自の接続プール構成を使用していますが、serviceA と serviceB の間のサービス品質にはまだ大量の相互汚染があります。サービスB.

「commandKey」を最初のパラメーターとして受け取るRibbonCommandの別のコンストラクターがあるようです。私が参照するコンストラクターは、「デフォルト」のcommandKey値を持つコンストラクターに単純に委任します。RibbonRoutingFilter でそれをオーバーライドするスイッチやオプションはありません。私にとって、これは spring-cloud プロジェクトから使用された場合、Zuul の実行可能性を著しく損なうものです。

各サービスが独自の回路を持つように、すぐに使用できるように構成する方法はありますか?

私のpomの該当部分：

アプリケーション.yml:

私のアプリケーションクラス:

自動構成を使用して、Spring Cloud をメッセージングで動作させようとしています。

私のプロパティファイルには以下が含まれています：

私の構成クラスは次のとおりです。

私のリスナークラス:

ただし、何も印刷されないようです。キューが適切なリージョンにあることを確認しました。キューに受信準備が整ったメッセージがあります。

誰かがガイダンスを提供してもらえますか？

spring-config-server を使用しています。私はそれを機能させていますが、理想的には、プロパティを持つ .yaml ファイルにサーバーのリストを生成したいと考えています。

それから：

(applicationName).yaml ファイル内:

List<Server>構成から動的に生成したいを参照してください。この構成が構成サーバー上にあるという事実は、ローカルの .yaml ファイルとそれほど変わらないはずですよね?

助けてくれてありがとう

私はSpring Cloud Configで遊んでいて、そこにあるアイデアの多くが気に入っています。ただし、その作成者がそれを使用することをどのように意図したかをよりよく理解したい.

より大きな API をサポートするサービスがいくつかあるとしましょう。これらのサービスは互いに独立しているため、ソースは別々のリポジトリで管理されます。これにより、それらをバージョン管理し、互いに別々に展開できます。今日、彼らの財産は個別に管理されています。

このより大きな API をサポートする個々のアプリケーション/サービスのすべての構成情報を単一の構成サーバーで提供するというアイデアが気に入っています。EnvironmentRepository (GIT ベース) のデフォルトの実装を見ると、すべてのアプリケーション構成ファイルを含む単一のリポジトリが必要になります。それらはすべて同じリポジトリ内にあるため、それらはすべて 1 か所でまとめて管理/バージョン管理されます。

両方のモデルを相互に動作させるにはどうすればよいですか? すべてのアプリケーションに 1 つではなく、アプリケーションごとにリポジトリを作成する方がよいでしょうか? あなたの考えは何ですか？

-ジョシュア