問題タブ [netflix-eureka]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
1173 参照

spring-cloud - netflix を使用して展開中にすべての要求を (同じサービスの) 特定のバージョンに転送する方法は?

異なるホストで実行されている同じサービスの 4 つのインスタンスがあります。そのサービスの新しいバージョンをノードごとにデプロイしています。展開中、着信要求はロード バランサーに従って任意のバージョン (ホスト) に転送されます。すべての受信リクエストを特定のバージョンに転送できる netflix の方法はありますか?

バージョンを定義できる一般的な方法はありますか (同じ serviceId に対して)。また、着信リクエストのヘッダーにバージョンが定義されている場合、それを使用してリクエストを特定のバージョンに転送できます。

次のようなものかもしれません:

Zuul プロキシでは、

サンプルサービスでは、

または同じサービスのバージョン管理を実現する他のメカニズムはありますか?

0 投票する
0 に答える
228 参照

node.js - エウレカの再起動はプラーナには効かないようです

Eureka を再起動すると、次のエラーが表示されます。

com.netflix.zuul.exception.ZuulException: 転送エラー原因: com.netflix.client.ClientException: ロード バランサーにクライアント用のサーバーがありません: prana

この問題を引き起こすと思われるプラーナの潜在性があります。しばらくすると、prana サイドカーが機能し始めたようです。手がかりはありますか?おそらく構成設定です。Spring クラウド ベースのアプリは正常に動作します。Prana に依存しない非 jvm ベースのアプリだけです。

0 投票する
1 に答える
8104 参照

spring-cloud - Netflix Eureka リースを理解する - サービスが登録解除し続ける

Spring Cloud Eureka クライアントの 1 つでこの断続的な問題が発生し続けていますが、他のクライアントでは発生していません。「NCLSEARCHSERVICE」を開始すると、Eureka に登録され、約 30 秒から 1 分間 Eureka に「UP」と表示された後、登録が解除されます。これは、他のすべてのサービスを登録しているが、「リースが登録されていない」ため検索サービスの登録に失敗していることを示す Eureka サーバーからのログです。ログ ファイルのコピー/貼り付けのフォーマットが不適切で申し訳ありません。

存在し、リソースを登録しています: CONFIGSERVICE - 172.18.100.120 2015-10-01 09:48:55.145 WARN 6470 --- [nio-8761-exec-4] cneureka.resources.InstanceResource : 見つかりません (更新): CONFIGSERVICE - 172.18. 100.120 2015-10-01 09:48:55.147 WARN 6470 --- [nio-8761-exec-2] com.netflix.eureka.InstanceRegistry: DS: レジストリ: リースが存在しません。リソースを登録しています: ZUULSERVER - eXploit- Zuul 2015-10-01 09:48:55.147 WARN 6470 --- [nio-8761-exec-2] cneureka.resources.InstanceResource: 見つかりません (更新): ZUULSERVER - eXploit-Zuul 2015-10-01 09:48 :55.419 INFO 6470 --- [nio-8761-exec-7] com.netflix.eureka.InstanceRegistry : ステータス UP 2015-10-01 09:48:55.423 のインスタンス ID 172.18.100.120 を登録しました INFO 6470 --- [nio -8761-exec-8] com.netflix.eureka.InstanceRegistry :登録されたインスタンス ID eXploit-Zuul のステータスが UP 2015-10-01 09:48:55.778 INFO 6470 --- [nio-8761-exec-9] com.netflix.eureka.InstanceRegistry : 登録されたインスタンス ID 172.18.100.120 のステータスが UP 2015-10-01 09:48:55.809 INFO 6470 --- [io-8761-exec-10] com.netflix.eureka.InstanceRegistry: 登録されたインスタンス ID eXploit-Zuul のステータスが UP 2015-10-01 09:49: 05.416 WARN 6470 --- [nio-8761-exec-3] com.netflix.eureka.InstanceRegistry : DS: レジストリ: リースが存在しません。リソースを登録しています: GEOSERVER - 172.18.100.155 2015-10-01 09:49: 05.418 WARN 6470 --- [nio-8761-exec-3] cneureka.resources.InstanceResource : 見つかりません (更新): GEOSERVER - 172.18.100.155 2015-10-01 09:49:05.441 INFO 6470 --- [nio- 8761-exec-5] com.netflix.eureka.InstanceRegistry : 登録されたインスタンス ID 172.18.100。155 ステータス STARTING 2015-10-01 09:49:05.607 INFO 6470 --- [nio-8761-exec-4] com.netflix.eureka.InstanceRegistry : 登録済みインスタンス ID 172.18.100.155 ステータス STARTING 2015-10-01 09:49:05.948 INFO 6470 --- [nio-8761-exec-8] com.netflix.eureka.InstanceRegistry : 2015-10-01 09:49:06.107 INFO 6470 のステータスを持つ登録済みインスタンス ID 172.18.100.197 -- - [nio-8761-exec-9] com.netflix.eureka.InstanceRegistry : ステータス UP 2015-10-01 09:49:11.175 WARN 6470 でインスタンス ID 172.18.100.197 を登録 --- [io-8761-exec-10 [ nio-8761-exec-3] com.netflix.eureka.InstanceRegistry : ステータスが UP 2015-10-01 09:49:11.562 WARN 6470 の登録済みインスタンス ID 172.18.100.155 --- [nio-8761-exec-5] cneureka.resources.InstanceResource : 最後のダーティ タイムスタンプ以降の同期時間異なる - ReplicationInstance ID: 172.18.100.155、Registry: 1443651408538 Incoming: 1443651207024 Replication: true 2015-10-01 09:49:11.607 INFO 6470 --- [nio-8761-exec-4] com.netflix.eureka.InstanceRegistry:ステータス UP 2015-10-01 09:50:03.859 INFO 6470 で登録されたインスタンス ID 172.18.100.155 --- [nio-8761-exec-6] cneureka.resources.InstanceResource : 見つかりました (キャンセル): NCLSEARCHSERVICE - 172.18.100.197 2015 -10-01 09:50:03.870 INFO 6470 --- [io-8761-exec-10] com.netflix.eureka.InstanceRegistry : 2015-10-01 09:50:04 のステータスでインスタンス ID 172.18.100.197 を登録しました.120 INFO 6470 --- [nio-8761-exec-2] com.netflix.eureka.InstanceRegistry : 2015-10-01 09:50:04.130 INFO 6470 --- [nio- 8761-exec-5] cneureka.resources.InstanceResource : 見つかりました (キャンセル): NCLSEARCHSERVICE - 172.18.100.197 2015-10-01 09:50:04.745 WARN 6470 --- [nio-8761-exec-3] com.netflix。 eureka.InstanceRegistry
: DS: レジストリ: リースが登録されていないため、キャンセルに失敗しました: NCLSEARCHSERVICE:172.18.100.197

私の検索サービスのログには、興味深いものは何も表示されていないようですが、Eureka で以前はダウンしていたことがわかり、現在はステータスがアップに変更されています。

2015-09-30 17:59:14.164 INFO 9056 --- [main] cneEurekaDiscoveryClientConfiguration : ステータス DOWN 2015-09-30 17:59:14.164 INFO 9056 --- [main] com.netflix. discovery.DiscoveryClient : ローカル ステータス変更イベント StatusChangeEvent [現在 = DOWN、前 = UP] 2015-09-30 17:59:14.208 INFO 9056 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_NCLSEARCHSERVICE/172.18 を見ました.100.197: サービスを登録しています... 2015-09-30 17:59:14.217 INFO 9056 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_NCLSEARCHSERVICE/172.18.100.197 - 登録状態: 204 2015-09- 30 17:59:14.218 情報 9056 --- [メイン] com.netflix.discovery.DiscoveryClient: DiscoveryClient_NCLSEARCHSERVICE/172.18.100.197 - ステータスの登録解除: 200 2015-09-30 17:59:14.218 INFO 9056 --- [メイン] cneEurekaDiscoveryClientConfiguration: アプリケーション nclSearchService をステータス UP の eureka に登録しています

さまざまな値と構成を実験し続けているため、私の構成は現在混乱していますが、ここに私が取り組んでいる基本的な値があります:

構成サービスから構成を動的にロードしていることもわかりますが、それはアプリケーション固有の変数をロードするだけです。

以前は、検索サービスの構成をランダムにいじり続けると、Eureka で安定させることができました。しかし、その後問題が再発し、実際に何が原因であるかを特定することはできません。Eureka とインスタンス レジストリの問題のようですが、どうすれば修正できるのかわかりません。

更新 1: NCLSEARCHSERVICE は、spring-boot-dependencies 1.2.5.RELEASE および spring-cloud-netflix 1.1.0.M1 を使用しています。私の Eureka サーバーは同じバージョンのスプリング ブート依存関係を使用していますが、spring-cloud-netflix 1.0.3.RELEASE. 検索サービスを更新して、問題に影響があるかどうかを確認してみました。すべてのサービスで同じバージョンを使用することが推奨されている場合は、バージョンを上下に移動できます。

トラブルシューティングで、検索サービスで /refresh を呼び出そうとしたのは 1 回だけでした。私の記憶が正しければ、一時的に表示されてから再びレジストリから削除されるという同じプロセスを経ていました。

更新 2: 問題を絞り込んだ可能性があります...ポート 8761 で実行されている Eureka サーバーと同じ VM のポート 8888 で実行されている構成サーバーがありました。検索サービスで動的構成を無効にし、の内容を移動しました設定サーバーの nclSearchService.yml から検索サービスの application.yml へ。検索サービスは Eureka に登録されており、約 10 分間安定しています。

検索サービスが構成サービスを使用するように構成されていないにもかかわらず、構成サービスがまだ展開されて実行されているため、これは奇妙です。また、検索サービスが登録解除されているときでも、構成サービスから nclSearchService.yml ファイルが正常にプルされたことをログで確認できました。構成サービス。

それが何を意味するのかわかりません:)

0 投票する
0 に答える
188 参照

node.js - Prana Side Car Service to Service Call

私は奇妙な問題に遭遇しています。nodejs ベースのサービスを使用して Prana Sidecar を実装しました。Node サービスは、prana ホスト uri を使用して、別のサービスを見つけて呼び出します。すべてのサービスは docker コンテナーにあります。prana を機能させるには、最初にノード サービスを直接呼び出す必要があるようです。そうしないと、次のエラーが発生します。

ノードサービスに直接アクセスしても問題は発生しません。

0 投票する
2 に答える
10563 参照

spring-boot - 春のブート負荷分散

私は春のブートアプリケーションに取り組んでいます。

アプリケーションの前にロードバランサーを配置して、いくつかのサーバーに負荷を分散する方法を知りたいです。

私がグーグルで調べたところ、ロードバランシングジョブを達成するのに役立つEurekaHystrixRibbonArchaiusなどの Netflix API があることがわかりました。

しかし、これらの用語が、特定のサービスにアクセスするすべてのユーザーに高い信頼性と可用性を提供すると同時に、要求を分散して負荷を分散するのにどのように役立つかはわかりませんでした。

これらすべてを調べていますが、起動へのエントリポイントを見つけることができません。実際、私はどこから始めればよいのかわかりません。

0 投票する
3 に答える
4557 参照

node.js - Node アプリを Spring Cloud と Netflix の Eureka に登録する方法

ノードアプリを Netflix の Eureka に登録しようと懸命に努力していますが、何度もグーグル検索した後も、まだ解決策を探しています。私が把握できる最大のことは、Pranaがあるということですが、まだPrana の問題リストにある問題が発生しています(これは、REST テンプレートがこのアプリを検出できないことを意味していると思います)。

サイドカーは、別の提案された解決策ですが、私は何の反応も得ていません。これらの 2 つとは別に、ノード モジュールEureka-Node-clientを見つけましたが、いずれも目的を果たしません。

0 投票する
0 に答える
1565 参照

spring-cloud - Eureka First Bootstrap モードで Spring Cloud Config-Server を実行できない

*****構成サーバー - アプリケーション サービスのセットアップ*****

  1. 以下は、application.yml からの構成です。

    /li>
  2. 以下はboostrap.ymlの構成です

    /li>
  3. この単純なスプリング ブート アプリケーションを起動すると、config-server が Eureka に登録されます。

**一般的な Eureka Server は 8761 ポートで実行されています

********以下はアプリケーションクライアントの設定です********

  1. 以下は、私のbootstrap.ymlのアプリケーションクライアント構成です

    /li>
  2. 以下のスニペットのような Spring Controller でのプロパティの注入が機能していません。

    /li>

私たちが何か間違ったことをしている場合は、私たちに提案してください。

0 投票する
1 に答える
2636 参照

spring - Zuul または eureka がホスト ヘッダーをサービス インスタンス ホストに設定

同じサービスの 3 つのインスタンスを使用しています。それらは eureka に登録されています。彼らの前にズールがいます。

サービスがコントローラの 1 つ (/login など) にリダイレクトしようとするたびに、ホスト名: ポート (ブラウザのアドレス フィールドに表示されます) に直接移動し、代わりに zuul プロキシを再度経由します。これにより、タイムアウトが発生します。サービスに入るヘッダーを追跡しています -hostサービスのホスト名に設定されたヘッダーがあります。

x-forwarded-host代わりにアドレス from を使用するべきではありませんか? zuul/eureka にそれを強制する方法は? それとも、代わりにそれを使用するためにいくつかのスプリングブート構成を調整する必要がありますhostか?