Spring Boot を使用して開発された約 50 のマイクロサービスがあります。Spring Cloud を使用してサービスを Eureka に登録し、Feign を使用してコンシューマからサービスを呼び出します。@FeignClient("<foo>")コントラクトは非常に標準的で、コンシューマーはアノテーション付きのインターフェースを使用してfoo、Eureka に登録されているサービスを見つけます。ターゲット サービスでの登録、ルックアップ、および呼び出しはすべて、サービスの 1 つまたは複数のインスタンスが実行されている状態で期待どおりに機能します。
foo各インスタンスが特定のステレオタイプまたは指定を持つ複数のインスタンスを同じサービスが実行している可能性があるという新しい要件があります。たとえば、 の一部のインスタンスはfooサードパーティ統合の同期ワークロードをfoo処理することが期待されており、 の一部のインスタンスは内部メッセージ (非同期ワークロード) を処理することが期待されています。ブートストラップ (Spring Cloud 構成の一部を介して実行) で定義されるサービスで呼び出される構成プロパティをstereotype定義し、サービス インスタンスにワークロードを処理するsyncように指示します。async構成は次のようになります。
service.stereotype: sync # or async
さらに、このプロパティをサービス登録時にプロパティeureka.instance.metadatamapとしてエウレカのマップに追加します。Eureka が登録されると、サービスに対してこの値が表示されるようになったことがわかります。stereotypefoofoo
ここまでは順調ですね。今質問：
DiscoveryClientまたは Feign to lookupのいずれかに構成 (または注釈) メカニズムがありますが、修飾子としてfooを使用しています。stereotype言い換えれば、コンシューマ アプリケーションが Eureka をルックアップするとき、Eureka に、たとえばstereotypeisのインスタンスのみを与えるように指示できますasyncか? これが可能であれば、コンシューマー コンポーネントは、非同期ワークロードfooを処理するインスタンスにのみ非同期ワークロードが送信されるようにすることができます。
これまでのところ、私の研究では何も見つかりませんでした。ここで概説されているようにDiscoveryClientEureka REST インターフェイスを使用し、返された各インスタンスのメタデータ マップを検索してターゲット エンドポイントを見つけるサンプル (オーバーライドできる可能性があります) を作成しました。しかし、それは力ずくのように聞こえました。できれば既存のメカニズムの 1 つを使用してこれを行うのが理想的です。これにより、車輪を再発明する代わりに、Feign の負荷分散と再試行機能を引き続き使用できるようになります。GET /eureka/v2/apps/appID