Zuulとリボンの統合
ZuulとRibbonの関係を理解できません。
私はズールを明確にしたと思います。これは、サービスのいくつかのインスタンスの1つに到達するために接続できるリバースプロキシです。ラウンドロビンアルゴリズムまたはそれを構成するものを使用して、適切なサーバーを選択します。これは従来のロードバランサーです。使用可能なインスタンスを知るには、Eurekaなどのレジストリを使用できます。
しかし、私はリボンでもっと問題を抱えています。クライアント側ロードバランサーとして販売されていますが、どういう意味ですか？外部サーバーは必要ありませんか？リボンは、Eurekaクライアントと同じようにクライアントに埋め込まれていますか？もしそうなら、それはどのように機能しますか？リボンを使用するときにZuulが必要ですか？
一部の記事で、実際にはZuulがデフォルトでロードバランシング部分にリボンを使用しており、さらに混乱していることがわかりました。これが本当なら「クライアント側」はどういう意味ですか？ Zuulはルーティング以外に何をしますか？
あなたが助けてくれるといいのですが。
クライアントとサーバーは常に相対的です。 Zuulはサービスインスタンスのクライアントであり、サービスインスタンスはZuulのサーバーです。
従来のロードバランサー（サーバー側ロードバランサー）を使用している場合、API呼び出し元（クライアント）はロードバランサーである単一のエンドポイントしか認識せず、クライアントはサーバーのリストを認識しません。ロードバランサーはリストからサーバーを選択します。
リボンのようなクライアント側のロードバランサーを使用している場合、API呼び出し元（クライアント）はサーバーのリストを認識し、リストからサーバーの1つを選択する必要があります。これが、クライアント側ロードバランサーと呼ばれる理由です。
ご存知のように、リボンはクライアント側のロードバランサーモジュールであり、多くのhttpクライアントモジュールに統合されています。例として、FeignおよびLoad-balanced RestTemplateはリボンをサポートしています。つまり、FeignおよびLoad-balanced RestTemplateは、リボンで使用する場合、指定されたリストまたはeurekaからリストからサーバーを選択できます。
Zuulに関しては、リクエストを実際のサービスインスタンスにルーティングするRibbonRoutingFilterがあります。 RibbonRoutingFilterはリボンを使用して、構成またはEurekaから提供されたリストからサーバーを選択しています。したがって、Zuulを負荷分散リバースプロキシとして使用する場合は、Zuulにリボンが必要です。